M

How to Build a Zero-Headcount Revenue Team in Claude Code

7 min readView source ↗

Cover image

A revenue team does six jobs. Hire for all six and it's six people and six salaries.

We wrote ours as six text files instead. For one client, that system produced $7.83M in qualified pipeline, $1.52M closed-won across 164 deals, with zero new hires.

This is what we build at @Frontal_AI: AI-native revenue systems that add pipeline without adding people.

This piece shows you how to build one yourself.

The six jobs a revenue team does, how each becomes a file inside Claude Code, how they're wired so the whole thing runs as one motion, the rule that keeps the output usable, and the first prompt to run. Everything we run is written down here, so you can stand up your own version starting with a single file.

The six jobs to automate

Strip a revenue team down to what it does and you get six jobs.

We wrote each one as a specialist inside Claude Code, a plain text file you can open and edit. Here is what each owns, and the number that tells you it's working.

  1. Strategy: who to go after.

Article image

Scans your site, defines the ICP, and scores every account out of 100. It's the judgment layer. It decides which accounts are worth the motion's time before anything else runs. Get the scoring wrong and everything downstream chases the wrong accounts.

  1. Signals: when to reach out.

Watches for the triggers that mean an account is in the market now: a funding round, a new CRO, an SDR hire, a competitor's tool showing up in their stack.

This is the file that moves the numbers most.

A cold email reply rate sits around 3.43%. Fire the same outreach off a real signal and it runs 15 to 25%, with elite teams clearing 30%. Intent-qualified accounts also convert 47% better and close 43% bigger. One Fortune-500 subsidiary signed a contract past €200K off a single signal and a 73-second Loom.

  1. Data: who to actually contact.

Pulls verified contacts at the accounts that clear the bar. The real person attached to the signal, with an email that won't bounce. Enrich late, only on accounts Strategy and Signals already qualified, so you're not paying to enrich the whole world. We run it as a waterfall: one call cascades through 20-plus providers until it finds the email and phone, at 80%-plus find rates.

  1. Copy: what to say.

Writes the email off the exact signal it caught, so it references the real thing happening at the account. Copy tied to a real trigger pulls up to 54.7% more replies than a generic template. The angle is whatever moved at that account this week.

  1. Execution: running it.

Sends the emails, the LinkedIn messages, and the follow-ups in sequence, across channels, with nobody pushing each one out by hand. The same account worked across email, LinkedIn, and ads in one sequence gets a 287% lift over a single channel, because the buyer keeps running into you in three places. It also holds the deliverability rules: 30 to 50 emails per inbox per day, a four-step follow-up, no more.

  1. System: keeping it one motion.

Connects the other five so one conversation runs end to end. The signal fires, the contact gets pulled, the copy gets written off that signal, the sequence sends, the reply routes back. It's the orchestrator that ties the other five files together.

How it's wired

Six files left alone will drift apart in a week. What holds them together is two things: layers, and governance.

The system runs on two layers.

Master skills sit on top and route each request to the right specialist. Ask it to build a campaign and it hands the job to Strategy, then Signals, then Data, in order.

Reference files sit underneath and hold what your company knows: your ICP, your scoring rules, the signals you track, your templates. This is where your edge lives. Two teams can run the same six specialists and get different results, because their reference layers are different.

Under that, a few primitives do the work: rules that load based on what you're working on, skills that fire only when a task matches, subagents that each handle one job in their own context, and a memory file that carries what the system learns from one session into the next.

Governance is what makes it safe to run on real pipeline.

You keep the rules separate from the part that executes them, so an agent can't quietly rewrite its own instructions mid-run.

When it spots something worth changing, it files a proposal, and you approve it before it goes live.

Because it's all files, you change the system by editing one. Your ICP shifts, you edit the strategy file. A new signal starts mattering, you add a line to the signals file. You don't need an engineer for any of it.

Never let the model guess

Most AI outbound reads like a robot wrote it. Someone runs a good prompt on no data, the model fills the gap with something plausible, and a week later the reply rate shows it.

The rule we run on every prompt: never let the model guess.

Before any research or writing step, paste the raw data in first: their actual website copy, their LinkedIn profile, whatever jobs they have open.

It's the least exciting here, and most teams skip it.

The AirOps rebuild

We rebuilt how AirOps got in front of the buyer with three plays running off that system.

Signal-driven outbound. A rep only touched an account when a real trigger fired at it. If nothing was moving inside an account, nobody wasted a morning on it.

Thought-leader ads on LinkedIn. Paid placement that warmed the buyer before a rep showed up. By the time an email landed, the name was familiar.

A connected list. Engagement on one channel triggered the next play on another. Someone engaged with an ad, that fired a signal, that queued the outreach.

Ten months in: $7.83M in qualified pipeline, $1.52M closed-won, 164 deals. No new hires on their side, and every change we made along the way was to a file.

The 10-80-10 split

This isn't a case for pointing an agent at your funnel and walking away.

We once had a client paying $50,000 a year for a data platform nobody logged into. The tool was fine. Nobody ever actually used it.

Most founders now make that same mistake with AI. They buy an agent, point it at the whole motion, and wait for pipeline that doesn't show up.

So we run every account on a 10-80-10 split.

You own the first 10%: who to go after, what a good lead looks like, the angle. No model makes that call for you.

The system runs the middle 80%: the research, the data, the first drafts, the follow-ups. We build our own software on top so it keeps getting better at that part.

Then you own the last 10%: you read the work before a prospect does and cut what's weak.

We've never let an agent run a play start to finish. That last 20% is what clients pay us for.

Why not just hire a GTM engineer

The obvious move is to hire a GTM engineer for all this instead. Postings for that role jumped 205% last year, and most of those hires in fact become six-figure list-builders for the SDR team.

A file doesn't take a quarter to ramp, need a manager, or quit and take the playbook with it.

It also forces the one number teams avoid. When the motion lives in files, you can read it every day, by campaign: the pipeline it produced against what it cost to run.

Get the whole system

You don't have to build a revenue system such as ours from scratch. We put the entire thing in one repo: the six specialists, the orchestrator that ties them together, and all 52 sub-skills, ready to drop into Claude Code and point at your own site.

We built it for our own team first. Now it's yours for free.

Comment SYSTEM and I'll send it over. Must be following.

Related articles