I build revenue systems by four rules: start with the number, automate what repeats, keep a person on every write, and test small before expanding. The opinion is that the person who builds a sales system should have sold with one.
Each rule has its own section. They’re in the order I’d apply them.
In this guide
- Start with the number: what should move before you build anything
- Automate what repeats, and keep one-off work manual
- AI drafts, people decide: the approval rule behind every agent I build
- Test it small, then expand only what works
- Why sales systems should be built by someone who sells
Start with the number: what should move before you build anything
The first rule I work by is simple: if we can’t name what should move, we’re not ready to build.
It sounds obvious, and it is often skipped. A team buys a tool, sets up a workflow and then asks what it was for. A number written down first gives the project a finish line and gives everyone a way to say no to extra work.
What counts as a number
- Days from first call to proposal.
- Share of open deals with a next step and a date.
- Forecast accuracy against what closed.
- Hours a week spent on a task nobody likes.
These are examples of the kind of number I mean. They are not claims about any company’s results.
Two questions before you build
- What is the number today, and where does it come from?
- What would we see in a month if this worked?
If you can’t answer the first, measuring comes before building. If you can’t answer the second, the project is still an idea.
The catch
A number can be wrong. Pick one that you can measure with data you already have, and be ready to change it after the first look at the real figures.
Related: Find your ideal customer in the deals you already closed
Automate what repeats, and keep one-off work manual
Not everything should be automated. My test is short: if a task repeats, build it once. If it doesn’t, do it by hand.
Automation has a setup cost and a maintenance cost. A task you do every week pays that back. A task you do once never does, and an automation built for it becomes one more thing to maintain.
A quick test
- Has this happened at least three times?
- Will it happen again next month?
- Can you describe the steps in plain words?
Three yeses mean it is a good candidate. If you can’t describe the steps, you are not ready to automate them. Write them down first.
Start with the dull tasks
Research before a call, call notes, CRM clean-up and a weekly summary are repetitive, low-risk and easy to check. That is where AI drafting fits. Judgment calls, pricing and anything that changes how a customer is treated stay with a person.
The catch
Even a repeated task needs a person on the write. Automate the draft, not the decision.
AI drafts, people decide: the approval rule behind every agent I build
Every agent I build follows one rule: it drafts, and a person decides. Nothing is sent and no CRM record changes until someone approves it.
That sounds slow. It isn’t, because the agent does most of the work before a person looks at it. My rule of thumb is 80/20. The agent does about 80 percent. I do the other 20 percent, which is checking it for made-up facts and weak writing before it leaves.
How a run flows
- A trigger starts the run: a schedule, a new deal, a call transcript or a question.
- The agent reads one shared configuration and pulls the records it needs.
- It drafts the result with the evidence behind each claim.
- The draft waits in an approval queue.
- A person approves, edits or rejects it. Only then does anything reach the CRM, an inbox or a customer.
Three details that make it work
One setup, shared. A single interview captures the target customers, buyer personas, competitors, field mapping, email voice and guardrails. Every agent reads it, so no agent asks the same question twice.
Evidence on every claim. Each statement an agent makes carries a quote, a link or a record it came from. If I can’t see where a claim came from, I don’t send it.
Changes shown as a table. Proposed CRM edits appear as a table of before and after. I apply them after I read them, not before.
The catch
The approval step is work, and it is the work that matters. An agent will sometimes state something that sounds right and isn’t. A person who reads the evidence catches it. A system that skips that step ships it.
Test it small, then expand only what works
The last rule I work by is to test small and expand only what works.
A short pilot is cheaper than a rollout that doesn’t fit. It also gives the team a chance to say what is annoying before it is built into everything.
What a pilot should answer
- Did the number move, and by how much?
- Did the team use it without being chased?
- What did it get wrong, and who caught it?
- What would we drop?
How to keep it small
- One number.
- One team or one pipeline.
- A fixed length, written down before you start.
- A date to decide what to keep.
Why I keep a person on the write
A pilot is also where you learn how often the AI draft needs a fix. If people approve everything without reading it, the approval step has stopped working. That is a finding too.
The catch
A small test can mislead you. A pilot with a few deals tells you about those deals. Treat the result as a reason to try a bit more, not a proof.
Why sales systems should be built by someone who sells
I’ve carried a quota for 26 years. More than ten of those were inside engineering and tech startups, where the seller is also the person who sets up the CRM, writes the pitch and works out who to call next.
That experience shapes how I build. Here is the opinion it left me with: sales systems work best when the person who builds them has used them under pressure.
What it changes
- Fields earn their place. A seller who has filled in a form at 5pm asks whether it is needed.
- Stages describe what happens. They aren’t an org chart of the process.
- Reports answer the question a seller would ask next, not just the one a manager asked last.
What it doesn’t mean
A seller who builds systems can build the wrong ones. A background in sales is not proof of good design. It is a reason to ask the right questions early, and to test the system with the people who will use it.
Both sides of the table
For the last several years I’ve worked in battery power for drones and defense, as both a competitor and a supplier. Seeing a market from both sides is useful when you design how a team qualifies and scores accounts.
Where to go next
If you want this built around your own pipeline, email me or see RevLathe. If you’re hiring for BD or RevOps, start here.
I’m Seth Levanen. I find the AI shortcuts that keep the quality and drop the busywork. Email me if you want to talk about it.