Building a Business Development Claude Project: Sales Collateral to Prospecting Engine

A founder asked me last week whether his team could “just put their sales playbook into Claude and have it do prospecting for them.” The answer is no, but the answer to a slightly different question is yes, and the slightly different question is the one worth asking.

You can’t replace human prospecting with AI. The deals that matter most are the ones where a real person with judgment made a smart approach at the right time to the right buyer. What you can do is build a Claude project that does the underlying work (account research, signal interpretation, angle development, message drafting) at a speed and quality that lets the human reps spend their time on the parts that actually require them.

This piece walks through how I build that project for clients. It’s not theoretical. It’s what’s been working over the last six months across a handful of engagements.

---

What a “business development Claude project” actually is

A Claude project (the feature inside Claude where you can give it persistent files, instructions, and context that it uses across every conversation) is a useful container for the kind of work a BDR or AE does at the top of the funnel.

The version I build typically contains:

• Sales collateral: case studies, one-pagers, deck content, pricing guidance. The stuff a rep would normally have on their desktop or in a SharePoint folder somewhere.
• Real interaction examples: anonymised email threads from won deals, discovery call summaries, objection-handling exchanges. The actual pattern of how this business sells, not the theoretical version.
• ICP definitions and signal libraries: who you’re selling to, what triggers indicate they’re worth approaching, what angles work for which segments.
• Voice and brand guidance: how the company writes, what it sounds like, what it doesn’t sound like. This is what stops the output looking like generic AI slop.
• Process documentation: the qualification framework, the discovery flow, what good prospecting looks like in this specific business.

What you get back is a Claude instance that genuinely understands how this company sells, who it sells to, and how to approach the work in a way that’s consistent with the brand and the existing playbook. Not a generic AI tool with sales prompts bolted on. A specific tool, for a specific business, that gets better the more you use it.

---

What it actually does day to day

The use cases that have stuck (the ones reps actually return to, not the demo-ware ones) tend to fall into four categories.

Account research. Rep identifies a target account. Claude pulls together what’s publicly known: company size, recent news, leadership changes, funding events, product launches, hiring patterns. It cross-references this against the ICP definition and flags whether and why this account fits. What used to be a 30–45 minute exercise per account becomes 5 minutes, with output that’s actually structured and comparable across accounts.

Signal interpretation. When a tool like Apollo or Clay surfaces a trigger event, the rep doesn’t always know what to do with it. New CRO appointed at a target account is a signal, but the angle for approaching that account depends on a dozen variables. Claude, with the company’s playbook and pattern of past wins loaded, can suggest the specific angle, the right opening, and which case study or proof point to lead with. The rep makes the judgment call. Claude does the analysis.

Personalised message drafting. Not template filling. The rep tells Claude what they’ve found, what angle they want to take, and which prospect they’re approaching. Claude drafts a message that’s actually personalised: references the right context, sounds like the company’s voice, includes the right proof points. The rep edits, sends, moves on. Time per high-quality outbound message drops from 20–30 minutes to under 5.

Pre-call preparation. Before a discovery call, the rep dumps everything they know about the account into Claude and asks for a structured pre-call brief: likely pain points based on company profile, questions to ask, objections to anticipate, comparable wins to reference. The output isn’t perfect, but it’s a much better starting point than walking into the call with a half-remembered LinkedIn skim.

There are other uses (call summaries, follow-up drafting, proposal scoping) but those four are where most of the time saving compounds.

---

How to build it

Building one of these isn’t complicated, but the order matters and the inputs matter more than the prompts.

Step 1: Get the inputs honest.

The single biggest mistake I see is people loading aspirational materials into the project instead of real ones. The sales deck you wish you used. The qualification framework that’s been in draft for six months. The ICP statement that doesn’t actually describe your real customers.

What you want loaded is what’s true. Real won-deal interactions. The actual ICP based on who’s actually buying. The case studies that reps actually use because they actually land. If your inputs describe a fantasy version of the business, the output will help you do prospecting for a business that doesn’t exist.

This is also why you can’t skip the foundations work. If you don’t have honest pipeline data, real ICP definition, or documented sales process, that’s the work to do first. The Claude project amplifies what you already have. What Revops Actually Means and How to Define Your ICP cover the prerequisite work.

Step 2: Add interaction examples, not just collateral.

Most people load the deck and the one-pagers and stop there. The thing that actually makes the project useful is the examples of real interactions. Email threads from won deals (the full thread, not just the cold open). Discovery call summaries showing how good calls actually flow. Examples of how reps handle the three or four objections that come up most often.

Anonymise where you need to, but keep the substance. The model learns the pattern from the substance, not the surface.

Step 3: Write proper instructions.

The system instructions for the project are where you bake in how it should behave. Things like:

• “When suggesting outreach angles, lead with the customer’s likely problem, not the product feature.”
• “Drafts should never use the words ‘leverage’, ‘synergy’, or ‘circle back’.”
• “Always cite which case study or interaction example you’re drawing from when making a recommendation.”
• “If the input doesn’t contain enough detail to make a confident recommendation, say so. Don’t invent specifics.”

The instructions are what stops the output drifting into generic AI sales territory. They’re worth iterating on for the first few weeks until the output consistently sounds like the business.

Step 4: Connect it to real intelligence sources.

A Claude project on its own works on what you give it. To make it genuinely useful for prospecting at scale, you want it connected (or at least workflow-adjacent) to the tools that surface real-time data. Apollo for contact and signal data, Clay for enrichment and trigger detection, the CRM for activity and engagement. The project doesn’t need to live inside those tools, but reps need a clean handoff: signal surfaces in Apollo, gets pasted into the project, gets turned into a brief and a message, gets actioned by the rep.

How to Build a Signal-Based Outbound List in Clay covers the front end of that workflow. The Claude project sits on the back end, turning signals into action.

Step 5: Run it for a month before judging it.

The first week is rough. The output isn’t quite right, the instructions need tuning, the inputs reveal gaps. By week three or four, if you’ve been iterating, it starts to genuinely work. The reps who stick with it are the ones who treat it as a tool they’re shaping, not a magic box they’re testing.

---

What this isn’t

It isn’t an AI SDR. It’s not sending its own messages, booking its own meetings, or operating without human judgment. Every output goes through a rep who decides whether to use it, edit it, or ignore it.

It isn’t a substitute for thinking. Reps who use it as a thinking shortcut produce worse work than reps who use it as a thinking accelerator. The judgment still has to be theirs.

And it isn’t a one-time setup. The project gets better the more you use it, refine the inputs, update the instructions, and add new interaction examples. Treating it as “set up once, use forever” produces a tool that goes stale within months.

---

Why this matters more than the latest tool

The AI-tool-of-the-week pattern in sales is exhausting. Every week there’s a new platform, a new category, a new pitch about how this one is different. Most of them are not different in any way that matters.

A Claude project built on your specific business is different in the way that matters: it’s yours. It encodes how you sell, who you sell to, what works in your specific context. It compounds in value the longer you use it. It doesn’t depend on a vendor’s roadmap or pricing decisions. And the skills your team builds operating it transfer to whatever the next generation of tools looks like.

This is what I mean when I say AI in sales is a workflow shift, not a tools shift. The teams that win the next few years will be the ones that built proper internal capability with AI, not the ones with the longest list of subscriptions. The Claude project is one of the most concrete starting points for that capability.

---

For the bigger picture on where this is heading, The Fullstack Salesperson Returns covers what B2B sales looks like in five years and why this kind of build matters now. For the proposal-side workflow that pairs with this, From Meeting to Proposal in Hours covers how the same approach compresses the meeting-to-proposal gap. For the manager-side counterpart, The AI-Augmented Sales Manager covers how to systematise the FAQ work that takes managers off novel problems. And the AI & RevOps page covers the broader principles. If you’d like help building one of these for your team, get in touch.