Guide
How to write a business playbook
A playbook is the written version of the judgement your best person applies without thinking. Its value is not documentation; it is that a new hire makes the same call on their second week as your best person makes on their tenth year.
Short answer
Write decision rules, not descriptions. Each play names the situation, the default action, the exceptions and who decides. If a section cannot change what someone does on a Tuesday, cut it.
What a playbook is, precisely
A playbook sits between a process document and a book of advice. Process documents describe steps; advice describes principles. A playbook does the thing neither does: it says in this situation, do this, unless these things are true. That is why it can be read once and used for years.
| Document | Answers | Read when |
|---|---|---|
| Process/SOP | How do I perform this task? | While doing the task |
| Playbook | What should I do in this situation? | Before the situation, and when it is ambiguous |
| Strategy doc | Why are we doing any of this? | Once a year, by leadership |
Find the plays
Do not start from a table of contents. Start from the decisions your team actually makes and gets wrong. Three ways to surface them:
- The repeated question. Anything three people have asked you this quarter is a play.
- The expensive mistake. Work backwards from the last four things that cost money or a client. Each one had a decision point.
- The shadow rule. Things your best person does that are not written anywhere: which leads to walk away from, when to escalate, what to do when a delivery slips.
If a section of your playbook has never been the subject of an argument, it probably does not need to be in the playbook.
The format of a play
Keep every play to the same six parts. Uniformity is what makes it scannable under pressure.
- Situation — one sentence describing when this applies, in the words people actually use.
- Default — what to do if nothing unusual is true. The most important line in the play.
- Why — two sentences. People follow rules they understand and quietly ignore ones they do not.
- Exceptions — the two or three cases where the default is wrong, and what to do instead.
- Who decides — the name of a role, not a committee.
- Example — one real case, anonymised, including one where it went wrong.
Six parts, roughly 800 to 1,500 words per play. Ten plays and you have a book.
Write decision rules, not descriptions
The difference in practice:
| Description (weak) | Decision rule (strong) |
|---|---|
| We aim to respond to client emails promptly. | Acknowledge within four working hours, even if the answer takes three days. If you cannot answer by Friday, say so on Thursday. |
| We are selective about the projects we take. | Decline if: the budget is under $8k, the deadline is under three weeks, or the person briefing us is not the person approving. Any two of these can be waived by the lead; all three cannot. |
| We value good handovers. | A project is not closed until the handover doc is in the client folder and one named person at the client has replied to it. |
Notice what the strong versions have: numbers, named thresholds, and a person. That is the whole trick.
Neubook Write’s playbook kind interviews you for the decisions. It asks what people get wrong, what your defaults are and where the exceptions live, then writes each play to a consistent shape with your examples in it.
Start a book, freeStructure for the whole book
- How we think — three to five operating beliefs, each with a consequence. Beliefs without consequences are wall art.
- The plays, grouped by function: winning work, delivering it, money, people, when things go wrong.
- The glossary — your internal terms, defined. This is disproportionately useful for new hires and disproportionately neglected.
- What we do not do — the clearest chapter you can write. Explicit non-goals stop more waste than any process.
- How this document changes — who owns it, how to propose an edit, when it is reviewed.
Keeping it alive
Most playbooks die within a year, and the failure is always maintenance rather than authorship. What works:
- Date every play and name an owner. Undated advice is assumed stale.
- Review on a calendar, not on inspiration. Two hours a quarter, one section at a time.
- Amend from incidents. Every post-mortem ends with "does this change a play?" Most of the time the answer is no, and that discipline is what keeps the document trustworthy.
- Version it visibly. "v3, updated March 2026" on the cover; keep the old versions.
When to make it a book rather than a wiki
Publish as a book when you want it read rather than searched:
- Onboarding. A new hire reads a book in week one; nobody reads a wiki cover to cover.
- Franchise or multi-site. A physical object travels and carries authority a link does not.
- Selling the method. A playbook is the best marketing document a consultancy can have, because the reader who implements it alone becomes the reader who hires you to do it properly.
- Handover and succession. Selling the business, or handing a team to a new lead.
Keep the fast-changing material — prices, tool configurations, contact lists — out of the book and in the wiki, and say in the book where it lives. The book holds judgement; the wiki holds facts that expire.
Confidentiality before publication
If the playbook will leave the company, do a deliberate pass for: client names and identifiable details, unpublished pricing, supplier terms, anything covered by an NDA, and staff details. Have someone other than the author do this pass — authors are blind to their own material. If your jurisdiction has trade-secret protection you rely on, publishing the method can weaken it; that is a conversation to have before the book, not after.
Writing it with AI without producing management pabulum
This genre has a strong gravitational pull toward the generic, and language models are fluent in exactly that register: "align stakeholders", "foster a culture of accountability". Countermeasures:
- Every play needs a number or a name. If it contains neither, it is not a play.
- Include the failure. "We tried the opposite for six months and here is what it cost" is the most credible paragraph in any playbook.
- Ban the abstract noun where a concrete one exists: "the Thursday call", not "the communication cadence".
- Read it as a sceptical new hire. Anywhere you would think "yes, but what do I actually do", rewrite.
Our free AI tells checker is useful here; business writing is where the reversals and triads cluster most thickly.
A two-week build
| Days | Work |
|---|---|
| 1–2 | List every repeated question and expensive mistake from the last year. Group into ten plays. |
| 3–4 | For each, write the default and the exceptions. Argue about them with the team; the argument is the work. |
| 5–8 | Draft the plays with real examples. Add the glossary and the "what we do not do" chapter. |
| 9–10 | Confidentiality pass. Give it to the newest person and watch which parts they cannot use. |
Ten plays most companies need
If you are staring at a blank contents page, these ten cover the decisions that cause the most expensive disagreements in small companies. Adapt the names to your language.
| Play | The decision it settles |
|---|---|
| Which work we take | Qualification thresholds and who can waive them |
| How we price | Floors, discounting rules, when to walk away |
| How a project starts | What must exist before work begins — brief, deposit, named approver |
| How we communicate with clients | Response times, channels, who owns the relationship |
| When something slips | Who is told, how soon, and what we offer |
| When a client is difficult | The escalation ladder, and the point at which we end it |
| How we hand over | Definition of done, documentation, sign-off |
| How we hire | What we test for, who decides, the trial arrangement |
| How money moves | Invoicing, chasing, approval limits |
| What we do after a mistake | Blameless review, who writes it, what changes |
Ten plays at 1,000 words each is a 10,000-word book that a new hire can read in an evening and use in their first week.
Getting it out of people's heads
The person with the judgement is rarely the person who wants to write. Interview rather than assign:
- Ask about the last five times, not the general policy. "Walk me through the last five leads you turned down." Rules emerge from cases.
- Ask why at each step, twice. The first answer is the policy; the second is the reason the policy exists.
- Ask what they would tell a new person to watch out for. This question produces more usable playbook material than any other.
- Record it. Transcripts contain the specifics and the voice; writing from memory produces generic prose.
- Send the draft play back as a question: "Is this what you would do?" Disagreement in review is the most valuable input you will get.
Where playbooks go wrong
- Written by the wrong person. A consultant's template with your logo has no authority, and everyone can tell within two pages.
- Aspirational rather than descriptive. If the playbook describes a company you would like to be, staff learn to ignore it. Write what you do, then change what you do, then update the book.
- No exceptions. Rules without stated exceptions get broken quietly, and the breaking becomes the real rule.
- Too long. Two hundred pages is a document nobody reads and everybody cites selectively.
- No owner. An unowned playbook is eighteen months from being wrong.
- Confusing values with plays. "We are honest" is a value. "We tell the client about the slip the day we know, not the day it lands" is a play. You need both, in separate chapters.
Rolling it out so it gets used
- Launch it in a room, not by email. One hour, walk through three plays, take the arguments seriously.
- Use it visibly in a decision within the first week. "Play 4 says we tell them Thursday, so we tell them Thursday." One public use teaches more than the launch.
- Put it in onboarding formally — day one reading, day three conversation about what surprised them.
- Make amendment easy and visible. If proposing a change requires a meeting, nobody will, and the document will rot.
A playbook's real test comes the first time it tells the founder they are wrong. If it gets overruled without amendment, it is decoration from that day on.
Publishing it outside the company
Some of the strongest business books are playbooks with the client names removed. If you go that way:
- Keep the specifics. The numbers and thresholds are why anyone would read it. A sanitised playbook is a pamphlet.
- Add the context a stranger lacks — your size, your market, your constraints — so readers can judge what transfers.
- Include what failed. External readers trust a book that describes an abandoned approach more than one that describes only victories.
- Expect competitors to read it. Decide in advance what you are comfortable giving away; for most service businesses, execution is the moat, not the method.
Get the way you work out of your head and onto paper. Neubook Write interviews you, drafts the plays, and exports EPUB, PDF and a print-ready paperback you can hand to a new starter on day one.
Start a book, freeSources
- Nielsen Norman Group: how users read on the web
- KDP: Content guidelines, including AI-generated content
- KDP: Paperback formatting and trim sizes
Common questions
How long should a playbook be?
Short enough to be read on the first day: 15,000 to 30,000 words, nine to twelve plays. A 200-page operations manual is a reference document, which is a different thing with a different home.
Wiki or book?
A wiki wins for material that changes weekly and needs searching. A book wins when you want it read end to end — onboarding, franchising, selling the method, or handing your approach to a client.
Who should write it?
The person who makes the calls, interviewed by someone who asks why. Playbooks written by someone who has not done the job read as theory and get ignored.
How do we keep it current?
Date every play, name an owner, and review on a fixed cadence. An out-of-date playbook is worse than none because people stop trusting all of it.
Can we sell our playbook?
Many consultancies do, and it works as marketing: the buyer who reads it and wants it implemented becomes a client. Take out client names and anything genuinely proprietary first.