← The Service Station ~ dish 09 of 10 · the service station

Service Playbook Authoring

When a new failure mode shows up, one account manager figures out how to handle it. They solve it brilliantly. Then they leave the company. That solution lives in their head. The station captures it and turns it into a playbook so the next person doesn't start from scratch.

The job

A customer reports an issue your team has never seen before. Broken feature triggered by a specific account configuration. Nobody documented the diagnosis or the fix. The account manager digs in. Checks seven things. Tests a hypothesis. Finds it. Fixes it. Tells the customer the move. Crisis resolved. Then the next customer hits the same bug. The next account manager doesn’t know about the earlier fix. Spends six hours retracing the same path.

Service playbook authoring watches for new failure modes (an issue that came in, was handled, doesn’t have a documented response) and drafts the playbook entry. This is the response. This is what to check first. This is the escalation path if the fix doesn’t work. This is what to tell the customer.

Plated well: the next time this issue hits, a support person reads the three-paragraph playbook and has context, diagnosis path, fix, and customer communication in ninety seconds instead of burning six hours.

The recipe

All seven ingredients still apply. The leverage on this dish is Feedback Loop (Ingredient #7) plus Four D’s Stance. Without the feedback loop, brilliant solutions stay brilliant for one person. Without the Chef tasting, playbooks become mechanical scripts instead of judgment calls.

Training sets what a playbook entry contains (issue name, trigger, diagnosis steps, fix, escalation path if fix fails, customer communication). Examples show the station what playbooks look like for different issue types (technical bugs, configuration mistakes, customer misunderstanding, system edge case). Context matters because the playbook is useless if it doesn’t explain why you’re checking that thing first (context teaches the next person to think, not just follow steps). Output Over Process means the destination is clear: capture enough so the next person doesn’t start from zero, but don’t over-document (ten-page runbooks are theater). Four D’s anchor: the account manager DECIDES what the failure mode actually is. The station DIALS to draft it. The Chef TASTES the playbook before it goes live (catches oversimplification, ensures it matches how the team actually handles it).

How to build it

  1. Identify your new failure modes. Over the last month, what issues came in that your team didn’t have a documented response for. Pick the two or three that are most likely to recur (happened once, will probably happen again).

  2. Pull the solution thread. For each new failure mode, find the ticket or call where someone solved it. Get the full context. What they checked. Why they checked it. What worked. What didn’t.

  3. Create playbook entry template. Issue name. Trigger (what makes this happen). How customer will describe it. Diagnosis (what to check first, second, third). Why you’re checking in that order (this is where judgment lives). Fix. Escalation path if fix doesn’t work. Customer communication (what to tell them). This is your structure.

  4. Draft one playbook example. Take one of the new failure modes and draft the playbook entry yourself. This is the standard the station learns from. Make it specific, not generic.

  5. Set the Chef taste checkpoint. The station drafts the entry. The account manager (the Chef) reads it and says yes or no. They can sharpen, correct, personalize. This is not auto-publish.

  6. Set the measurement: Did this playbook entry actually get used by the next person who hit this issue. Did they report back that it was useful. If yes, it’s working. If they had to call someone to clarify, the entry wasn’t clear.

  7. Track new failure modes. How many new issues came in this month. How many made it to a playbook entry. By month four, you should have captured most of your recurring edge cases.

What breaks it

  • Mechanical checklist, not judgment guide. The playbook says “check field X, check field Y, check field Z” without explaining why. The next person follows the steps, gets a false negative, misses the actual problem. Judgment is the load-bearing element. Explain why you’re checking in that order. That teaches the next person to think.

  • Oversimplification. The station captures “restart the server and call back” when the actual fix is more nuanced. The next person tries the restart, it doesn’t work, they’re stranded. Playbooks should be specific enough to work, not simplified to uselessness.

  • No escalation path. The playbook says “do X to fix it” but X doesn’t work in 10% of cases and nobody documented what to do then. The next person hits that 10%, tries the playbook, fails, spends hours stranded. Always include “if X doesn’t work, escalate and include Y info.”

  • Chef never tastes. The station drafts playbooks and they go live without the account manager reviewing. By month two, the playbooks are disconnected from how the team actually handles issues. Catches have stopped.

  • No customer-communication guidance. The playbook documents the fix but never says what to tell the customer. Is this a known bug. Is it a rare edge case. Is it a configuration mistake on their end. Different issue = different customer message. Include it in the playbook.

When it’s working

By week two, new failure modes are getting playbook entries drafted. By month one, five new playbooks are live. By month two, when a known issue comes in, the support person finds the playbook and handles it in 15 minutes instead of six hours. By month three, the team is using playbooks to train new hires. By month four, most recurring issues have playbooks and your support time on known problems is predictable.

Measure it: when an issue hits that has a playbook entry, how fast is it resolved. Compare against issues without playbooks. Playbooked issues should resolve 5x to 10x faster.

Monday Move

Look for one issue your team solved this week that doesn’t have a documented playbook. Pull the solution thread. You write the playbook entry. Then have the station read the same thread and draft the entry. Compare. Did the station get the logic right. Did it explain why you’re checking in that order. Did it include the escalation path. That gap is where the playbook gets sharper.

Dish 9 of 10 on the Service Station. Build-note leverage: Feedback Loop (Ingredient #7) + Four D’s Stance.