What is a sales playbook?
A sales playbook is the operating manual for your sales motion — ICP, qualification criteria, discovery questions, demo flow, objection handling, pricing, and the contract motion. Done right, it’s the document that lets a new AE ramp in 30 days instead of 90. Done wrong, it’s a 60-page deck that no one reads after week one. Here’s what goes in it, what gets cut, and how to write one your AEs actually use.
TL;DR
- A sales playbook is an operating doc, not a deck. AEs reference it during deals, not just during onboarding.
- Length: 10-20 pages for early-stage. Anything longer is filler.
- Sections: ICP, qualification, discovery questions, demo flow, top 10 objections + responses, pricing, contract terms.
- Build it after closing 10-20 deals yourself. Pre-deal playbooks are theory; post-deal playbooks are pattern-recognition.
- Update quarterly. Markets shift, ICPs evolve, objections change. A frozen playbook becomes wrong within 12 months.
- Test the playbook on a real AE. If they can’t use it to run a discovery call without coaching, it’s not done.
What a sales playbook actually is
A sales playbook is the codified version of how your company sells. It’s the answer to “what should a new AE do in week one” and “how do we run discovery for the healthcare segment” and “what’s our response when a prospect says they’re evaluating us against Outreach.”
A playbook is not:
- A pitch deck (that’s for prospects)
- A product training (that’s separate, longer, more technical)
- An aspirational document about how you wish you sold
- A 60-page binder produced once and never updated
It is:
- A working operating manual the sales team references during live deals
- Specific enough to answer “what do I do next” in any normal deal scenario
- Short enough that AEs actually read it (10-20 pages, not 60)
- Updated quarterly as the motion evolves
When you write the playbook
The mistake most founders make: writing the playbook before they’ve sold anything. The result is a document full of guesses about what the sales motion should look like, which the first real AE then has to debug from scratch.
The right timing: write the playbook after the founder has personally closed 10-20 deals, ideally across at least 2-3 ICP variations. At that point you have real pattern recognition: you know which objections come up, which discovery questions actually surface decision criteria, what the demo flow needs to cover, and where deals die.
The playbook is the codification of the founder’s pattern recognition, not the founder’s prediction of what sales will look like. Write it from real deals, not from theory.
The standard playbook sections
A working B2B SaaS playbook has 7-9 core sections. Each is 1-3 pages.
1. ICP (Ideal Customer Profile)
The crisp definition of who you sell to. Not “B2B SaaS companies” — too broad. Specific:
- Company size (employee count, revenue range)
- Vertical or sub-vertical
- Stage (Series A-D)
- Buying signals (recent hiring, funding, tech stack, etc.)
- Anti-ICP (who you do NOT sell to, even if they ask)
The anti-ICP section is the most-overlooked part. Without it, AEs chase deals that close at 5% close rates instead of disqualifying. See closed-won deconstruction for the methodology.
2. Qualification criteria
The 3-7 things that must be true for a deal to be qualified. Stated as binary yes/no questions where possible:
- Is the prospect in our ICP? (size, vertical, stage)
- Do they have the specific problem we solve, in their words?
- Is there a clear economic buyer identified?
- Is there a timeline (within 90 days)?
- Is there budget allocated or available?
Different qualification frameworks (BANT, MEDDIC, SPICED) provide structures for this. Pick one and adapt it. See qualification frameworks.
3. Discovery call structure
The 30-minute discovery call architecture — opening, qualifying questions, value frame, next-step ask. The 15-20 discovery questions that surface the criteria above.
Specific questions, not categories. Not “ask about their current solution” but “What are you using today to handle X? What works about it, what doesn’t?”
See discovery call architecture.
4. Demo flow
The 20-30 minute demo structure. What screens to show, in what order, in response to what the prospect surfaced in discovery. Not a fixed canned demo; a flow that adapts based on which use case is in play.
Include: the 3-4 demo variants for different ICP segments, the “wow” moments to lean into, the screens to skip if time-constrained, the multi-stakeholder demo choreography.
5. Top 10 objections + responses
The objection library. The 10 most common objections AEs hear, with the 1-3 paragraph response for each:
- “We’re already using [Competitor]”
- “Too expensive”
- “We’re not ready, maybe next quarter”
- “We need to think about it / talk internally”
- “Can you build [X feature]?”
- “Security/compliance concerns”
- “We’ll just build it ourselves”
- “Send me a deck/proposal”
- “Wrong person — let me forward”
- “Not interested”
For each, the response includes: the acknowledgment, the reframe, the question that surfaces the real concern. Not a sales script; a structured response that AEs adapt. See objection handling.
6. Pricing and packaging
The pricing model (per-seat, per-usage, tiered), the price points for each tier, what’s included, what’s an add-on. The discount discipline — when AEs can discount, by how much, who has to approve.
For early-stage startups: pricing should be in the playbook even if it’s “starts at $X, negotiable.” A new AE shouldn’t have to guess.
7. Contract motion
The contract flow from verbal yes to signed. What MSA template to use, what redlines are acceptable and which require legal, what payment terms are standard (Net 30 most common), how to handle multi-year and discount packages.
8. CRM / pipeline hygiene
The operational rules. How to log calls, how to update opportunity stages, what counts as “qualified pipeline,” how to forecast, when to mark deals lost. Boring but load-bearing — without it, the pipeline data is unreliable and forecasting collapses.
9. Tools and resources
The tooling map. Where to find what — call recordings, case studies, security docs, customer references, the proposal template, the discovery questionnaire. Links, not file paths.
What gets cut
Things that bloat playbooks without adding value:
- Company history / mission / values: belongs in the company handbook, not the sales playbook.
- Product roadmap: belongs in product docs. Changes too fast for the playbook.
- Comprehensive product training: separate doc, separate process.
- Industry overview / market analysis: AEs should know this, but it doesn’t belong in the playbook. Belongs in onboarding training.
- Detailed personas with stock photos: AEs don’t use these. ICP is what they reference.
- Aspirational content: “Here’s how we’ll sell once we have product X.” If it’s not real yet, it’s not playbook content.
The 12-page playbook
An early-stage B2B SaaS playbook can fit in roughly 12 pages:
| Section | Pages | Why |
|---|---|---|
| ICP + anti-ICP | 1-2 | Who to chase, who to disqualify |
| Qualification | 1 | 5-7 binary questions |
| Discovery | 2 | Call structure + question bank |
| Demo flow | 1-2 | Per-variant structure |
| Top 10 objections | 2-3 | The most-referenced section |
| Pricing | 1 | Tiers, discount rules |
| Contract motion | 1 | MSA, redlines, terms |
| Tools / CRM | 1 | Links, hygiene rules |
How AEs actually use the playbook
A well-used playbook gets opened 3-10 times per week per AE. The use cases:
- Pre-discovery prep: AE reviews the discovery question bank before each call (2-5 min).
- Mid-deal objection: AE encounters a competitive objection in a call and pulls up the objection library afterward to plan response (5-10 min).
- Pre-demo prep: AE pulls up the demo flow for the relevant ICP variant before each demo (3-5 min).
- Pricing question from prospect: AE references the pricing tier and discount rules to respond accurately (2 min).
- Onboarding: new AE reads the full playbook in week 1, then references continuously through ramp.
If the playbook isn’t being opened, one of two things is wrong: either the content isn’t useful (too theoretical, not specific enough) or the discovery is happening in some other format (Notion docs, Loom videos, Slack threads). Either way, the playbook needs work.
Updating the playbook
A playbook frozen at write-time becomes wrong within 12 months. The market shifts, product changes, ICP evolves, competitive landscape moves. Updates need a cadence:
- Quarterly review: 60-90 minute meeting with the sales team. Identify what’s changed, what’s wrong in the current playbook, what’s missing.
- Objection library refresh: monthly. New objections come up; old ones become stale. Add and remove.
- Pricing/packaging: anytime pricing changes. Same-day update.
- Demo flow: monthly review. Product changes drive demo flow changes.
The owner is usually the head of sales (or the founder, pre-VP-Sales). One person has final edit rights to keep voice and structure consistent.
Playbook anti-patterns
- 60-page PDF that no one opens. The most common failure mode. Length kills usage.
- Written by someone who hasn’t sold the product. Reads as theory. AEs ignore it.
- One-time creation, never updated. Becomes wrong, AEs stop trusting it, then stop using it.
- Written as a deck, not a doc. Decks are bad reference material. Make it text + tables.
- Filled with marketing-style language. “Our innovative solution leverages cutting-edge AI” — meaningless. Use the language AEs actually use in calls.
- No anti-ICP. AEs chase every prospect that walks in the door. Close rate drops.
- Pricing not included. New AEs guess at pricing or have to ask their manager every time.
Where this fits
The playbook is the deliverable that converts founder-led sales into a repeatable motion. Before there’s a playbook, every deal is the founder’s — the knowledge of how to sell exists only in the founder’s head. The playbook is the document that lets that knowledge transfer to AEs, which is the gate between founder-led sales and a sales org.
The natural sequence: founder-led sales through the first 10-30 deals, then write the playbook, then hire the first AE against the playbook. Each stage assumes the prior one. The playbook is the bridge.
Allston Labs operates the full sending estate as a service.
We provision domains, configure the entire authentication record set, run warmup, and monitor reputation across providers. The stack lives under your entity. The engineer on call lives in your Slack.