Sales Brain

Inside this Project, Claude carries the organisation's sales context:

• The context register — every knowledge file, what it is authoritative for, who owns it, and how current it is.
• The proof library with each entry's approval status, so customer-facing drafts use only what has been cleared.
• The playbook, ICP, positioning and voice rules every job is grounded in, so the tenth seller to use the workspace gets the same facts as the first.
• Approved learnings from calls and campaigns, once the context owner has accepted them into a file, together with the decisions log of watch items and rejected proposals, so the same idea is not re-argued without new evidence.

Treat the knowledge files as the record. A learning that lives only in one person's chat does not reach the rest of the team; one written into an approved, dated file does.

Run one Project per organisation — or per business unit, where units sell different products to different buyers. Splitting further brings back the problem this workspace exists to solve.

Reach for this Project when:

• Several people on your team run AI-assisted sales work and each is re-explaining the same product, ICP and positioning from scratch.
• You want outreach, follow-ups and objection responses to draw on the same approved proof rather than whatever each seller remembers.
• You have call transcripts and campaign results and want what they show captured once, for everyone.
• You are onboarding sellers and want them working from the organisation's real context on day one.

Use something else when:

• You are working one strategic account over months — that is Account 360 Builder. This Project holds what is true of your organisation; that one holds what is true of one account.
• You are running a standing outbound programme with its own pattern memory — that is SDR Outbound Engine.
• You need full battlecards with sourced claims — that is Competitive Battlecard Builder. Keep a one-page competitive summary here and the library there.
• You are preparing to coach a named person — that is Manager Coaching Studio. Call review here looks at the buyer and the message, never the seller.

Related resources:

• Setup companion — Build Your AI Sales Brain, a prompt chain whose first step drafts a structured sales playbook. Run it first if you have no written playbook, then upload the approved result here.
• Cowork variant — Set Up Your Cowork Sales Workspace, the same foundation built as a folder and a CLAUDE.md file that Claude Cowork reads at the start of each session.
• Related workflow — Claude Marketing & Sales OS Foundation — Onboarding Workflow, a four-step workflow for setting up and onboarding a team onto a shared marketing and sales Project.

Once, to set the workspace up, you provide the core files: sales playbook, ICP and personas, positioning and messaging, proof library, outreach and voice rules, and a competitive summary — each with an owner and a date.

Then, per job, you provide:

• Outreach — the persona, the account, and one specific, dated fact about the prospect with its source.
• Campaign review — results by segment, message and channel: sends, replies, meetings. Aggregated figures, not contact-level exports.
• Call review or follow-up — the transcript or detailed notes, with personal details removed.
• Objection response — the objection in the buyer's own words, and the deal context it came up in.

The prospect fact is the input most often skipped. Without it, Module 1 returns a gap statement rather than a draft — by design, because a generic first touch sent under your organisation's name costs more than it gains.

The proof library prevents more damage than any other file. Without it, every draft either carries no proof or tempts someone to improvise a figure — and an improvised figure, once it reaches a customer, is very hard to take back.

Project files are limited to 30MB each, and there is no fixed limit on how many you add. How much of the knowledge Claude works with at once depends on your plan — on paid plans, large project knowledge is searched by retrieval rather than read in full — so fewer, sharper files beat a full archive, and a clearly named, single-subject file is far easier to find and cite.

Prepare files this way:

• Strip cover pages, legal boilerplate, and navigation chrome — they consume context and carry no signal.
• Prefer text formats. A clean export beats a scanned PDF.
• Name each file for what it contains, not when you exported it. Claude reads filenames.
• One subject per file. A merged reference document is harder to cite precisely.
• Date anything that goes stale, inside the file itself, so Claude can tell you when it is working from old material.

Two additional rules for this Project. Put the owner and the date at the top of every core file — the context register reads them from there, and a file without them is reported as ownerless. And prefer redacted call excerpts or detailed notes over full transcripts: the learning is in what the buyer said about their problem, not in the small talk, and less material means less personal data to protect.

1. Gather or build the core files. If you have no written playbook, run the first step of Build Your AI Sales Brain to draft one, then have the context owner correct and date it. A playbook generated from your website is a draft, not an approved source.
2. Create the Project and paste the Project Instructions. Name it for the organisation or business unit — for example Sales Brain — Fenmore EMEA.
3. Replace the three bracketed fields. The context owner matters most: without a named owner, conflicts and update proposals have nowhere to go.
4. Upload the core files, proof library first, each with its owner and date at the top.
5. Run the context check. Fix what it flags before inviting the team. A team that meets a Not ready workspace on day one rarely comes back.
6. Share deliberately. On Team and Enterprise plans, give the context owner Can edit and everyone else Can view. Anyone with edit access can change the instructions and knowledge for everyone.
7. Run one real job for each module you plan to use, and check every citation against the file it names. That pass shows whether your files are strong enough to work from.

Allow about 45 minutes if the core files already exist. If they do not, building and approving them is the real work, and it is worth finishing before anyone relies on this workspace.

The bracketed fields below are placeholders you replace with your own details before you save the instructions. Leaving them unfilled produces generic output — that is the single most common reason a Project underperforms in its first week.

This Project has three:

• [FILL IN: Company Name] — your employer, or the business unit this workspace serves.
• [FILL IN: Context Owner] — the named person, or role, who approves changes to the knowledge files and resolves conflicts between them. Without one, update proposals pile up unanswered and the workspace drifts away from what the team has learned.
• [FILL IN: Approved Claims Source] — where approved proof and customer-facing claims live, and who owns them. Name the document or the person, or say explicitly that no approved list exists — in which case every proof point is treated as internal-only until a human clears it.

The bracketed inputs in the commands — [PERSONA], [ACCOUNT], [OBJECTION] and [TOPIC] — are filled each time you run a job, not in the instructions.

Role

You are the sales context steward for [FILL IN: Company Name]. This workspace holds the organisation's playbook, ICP, positioning, proof, live campaigns and call learnings, and you run whatever sales job is asked against them — citing the file behind every claim.

Operating rules

• Every claim is labelled Supplied, Inferred or Unknown, and Supplied claims name their file.
• Never invent a customer name, metric, quote, case study or ROI figure.
• Only proof approved for external use goes into customer-facing drafts.
• Nothing learned from one customer appears in output for another.
• Learnings become context update proposals with evidence; a named owner approves them and a human applies them.
• Draft only — nothing is sent or written to a system from here.

One context, seven jobs

Context check · outreach draft · campaign results review · call review · objection response · follow-up · context update proposal.

The full instructions continue with the context register and readiness rubric, the output format for each module, the commands, the boundary with job-specific Projects, and escalation.

This Project produces seven deliverables, each with a defined format:

• Context check — the register, a readiness band, conflicts between files, and the top three gaps.
• Outreach draft — a first touch anchored on a supplied prospect fact, with an anchor note citing every file used.
• Campaign results review — what the data shows with sample sizes, explanations labelled as inferences, and one defined test.
• Call review — what the buyer said, in their words, and whether it confirms, contradicts or adds to the context.
• Objection response — the testing question, a response grounded in the playbook, approved proof, and any commitment flag.
• Follow-up — a short email built on what the buyer said, with the next step, owner and date.
• Context update proposal — evidence-backed changes to the knowledge files, for the context owner to approve or reject.

A context check, followed by a context update proposal. Fenmore Analytics is fictional.

Context check — Fenmore Analytics · 14 October 2026

Readiness: Partial. Five of six core files are present; the competitive summary is missing, and the proof library is past its refresh interval.

Conflicts

1. Mid-market definition. icp-and-personas.md (15 Jul) defines mid-market as 200–1,000 employees; positioning-messaging.md (2 Sep) says 100–750. The register names the ICP file as authoritative for segments, so drafts use 200–1,000 and say so. Flagged to the context owner; product marketing owns both files.
2. "41% faster onboarding." The figure appears in positioning-messaging.md but not in proof-library.md. It will not be used as proof until it is added to the library with an approval status.

Top three gaps

1. Refresh the proof library. Until then, every proof point in a draft is flagged as resting on a stale file.
2. Add a one-page competitive summary. Objection responses that turn on a competitor will return Unknown until it exists.
3. No call material yet. Objection wording comes only from the playbook, not from real buyers.

Verify before use: check that each date in the register is the file's last review, not its export date, and confirm the mid-market definition with product marketing before drafts rely on it.

Context update proposal — from q3-campaign-results.csv

Watch item, not proposed: three replies mentioned already owning a BI tool. That is below the five-reply threshold, so it is logged rather than proposed as an ICP change.

For approval by: Head of Revenue Enablement, as context owner.

No file has been changed. The proposal stands until the context owner accepts or rejects it and records the decision in the log.

Verify before use: RevOps confirms both variants went to comparable lists in the same segment, and the context owner checks the decisions log for an earlier ruling on email length.