How to write a one-page support playbook

Most small teams don't need a support wiki. They need one page that answers the questions people ask in chat ten times a week: who handles this, how fast, and am I allowed to refund it?

A one-page playbook is short enough that people actually read it and specific enough that a new teammate can work a shift with it open in another tab. This guide gives you the template, explains what goes in each section, and ends with a filled-in example.

Why one page#

Long support documentation fails in a predictable way. Nobody reads it end to end, it drifts out of date, and people go back to asking the person who has been there longest. A single page forces you to make decisions instead of describing every possible case. If a rule doesn't fit on the page, it's usually either rare enough to handle by judgment or important enough to deserve its own linked document.

The page has three jobs:

• Tell people where mail lands and who owns it.
• Set the defaults (response times, tone, what to do when stuck).
• Grant authority so people don't have to ask permission for routine decisions.

The template#

Copy this into whatever your team uses for documents. Keep the headings; replace the bracketed text.

SUPPORT PLAYBOOK — [Team name]          Last reviewed: [date] by [name]

1. ADDRESSES AND OWNERS
   [address]      → owner: [person/role]   backup: [person/role]
   [address]      → owner: [person/role]   backup: [person/role]

2. HOURS AND TARGETS
   Covered hours: [days, hours, time zone]
   First reply target: [e.g. same business day]
   Urgent (service down, data issue): [target + how to reach on-call]

3. TRIAGE RULES
   Work first: [what counts as top priority]
   Then: [next category]
   Can wait: [low-priority category]
   Never reply to: [spam, vendor pitches, etc.]

4. ESCALATION
   Bugs → [where and how]
   Security or account access → [who, and what never to do]
   Angry customer / legal threat → [who]
   Founder/lead gets pulled in when: [criteria]

5. REFUNDS AND MONEY
   You may approve without asking: [scope]
   Needs approval from [person]: [scope]
   Always log: [where]

6. TONE
   Sign off as: [first name / team name]
   We always: [2–3 habits]
   We never: [2–3 habits]

7. LINKS
   Docs: [url]   Status page: [url]   Snippets: [url]
   Bug tracker: [url]   Billing admin: [url]

Filling in each section#

1. Addresses and owners#

List every address that receives customer mail, even the ones that "barely get anything." The forgotten address is the one where a complaint sits for three weeks. Every address gets one owner and one backup. A role ("whoever is on rota") is fine as long as the rota itself is linked.

2. Hours and targets#

Write targets you will actually hit on a bad week, not a good one. "Same business day" is honest for most small teams; "within one hour" usually isn't. Spell out the time zone. If you offer any after-hours coverage, say exactly what qualifies as urgent so the on-call person isn't woken for a password reset.

3. Triage rules#

This is the order of work, not a full taxonomy. Three or four lines is enough. A common order is: anything blocking a paying customer, then billing, then how-to questions, then feature requests. Add a line for what never gets a reply so people stop agonizing over vendor pitches.

4. Escalation#

For each type of escalation, name a destination and a format. "Tell engineering" is not a rule; "Open an issue in the Support Bugs project with repro steps and the thread link, then post the link in the support channel" is. Include at least one explicit "never" for account-access requests, such as never changing an account owner based on an email from an unverified address.

5. Refunds and money#

This section removes the most friction. People hate asking permission for small decisions, and customers hate waiting while they do. Pick a threshold below which anyone can refund without approval, and say where to record it. Above the threshold, name one approver.

6. Tone#

Three "always" and three "never" lines beat a page of brand-voice prose. Examples: always answer the question in the first paragraph; always give the next update time; never blame the customer; never promise roadmap dates.

7. Links#

The page is a hub. Link the docs, the status page, the snippet library, the bug tracker, and whatever admin tool is used for billing. If someone has to ask "where is that?", the link belongs here.