By Siddharth GangalWhat a governed sales playbook is
A sales process names the milestones through which work moves. A playbook defines how people execute and govern those milestones. That distinction matters: a diagram that says “discovery, demo, proposal” cannot tell a rep whether discovery is complete, whether a demo is justified, which claim is approved, or who can authorize a nonstandard term.
This page owns the complete operating layer from first touch to close. It does not replace the narrower artifacts that belong at the point of use. Use the dedicated sales call talk track, sales discovery guide, demo script template, sales proposal guide, and call-closing guide as linked modules. Keeping those modules canonical prevents conflicting copies.
The CRM should reflect the model, not invent it. HubSpot’s official pipeline documentation describes stages as steps that signal where a record is in a process, while Salesforce describes opportunity stages as business milestones. Those are useful implementation primitives. Your team still has to define the evidence and authority behind each stage. See the HubSpot pipeline documentation and Salesforce opportunity guidance.
Start with the control page
Put governance before messaging. The first page should let a reader decide whether the playbook applies and whether it is current. Record: playbook name; motion and segment; included and excluded products, regions, channels, and deal types; accountable owner; content steward; functional approvers; version; effective date; next review condition; superseded version; and change log.
Add source fields beside claims that can expire: source URL or internal artifact, source owner, verified date, and review trigger. A product claim may expire after a release; pricing guidance after a packaging change; compliance language after counsel changes it. “Reviewed annually” is not enough when a material change happens tomorrow.
Safety boundary. The playbook can route decisions, but it must not impersonate legal, privacy, security, finance, or contracting authority. A qualified owner defines applicable rules. For example, the FTC’s CAN-SPAM business guide explains requirements for commercial email in the United States; it is not a universal outbound policy for every jurisdiction or channel.
Assign ownership and decision rights
For each controlled object—ICP, claim, message, qualification rule, stage, price, proposal term, security evidence, and close/handoff—name four things: the person who performs the work, the person accountable for the rule, the approver for exceptions, and the destination for escalation. Titles vary; decision rights should not.
| Object | Operator | Accountable owner | Evidence | Escalate when |
|---|---|---|---|---|
| Account selection | SDR/AE | Segment owner | ICP facts and trigger | Fit is ambiguous or restricted |
| Product claim | Seller | Product/marketing owner | Approved proof and expiry | Customer asks beyond evidence |
| Commercial term | AE | Commercial owner | Approved range and rationale | Request leaves authority band |
| Security response | AE coordinates | Security owner | Current approved artifact | Question is novel or sensitive |
| Closed-won handoff | AE | Delivery owner | Accepted handoff packet | Scope, date, or owner conflicts |
Do not hide shared accountability behind “everyone owns it.” One owner accepts or rejects the artifact; contributors remain visible. Add a backup for absences and a response target appropriate to deal risk.
Write stage contracts, not stage descriptions
A stage contract has six fields: entry event, required work, required evidence, exit decision, authority, and rollback rule. This converts a label into a test. A rep should be able to explain why a deal entered the stage and point to the evidence that allows it to leave.
| Stage | Entry | Required evidence | Exit |
|---|---|---|---|
| First touch | Approved account, person, purpose, and channel | Fit basis, source, suppression/policy check, message version | Valid response, qualified meeting, nurture, or stop reason |
| Qualification | Two-way engagement or accepted inbound | Problem, fit, authority path, timing context, disqualifiers | Proceed, recycle, disqualify, or escalate ambiguity |
| Discovery | Qualification threshold met | Current state, impact, desired state, stakeholders, decision path | Mutual problem statement and agreed validation step |
| Demo/validation | Use case and audience known | Scenario map, proof source, questions, gaps and follow-ups | Customer confirms fit/gap and next evaluation action |
| Proposal/commercial | Scope and buying path sufficiently known | Scope, assumptions, price authority, approvals, decision date | Accepted, revised under control, paused, or closed-lost |
| Close/handoff | Required agreement and approvals complete | Signed artifact, obligations, risks, owners, dates, CRM reconciliation | Delivery accepts packet or seller remediates gaps |
Configure CRM stages only after agreeing these contracts. Otherwise mandatory fields become clerical gates. If a field cannot support a decision, forecast, handoff, or audit, challenge why it exists. If evidence can change, record its timestamp and source rather than treating it as permanent truth.
Govern channel plays without duplicating scripts
A channel play is an index card, not a universal script. Define the eligible audience, allowed purpose, prerequisites, message owner, approved variants, stop conditions, response branches, evidence captured, and destination stage. Keep actual copy in one maintained module. For follow-through, link the canonical follow-up sequence instead of pasting variants into every stage.
Phone, email, social, partner, and meeting plays have different constraints. The playbook should route to the applicable policy and approved asset without claiming one channel is legally or commercially suitable everywhere. Include “do not run” conditions: missing lawful basis or policy clearance, invalid contact data, unresolved suppression, a sensitive account, an active owner conflict, or a customer request to stop.
Make qualification reversible and evidenced
A qualification framework is a prompt for evidence, not a scoring costume. Define each field in observable language. “Budget confirmed,” for example, might mean the buyer described an approved source and process; it should not mean the rep feels the deal is funded. Separate unknown from negative. Unknown creates a next question; negative may trigger disqualification.
Choose one primary framework and define overrides for motion-specific cases. The qualification frameworks guide compares structures; the playbook should state which one applies here. For every criterion include accepted evidence, unacceptable proxies, owner, collection stage, expiry, and effect on advancement. Preserve a rollback path when new evidence invalidates an earlier assumption.
Control discovery-to-close handoffs
Handoffs fail when the next activity is booked but the underlying decision is not transferred. Use an acceptance packet. Discovery to demo should carry the agreed problem, affected workflow, audience, success questions, proof allowed, unknowns, and explicit “do not show” areas. The demo owner accepts or returns it with a reason.
Demo to proposal should carry confirmed fit and gaps, scope, assumptions, stakeholders, buying steps, security/procurement work, risks, and next decision. Proposal to close should carry approved version, deviations, obligations, signature authority, dates, and unresolved dependencies. Closed-won should not mean “contract exists”; delivery must accept a packet that reconciles what was sold with what can be delivered.
A handoff has three states: accepted, accepted with named conditions, or returned for remediation. Record who decided and when. That makes missed information visible without rewarding stage inflation.
Design exceptions and escalations
Real deals depart from the happy path. Define exception classes before they appear: unapproved claims, nonstandard security requests, restricted data, pricing outside authority, unusual contract terms, missing stakeholders, accelerated deadlines, channel complaints, ownership disputes, and delivery risk.
Each exception card should contain trigger, immediate safe action, forbidden action, evidence to preserve, owner, escalation path, response target, decision outcomes, and retrospective requirement. “Ask a manager” is incomplete if the manager lacks authority. Route to the decision owner and give the rep a customer-safe holding response that does not promise an outcome.
Version, release, and retire the playbook
Treat each release as a controlled product change. Draft the change, identify affected stages and assets, obtain domain approvals, test links and examples, pilot with representative users and cases, record defects, approve, publish one effective version, announce what changed, and archive the predecessor. Never leave two versions presented as current.
Use semantic labels or another unambiguous convention. Material changes alter decisions, authority, stage gates, claims, or customer obligations; minor changes clarify without altering the rule. Emergency changes need an owner, effective timestamp, notification path, and later retrospective.
Test retrieval as well as correctness: can a rep facing a real scenario locate the rule, source, owner, and escalation path quickly enough to act safely? Broken links, expired evidence, inaccessible permissions, and contradictory modules are release blockers.
Measure use, quality, and outcomes separately
Do not claim the playbook caused a win-rate change merely because both moved. Maintain four measurement layers:
- Access: availability, search success, broken links, and time-to-find in a controlled task.
- Execution: required evidence completeness, stage-contract adherence, handoff acceptance, and exception routing.
- Quality: manager observation against a rubric, evidence accuracy, customer-safe behavior, and remediation patterns.
- Outcomes: stage progression, cycle time, loss/stop reasons, rework, forecast reconciliation, and customer/delivery exceptions.
Define numerator, denominator, population, period, exclusions, source system, owner, refresh time, and tolerance for every metric. Compare cohorts cautiously and investigate confounders such as territory, segment, product, season, staffing, and policy changes.
Training attendance is also not workplace adoption. CDC guidance recommends assessing both learning and learning transfer and notes that delayed follow-up is useful for evaluating application on the job. Use a scenario-based pre/post check, observed practice, and later workflow evidence—not satisfaction alone. See the CDC training-evaluation guidance. Connect release practice to the printable 30/60/90 onboarding program.
Printable sales playbook template
Copy this block into your controlled workspace. Duplicate the stage and exception cards as needed. Empty fields are visible risks, not invitations to invent answers.
Sales playbook control sheet
Name / motion / audience: ______ Version / effective: ______
Scope included: ______ Excluded: ______
Accountable owner: ______ Steward: ______ Approvers: ______
Review triggers: product ___ price ___ policy ___ process ___ tooling ___ market ___
Stage: ______ Stage owner: ______
Entry event/source: ______
Required work: ______
Required evidence, source, timestamp: ______
Exit decision and authority: ______
Rollback/stop rule: ______
Accepted handoff owner/evidence: ______
Channel play: ______ Eligible audience/purpose: ______
Prerequisites: ______ Approved asset/version: ______
Stop conditions and branches: ______
Exception trigger: ______
Immediate safe action / forbidden action: ______
Escalation owner / response target: ______
Decision and retrospective: ______
Release test: links ___ permissions ___ sources current ___ scenario pilot ___ approvals ___ archive ___
Measurement contract: metric ___ formula ___ population ___ source ___ owner ___ cadence ___ tolerance ___
Where Gangly fits—and does not
First-party product context: Gangly can help put approved workflow guidance and preparation closer to seller activity. That may reduce the distance between a controlled play and its point of use. Evaluate that claim in your own pilot with representative scenarios, access controls, failure cases, and observed evidence.
Gangly does not decide your ICP, verify a customer fact, approve a claim, determine law or policy, grant pricing authority, accept a contract, or own delivery risk. Those decisions remain with named people and source systems. The playbook is successful when it makes those boundaries easier to see and follow—not when it automates judgment away.