First-line playbook: the document after which support no longer depends on one person

Support without a playbook rests on one person who "knows everything". When they go on holiday, quality drops and developers answer users themselves again. A playbook moves knowledge from a head into a document that a new employee or an external team works from on day one.

What goes into the playbook

• Channels and coverage hours: where requests are accepted, at what time, what happens outside those hours.
• Request categories: question, defect, feature request, complaint, financial question — with examples and signs of each.
• Areas of responsibility: what the first line resolves itself, what it passes on and to whom — per category.
• Timings: first response and resolution time per category; what counts as a resolved request.
• Tone and templates: formal or informal address, signature, templates for typical answers in every language.
• Escalation: how a defect is handed to development — with steps to reproduce, environment and severity; how financial and legal questions are passed on.
• Forbidden: what the first line never promises or does — refunds without confirmation, fix dates, legal assessments.
• Reporting: what is counted weekly — volume, topics, response and resolution time, escalation share.

Categories and rules for each

The main mistake of playbooks is describing the process as a whole rather than per category. The question "how do I change my password" and the complaint "I was charged twice" require different actions, timings and rights. A working playbook is a table: category, signs, what the first line does, whom it passes to, timing, reply template. Five to seven categories are enough for almost any product.

1. Product question: an answer from the knowledge base within the first-response time; if there is none — a check with the team and an addition to the base.
2. Defect: reproduction by the user's steps, a ticket in the tracker with severity, an interim reply to the user, a notification after the fix.
3. Feature request: thanks, an entry in the ideas backlog, no promises on timing.
4. Complaint: a reply within a short time, escalation to the owner, closure control.
5. Financial question: collecting transaction data, hand-over to the owner, an interim reply within the SLA, no refund promises before a decision.

Timings that work

Timings must be achievable within coverage hours and honest outside them. A typical frame for products in the region: a first response within an hour during business hours, a typical question resolved the same day, financial questions and defects — an interim reply on the day of the request and a final one after the responsible party decides. Timings are fixed in the playbook and reported — otherwise nobody keeps them.

How the playbook lives

• The knowledge base grows after every request that had no ready answer.
• Once a month the playbook is reviewed against accumulated cases: new categories, changed timings, new templates.
• After every release templates and the knowledge base are updated for product changes.
• The weekly request report shows where the playbook fails: long timings, a high escalation share, recurring topics.