Write a play that someone can actually run
Choose one commercial situation rather than trying to document the whole business at once. Explain why the account fits, what is hypothetical and how a buyer can disprove the premise. Connect outreach to discovery and stage acceptance, then show which decisions need product or commercial approval.
Include the artifacts the operator needs: an account record, buyer note, next-action plan and escalation route. Document exceptions alongside the normal path. Assign a maintainer and a review trigger so new loss or adoption evidence can change the rule. A playbook that grows without revising decisions becomes an archive.
| Decision | Evidence to use | What changes next |
|---|---|---|
| Entry | Trigger, fit, source and disqualifiers | Operator can choose whether the play applies |
| Execution | Message, discovery, evidence and approved actions | Operator can progress or reject responsibly |
| Exit and recovery | Handoff, stop condition, exceptions and owner | The motion survives mistakes and team changes |
Work through the decision
Illustrative play: a platform adds enterprise access tiers. The researcher saves the pricing source and asks whether plan changes create manual work. The seller sends a neutral workflow question, validates the consequence and records who owns the change.
If the buyer confirms a project and feasible scope, agree evaluation criteria. If the workflow is already solved or requires an unsupported deployment, stop and retain the reason. The longer guide supplies a complete worked play with message, discovery and handoff examples you can adapt rather than just a list of headings.
The template tells people what to say but not when to stop
A script-only playbook can encourage persistence on unsuitable accounts. Include rejection, escalation and buyer-correction examples. Good judgment includes deciding not to proceed when the evidence does not support the offer.
A concrete next step
Open the longer playbook guide, adapt one complete play to your product and test it on one strong-fit and one weak-fit account before rolling it out.
Sources and research notes
- GitLab sales operating proceduresCompany operating handbook
- GitLab customer-ready shadow programCompany operating handbook
Primary sources reviewed October 6, 2026. The operating recommendations and worked scenarios are Daavid’s analysis. Illustrative numbers are assumptions, not measured client results. Company marks identify sources and prior experience; they do not imply a customer relationship or endorsement.
Schematic