ع
Learn Tracks Reference Guides Saved
playbook

Set the support voice and policy every reply inherits

Build two source-of-truth files once — `support-voice.md` (how you sound) and `support-policy.md` (what you're allowed to promise) — so every reply, macro, new-hire ramp, and QA review checks against real documents instead of each agent's guess.

medium ~1 hour to build, reused on every ticket
when to reach for this

Without a written voice and a written policy, every agent guesses — so your support sounds like a different person on every ticket, and nobody's sure what they can actually promise a frustrated customer without a manager. The fix is two short source-of-truth files you build once: support-voice.md (how you sound — the warmth, the apology pattern, de-escalation, the words you use and avoid) and support-policy.md (the guardrails — what an agent can offer without sign-off, the escalation thresholds, and the hard "never" list). Every reply draft, every macro, every new-hire ramp, and every QA review inherits these two. Build it first — every other Support playbook gets sharper once "our voice" and "what we're allowed to say" point at real documents instead of forty private interpretations.

gather this first
  • 8–10 of your best real past replies — the ones you'd be proud to show a new hire — pasted in or dropped into the chat in Claude Desktop. Scrub names, emails, order numbers, and account details to [customer] / [order] first. You're codifying a voice that already works, not inventing one.
  • Your current rules of thumb on what an agent can do alone: the refund ceiling, when a credit or exception is okay, how you talk about ship dates, and what has to go to a manager. Rough notes are fine — this playbook turns them into a written line.
  • Any hard "never" rules you already enforce — no admitting legal fault, no promising a fix date engineering hasn't given you, no inventing policy on the fly. Bring whatever exists; Claude will help you find the gaps.
the workflow

  1. Extract the voice that already works

    Open the folder with your best past replies in Claude Desktop and ask in the chat — no terminal needed. Don't describe the voice you wish you had; have Claude read the replies you're already proud of and name the pattern in them. Codifying a real voice beats inventing an aspirational one nobody talks like.

    you ask
    Read these 8–10 real support replies. Don't rewrite them — describe the voice they share: the level of warmth, how formal or casual, sentence length and rhythm, how they open and close, and the specific phrases that recur. Then give me a 4–5 line voice summary a new agent could actually use, with two or three example phrases that capture it.

    what you get back A short, recognizable voice description — "warm but not chirpy, short sentences, opens by naming the problem back, closes with one clear next step" — drawn from your own replies, plus a few signature phrases. If it doesn't sound like your team, you're reading the wrong sample.

    Pick the replies a manager would hold up as the standard, not a random sample — you're encoding the ceiling, not the average.

  2. Codify the apology and de-escalation pattern

    The hardest replies to get right are the ones where you're in the wrong or the customer is angry — so pin down the shape of those replies now, not in the moment. A written apology pattern is what keeps a stressed agent from either grovelling or going cold.

    you ask
    From the same replies, find the ones where we apologized or handled an upset customer. Describe the pattern: how we own the issue without over-apologizing, whether we explain why, how we offer the next step, and what we never do (no excuses, no blaming the customer, no fake urgency). Write it as a reusable 'when we're in the wrong / when they're angry' template — the shape of the reply, with placeholders.

    what you get back A de-escalation template — own it plainly, one honest line on what happened, a concrete next step, no defensiveness — that an agent can follow when the ticket is tense and their own judgment is under pressure.

    If your sample has no genuinely hard replies, write one or two with Claude and have a senior agent sign off — this is the part new hires most need a model for.

  3. Write the authority and escalation guardrails

    This is the policy half. The single most useful thing you can give an agent is a clear line: here's what you can offer on your own, here's where it goes to a manager. Vague authority is why agents either over-promise or freeze.

    you ask
    Help me write the response guardrails for support. Based on my notes, lay out three tiers: (1) what an agent can offer without any sign-off — refund up to [amount], a credit, a goodwill exception, how we phrase ship dates; (2) what needs a manager — refunds above the ceiling, policy exceptions, anything legal or press-related; (3) the escalation line itself, stated plainly. Flag anything I left ambiguous so I can pin a real number or rule to it.

    what you get back A tiered authority table — solo / manager / hard-stop — with real thresholds, plus a list of the spots where your rule was still fuzzy. The flagged gaps are the whole point: ambiguity here is what produces inconsistent, risky replies.

    Put real numbers on the ceilings. "Use your judgment" isn't a policy — it's the absence of one, and it's where the worst tickets go wrong.

  4. Build the explicit 'never say' list

    Some lines are bright red regardless of how reasonable they feel in the moment. Write them down as hard rules so neither an agent nor Claude ever crosses them — this is the list that protects you legally and keeps trust intact.

    you ask
    Draft a hard 'never say' list for support replies. Include: never invent an order number, refund, ship date, or policy that I haven't confirmed; never promise a fix or a date engineering hasn't committed to; never admit legal fault or liability; never make up a policy on the spot — say you'll confirm instead. Add any others a careful support lead would include, and for each, give the safe thing to say instead.

    what you get back A short, blunt list of bright lines, each paired with the safe alternative — "don't promise a ship date; say 'I'll confirm the timeline and follow up by [day]' instead." This is the rule both your agents and Claude get checked against on every draft.

    This list is the single most important guardrail against a confident, wrong reply — it's where 'Claude drafts, a human decides' becomes a written rule, not a hope.

  5. Assemble the two paste-ready files

    Pull it into two short, canonical files — voice and policy, kept separate so each does its job. Keep them tight; a document nobody can hold in their head doesn't get used on a busy queue.

    you ask
    Assemble two files. `support-voice.md`: the voice summary, the signature phrases, the apology / de-escalation template, and a short 'words we use / words we avoid' line. `support-policy.md`: the three-tier authority table, the escalation line, and the 'never say' list with safe alternatives. Keep each to about one page, plain and scannable — these are the source of truth every reply, macro, and new hire inherits.

    what you get back Two paste-ready files — support-voice.md (how you sound) and support-policy.md (what you're allowed to say) — that every downstream Support playbook points at instead of each agent's guess.

    Save both files and give them one owner. Voice decides how you sound; policy decides what you can promise — keep them separate so neither dilutes the other.

make it your own
  • Feed them into every reply: the Draft a reply that sounds like a person and Build a canned-response library you'll actually reuse playbooks both inherit these docs — load support-voice.md and support-policy.md alongside the ticket so every draft is on-voice and inside policy by default.
  • Score the queue against them: QA the queue and coach the team to one voice grades real replies against support-voice.md and support-policy.md, so 'off-voice' and 'over-promised' become findings you can coach, not vibes.
  • Hand them to new hires: Ramp a new support hire in their first week gives a new agent both files on day one — they learn the voice and the authority line from a document, not by absorbing it ticket by ticket over a month.
  • Make it a skill (Power Track): load support-voice.md + support-policy.md as a reusable skill or a /reply custom command so every draft is automatically checked against both the voice and the guardrails (see the Features tab). Skills and custom commands are the opt-in Power Track — on Desktop you just attach the two files to the chat by hand until you're ready to wire it together.
watch out for
  • Codify the real voice, don't invent one. If you write an aspirational voice nobody actually uses, agents ignore the file and you're back to guessing. Build it from your best real replies so it sounds like your team on its best day, not a brand deck.
  • Put real numbers on authority. A policy that says "use your judgment" on refunds and exceptions isn't a guardrail — it's the gap where agents over-promise or freeze. Pin a ceiling, an escalation line, and a manager threshold to actual numbers.
  • Scrub the sample replies before you upload them — past tickets are dense with names, emails, order numbers, and account details, and you only need the shape of the writing, not the customer's data.
  • Claude drafts the voice and policy; a human owns them. A senior support lead has to review both files before they become the standard — especially the 'never say' list and the authority ceilings, which carry real legal and money risk. Claude proposes; you decide what's binding.

you'll end up with Two short source-of-truth files — `support-voice.md` (how you sound: warmth, the apology pattern, de-escalation, words you use and avoid) and `support-policy.md` (what you can promise: the authority tiers, the escalation line, the hard 'never' list) — that every reply, macro, new-hire ramp, and QA review across the Support team inherits, so your support finally sounds like one team that knows what it's allowed to say.

Questions people ask

Why two separate files instead of one support guide?
Because they answer two different questions and get used differently. `support-voice.md` is *how you sound* — warmth, the apology pattern, words you use and avoid — and it shapes every draft. `support-policy.md` is *what you're allowed to promise* — refund ceilings, the escalation line, the hard 'never' list — and it's the guardrail QA and managers enforce. Keeping them separate lets a reply be checked against tone and against authority independently, and lets the right owner maintain each. You feed both into a draft together; you just don't collapse them into one blurry doc.
How do I capture our voice without just making one up?
Don't describe the voice you wish you had — have Claude read 8–10 of your best real replies and name the pattern that's already there: the warmth level, sentence rhythm, how you open and close, the phrases that recur. The voice file is a description of your team on its best day, not an aspirational brand voice nobody talks like. If the summary doesn't sound like your team, you handed Claude the wrong sample.
What exactly belongs in the policy file versus an agent's judgment?
The policy file removes the guesswork from the high-stakes calls: what an agent can offer alone (a refund up to a set ceiling, a credit, a goodwill exception, how to phrase ship dates), what has to go to a manager (refunds above the ceiling, policy exceptions, anything legal or press-related), and the bright-line 'never say' list. Judgment still applies to wording and empathy — but money, exceptions, and legal exposure should follow a written line, not a busy agent's gut.
Does this mean Claude decides what we promise customers?
No. Claude drafts the voice and policy from your inputs and flags the gaps, but a senior support lead reviews and owns both files — and every reply built on them still gets a human's eyes before it sends. The 'never say' list exists precisely because a confident draft can be wrong: never invent an order number, refund, ship date, or policy, and never admit legal fault. Claude proposes; a person decides what's binding and what goes out.