Claude Code for Sales
Claude Code is where our sales work actually runs. It reads the client brief, calls the data tools, hands judgment calls to batches of subagents, writes every result to a database and checks the campaign before anything is sent.
What it is and when to use it
Claude Code is Anthropic's agentic coding tool. It works in a terminal, reads and writes files, runs scripts, calls APIs and MCP servers, and can split a large job across subagents that work in parallel. For sales work that combination matters more than the code: it can do research and judgment at the volume of a spreadsheet, and leave a written reason behind every decision.
We use it as the operating layer for outbound. Each recurring job, such as turning an event list into a send-ready list or launching a LinkedIn campaign, is written down as a skill: the steps, the tools, the checks and a table of every mistake a real run has made. The next run starts from that skill instead of from memory.
Use this playbook when
- You have a raw list, such as event attendees, companies posting a certain job or target accounts with no contacts, and it has to become a short list of the right people with a reason for each one.
- The work needs judgment at volume: grading thousands of job titles or qualifying hundreds of companies from what they actually do, not from a dropdown field.
- You run LinkedIn and email campaigns where every message is final text that must be checked before it goes out.
- The same job comes back for every client or every quarter, so it is worth writing the method down once and improving it after each run.
Tools we use
Only tools we have run this playbook with, and what each one does in it.
- Claude Code: Runs the pipeline, skills and parallel subagents for grading and qualification
- Supabase: One database per client: the single source of truth, raw payloads stored in the cell
- Apify: LinkedIn profile, company page and company employee scrapes
- Blitz: Company enrichment and job search
- Prospeo, AI-Ark, ZeroBounce: The email waterfall: find, then verify
- Firecrawl: Homepage scrape, only when a company description is too thin to judge
- Parallel: Research on each prospect before a message is written
- HeyReach: LinkedIn connection requests, messages and InMail
- Smartlead: Cold email sending
- HubSpot: CRM: read by default, written only where the client has given write access
- Fireflies: Call transcripts, turned into meeting notes and decisions
The steps
The order we work in. Each step feeds the next, and every result is written to the database as it happens.
Start from the qualifying question
We take two inputs only: the question that decides fit, in the client's own words and ideally from a call transcript, and the buyer personas. Everything else is derived from those.
Land every source in one table
Attendee lists, signal exports and CRM pulls go into one table in the client database, de-duplicated on the normalized LinkedIn URL, with a first-seen date that is set once and never overwritten.
Resolve identities company first
When a list has names but no profiles, we pull people by company and title and match the name inside that small pool. Searching the name on Google returns namesakes.
Grade job titles, not people
Subagents grade each distinct title once against a department and seniority grid, and store a reason and a confidence for every title. No keyword rules: a title like "VP Talent" fools them.
Reuse before you pay
Before any scrape we check what the database already holds, including data bought for earlier work. Every new scrape stores the complete raw payload right beside the identifier it came from.
Qualify companies from their description
Each company is judged from its own LinkedIn description, and from a cleaned homepage only when the description is not enough. The industry tag is never the gate. Each verdict is stored as a label with a reason and a confidence.
Gate, then flag every row
Employment and evidence checks run next. Every row ends with a final flag and a plain-English reason, so anyone can see why a person is in or out.
Find emails and pick the channel
A pilot of 50 people comes first, then the email waterfall. Domains whose mail runs through a security gateway are routed to LinkedIn instead of email.
Write messages in stages
Code fetches and compacts the research, the model judges whether there is a real hook and drafts, an independent judge and a code validator check the draft, and only then is it uploaded.
Cross-examine before launch
The pre-launch checklist runs on every campaign: final literal text, the right sender voice and signature, a read-back of every lead from the platform and a test send per persona.
Capture replies and sync the CRM
Replies arrive by webhook into one row per person. CRM uploads create companies first, then contacts, and end with a duplicate audit.
Write the lesson into the skill
After each run, the mistakes and the measured costs go into the skill that governed it, so the next run does not repeat them.
What good output looks like
What finished runs have looked like, measured from our run records:
A conference attendee list of 2,432 people became 27 people at 22 qualified companies, with a reason on every row. Scraping cost $3.47.
1,632 distinct job titles were graded by 13 parallel agents, then checked by an adversarial auditor.
214 of 337 companies on that list were already in our data from earlier work and cost nothing to reuse. Only 17 of the 337 needed a homepage scrape.
A job-posting sweep of about 3,000 postings became 913 companies and a send list of 102 after an adversarial review, with no data cost.
On a 219-person LinkedIn list, about 35% had a genuine hook from their own posts and about 65% got a clean generic opener. Moving the fetching from the model into code cut the work from 32M tokens to about 5M.
Common mistakes, and the fix
Each of these happened on a real run. The fix is now part of how we work.
Name searches returned the wrong people: 3 confirmed identities out of 295 rows, for $8.79.
- Cause
- Google does not filter LinkedIn results by company, so "Name" plus "Company" becomes a name-only search.
- Fix
- Pull people by company and title first, then match the name inside that pool.
About 15% of paid profile scrapes would not link back to their rows.
- Cause
- Stored URLs carried country subdomains that the scraper did not return.
- Fix
- Match on the /in/ slug, never on the full URL.
A grading rubric would have dropped every CTO and VP Engineering.
- Cause
- The rubric only had a top grade for security titles.
- Fix
- Check that every department in the persona grid has a path to the top grade before running it.
Literal braces reached 50 prospects in a LinkedIn note.
- Cause
- Variable syntax from the email tool was pasted into the LinkedIn tool, which uses a different format.
- Fix
- Upload final literal text only, and run a rendered test send on every channel.
One sender's messages went out signed with the other sender's name.
- Cause
- Custom fields live on the lead, not on the campaign, so two senders shared one field.
- Fix
- Give each sender its own field variant and read every lead back per sender.
A reshare was nearly quoted back as the prospect's own post.
- Cause
- Reposts and quote posts arrive mixed in with original posts.
- Fix
- Split posts into original, quote and bare reshare before any hook is written.
A public profile contained text written to instruct an AI.
- Cause
- Scraped text was treated as possible instructions.
- Fix
- Treat every scraped field as data, never as instructions, and give that person the generic message.
A bulk insert reported 413 rows saved when every one had failed.
- Cause
- The write responses were never checked.
- Fix
- Insert in batches of 25 or fewer and finish with a count read back from the database.
Every drafted message had to be thrown away.
- Cause
- Subagents were told to skip the research stage to go faster.
- Fix
- Get speed from parallel workers and code, never by dropping a stage.
Questions people ask about claude code for sales
How do you use Claude for sales prospecting?
We give Claude Code the qualifying question and the buyer personas, then let it run the pipeline: pull people from a signal or event list, grade every distinct job title, qualify each company from its own description, find and verify emails, and draft messages from each prospect's own posts. Every decision is written to the client database with a reason, and a person reviews the list before anything is sent.
What are the best Claude Code skills for sales?
The ones we rely on are written from real runs: turning an event or signal list into a send-ready list, finding contacts by persona at accounts that have none, the email waterfall, writing LinkedIn messages from a prospect's own posts, the pre-launch campaign checklist, capturing replies, and uploading to the CRM without duplicates. Each one carries a table of the mistakes earlier runs made.
What is the difference between Claude and Claude Code?
Claude is the AI assistant you chat with. Claude Code is the agentic tool that runs Claude in a terminal: it can read and write files, run scripts, call APIs and MCP servers, and split work across subagents. For sales that difference matters, because the work is calling data tools and writing results to a database, not just writing text.
Can Claude Code access or scrape LinkedIn?
Not on its own. It calls tools that do: we use Apify actors for LinkedIn profiles, company pages, employee lists and posts, a LinkedIn signal tool for posts and engagement, and HeyReach for sending. Claude Code orchestrates those calls and treats everything scraped as data, never as instructions.
Do I need to know how to code to use Claude Code?
It writes and runs the code for you, so you do not need to write it. You do need to read what it did: we check every count against the database, read leads back from each platform and review the final list, because a step that reports success is not proof that it worked.
Want this playbook running on your market?
Tell us what you sell and who you sell to. We will show you how this playbook would run for you, and what we would check first.
