How to build a sales process your team can run without you

A sales process your team can run is about four documents, not twelve.

And you do not write them by deciding how selling should work. You write them by looking backwards at the deals you already won, which means most of the work is reading rather than thinking.

Why sales playbook templates fail

Download a template and the first question is usually some version of “what are your discovery questions?”

The honest answer is that they change every call. So the founder fills in what sounds right, the rep follows it, and it does not work, because it was never what closed anything. It was what someone believed a good discovery call looks like.

I have watched founders spend a full day on a twelve-section playbook and produce a document nobody opened twice. The problem was not effort. It was direction. They were describing an idealised process instead of documenting a real one.

Start with the last ten deals you won

Pull your last ten closed-won and your last ten closed-lost. Read the notes properly, not the summary fields.

You are looking for one thing: what was true in every win and absent in every loss.

Some of what you find will be uncomfortable. Often it is something you would not have chosen as a qualification criterion, like the buyer already having a failed attempt at solving the problem, or a specific person having been in the first meeting. Those are the useful ones precisely because you would not have invented them.

Around 70% of first sales leadership hires do not work out, according to Jason Lemkin’s surveys at SaaStr. Most of that failure is hiring someone into a system that was never written down. This exercise is what stops that.

Document one: what a real opportunity looks like

Not a persona document. Three or four conditions that were true in every deal you won, phrased so a rep can check them on a first call.

Include the disqualification side. Telling someone what to walk away from is more useful than telling them what to chase, and it is the half that never gets written. A rep who knows what to kill will build a smaller, more accurate pipeline. That looks worse for a month and better for a year.

Document two: the five objections and the words that worked

You have answered the same five objections a hundred times. Write down the actual sentences that worked.

Not a framework for handling objections. Not “acknowledge, isolate, respond.” The words.

There is a real difference between the two, and it is why most sales enablement material is useless. A framework tells a rep what shape their answer should take. It does not tell them what to say when a buyer asks why you cost more than the incumbent they have used for six years.

#TCCRecommends: Objection handling techniques for B2B SaaS sales

Document three: stage exit criteria tied to buyer actions

A deal moves forward when the buyer does something. Not when the rep feels good about it.

The criteria that actually predict:

• Brought someone new to a call
• Asked about implementation or onboarding
• Requested pricing in writing
• Named a date

Notice what is not on that list. “Sent proposal” is a seller action. “Asked for a proposal” is a buyer action. Only one of them tells you anything, and most CRMs are configured to track the wrong one.

This is the same failure the pipeline post describes from the other side. Stages that measure hope produce a full pipeline and flat revenue.

Document four: the pricing decision tree

The one nobody writes down, and the one that most often blocks the handover.

What a rep can offer without asking. What needs approval. What is never on the table.

Without this, the founder stays on every call that reaches pricing, which is every call that matters. The rep runs discovery, builds rapport, and then hands the deal back at the exact moment it becomes a deal. That is not a sales process. It is a lead qualification function with a salesperson’s job title.

Writing this one down is uncomfortable because it forces decisions you have been making case by case. That discomfort is the point.

How to know it is working

Two tests, both binary.

A new rep closes a deal with the founder not on the call and not in the thread. Not advising in the background. Absent.

Two different reps describe your qualification rule the same way, without checking the document. If they give you two different answers, the rule exists on paper but not in the team.

Fail either and you have a document, not a process.

Common questions

---

Close

You are not designing a process. You are writing down the one you already run.

That is less creative and far more useful, and it is what we do in Get Booked.