Your team already has the tone-and-policy, reply-drafting, and macro-library playbooks — the worked recipes for building each document, step by step. This module is the layer above the recipe. It’s where you master the three files every reply inherits — how you sound, what you can promise, and the templates every agent starts from — build them for your own team, and prove, against a real rubric, that you can.
It’s Module 1 of the certifiable Customer Support track, and it’s the one we leave open. Read it, do the assignment, and you’ll know exactly what the depth is worth before you put a team through the rest.
Every reply your agents send — every VAT export explanation, every billing clarification, every escalation to a manager, every refund decision — is a withdrawal from three accounts: how you sound, what you can promise, and the templates you start from. Most teams never fund those accounts, so every agent improvises all three on every ticket, and the brand sounds like a different company depending on who’s on shift. The foundation is the hour where you fund them once, and it’s the highest-leverage hour in the whole track.
Why the foundation is the highest-leverage hour you’ll spend
Support fragments at the voice. One agent opens with warmth and owns the problem immediately; the next leads with a policy citation and a hedge; a third sends a reply so formal it reads like a bank letter. A single customer who tickets twice gets two different companies, and their trust — which was already strained because they had to ticket at all — takes the hit both times. Voice without a written anchor drifts to the median of whoever sent the last reply, and the median is forgettable at best and alienating at worst.
The same fragmentation happens at the policy line. With no written authority table, every agent invents their own escalation threshold. One approves a refund that should have gone to a manager; another calls a manager for a credit that was well inside their authority. Both outcomes are expensive — the first creates precedents that are impossible to enforce; the second adds queue pressure to a manager who should be handling the decisions only they can make. “Use your judgment” is not a policy. It’s a transfer of anxiety onto whoever opened the ticket.
Three documents fix all three failure modes. A support-voice.md decides how you sound — the signature phrases, the apology pattern, the words you use and the ones you don’t. A support-policy.md decides what you can promise — the authority tiers with real numbers, the escalation line, the never-say list. And a set of macros.md templates decides where every reply starts — on-voice, on-policy, with the placeholders in the right spots so no agent has to improvise the opening line under pressure. Build them once and every later task inherits them: you feed the voice into a reply-drafting job and Claude opens warm instead of corporate; you feed the policy into a triage workflow and the right tickets get routed without a Slack message; you feed the macros into a new hire’s first week and they sound like Layla on day one.
That’s why this is Module 1. Skip it and Claude just helps your team send faster replies that are still off-voice, over-promising, and form-letter cold — which is worse, not better. Fund the three accounts first and every ticket downstream gets sharper for free.
Mastering the voice — the judgment the recipe can’t teach
The playbook gives you the steps. Mastery is the judgment inside the steps — the four calls that separate a voice document agents actually write from and one that gathers dust in a shared folder.
- Codify what already works — don’t invent an aspirational voice. Pull your ten best recent replies — the ones with the highest satisfaction scores, the ones where a frustrated customer came back saying “thank you, that was helpful.” Read them as a set. The voice is already there: a rhythm, a way of opening, a pattern for owning a mistake. Write that down. Do not write the voice you wish you had — write the one that’s already producing results. An aspirational voice is fiction; a codified real voice is infrastructure.
- The apology has a shape — pin it now, not under pressure. Every team agrees that a good apology names the problem, owns it, and moves to the fix — but when a customer is angry and an agent is staring at the compose box, that agreement disappears under the pressure of the moment. The only way to guarantee the shape survives pressure is to write it down explicitly before the pressure hits. Does the apology go in the first sentence or the second? Does it name the specific problem (“you were charged twice”) or the general situation (“there was an error with your billing”)? Specificity is warmth; vagueness reads like a corporate non-apology. Write the pattern out, lock it, and put it in the document.
- Words you avoid are as important as words you use. “Per our policy” tells the customer their problem is smaller than your procedure. “As a one-time courtesy” implies they’re lucky you’re helping them at all. “We apologize for any inconvenience” apologizes for nothing, because it names nothing. These phrases feel safe to agents under pressure — they’re habits borrowed from other support cultures — and they erode trust at scale, one reply at a time. The words-to-avoid list is the single most actionable section of your voice document, because removing a bad phrase is a smaller ask than writing a better one.
- One owner, or it drifts. The whole value of the voice document is that it’s a single source of truth every agent writes from. If everyone can freely edit it, it splinters back into a different tone per agent within two quarters. Name one owner — usually the CX lead or the team’s most senior writer — and treat changes as reviewed updates with a date bump. The owner is not a gatekeeper; they’re the person accountable for making sure the brand sounds like itself at 3am on a Friday when the senior agent is off.
The policy — authority that doesn’t leave agents guessing
The fastest way to lose a customer is to make them feel the decision about their problem is being made by the wrong person. A sharp authority table and a clear escalation line are how you put the right decisions at the right level — and the test of a good policy is brutal: an agent should be able to read it, apply it to a real ticket, and know exactly what they can do without sending a Slack message.
A policy document agents can actually use is specific and number-based, not principled and vague:
- Real numbers, not principles. “Use your judgment on refunds” is not a policy; it’s a gap. “You can apply a credit up to AED 150 or comp one month for a clear Mizan error, without approval” is a policy. The agent who reads it knows immediately whether this ticket is theirs to resolve. Every money amount, every timeline promise, every exception has a number. Where you genuinely need judgment — because the situation is truly novel — the policy names a person to call, not a principle to weigh.
- The escalation line is the most valuable sentence in the document. Most policy documents describe what agents can do; the escalation line describes what they cannot, and that line matters more. Write it directly: “If the refund would exceed AED 150, if the customer is asking about annual plan changes, if they’ve mentioned a lawyer or the media — call the manager before you reply.” That sentence, memorized, is worth more than three paragraphs of guidelines, because it fires before the agent types anything irreversible.
- The never-say list with safe alternatives. Every support team has sentences that sound harmless but create legal exposure or set precedents the team can’t honor. “We admit this was entirely our fault” sounds like accountability — and in a legal dispute it’s a liability. “I can guarantee this won’t happen again” sounds reassuring — and the next time it happens, the customer has a screenshot. The never-say list names these explicitly, and pairs each one with a safe alternative that is still warm and honest. Agents don’t need to be cold to stay safe; they need to own the specific error without making commitments they can’t keep.
- Policy and voice are separate files. Voice is how you sound; policy is what you can promise. Agents need to hold both in their head on every ticket — but they’re different muscles. Mixing them into one document means agents look up the refund threshold and accidentally re-read the apology shape advice, or vice versa. Keep them separate, named clearly, and cross-reference them once in each document so agents know the other exists.
The macro library — warmth at scale
Macros exist for one reason: the top ten recurring ticket types shouldn’t require an agent to draft from a blank screen at 9am when the queue has forty tickets in it. A good macro is the best reply to a common question, bottled. A bad macro is a form letter that tells the customer they’re a category, not a person. The difference between the two is not the macro itself — it’s the judgment that goes into building it.
- Build from real best replies, not blank templates. Open your inbox. Find the ten tickets where the customer replied “thank you, that solved it” or gave a five-star rating. Those are your macro source material. A macro built from a real high-performing reply inherits its warmth, its pacing, its way of opening — because that warmth was already tested against a real frustrated human and passed. A macro built from scratch inherits whatever register the author happened to be in at 2pm on a Tuesday. Start with the best, formalize the structure, and strip only the parts that are ticket-specific.
- Placeholders in the right spots — and only those spots. Every macro has three things that change per ticket: the customer’s name, the specific detail of what happened (“the export that errored” rather than “your issue”), and what you’re doing about it right now. Those are the only
[placeholders]. The apology pattern, the sign-off, the warmth of the middle — those don’t change per ticket, so they don’t get placeholders. A macro with a placeholder where the policy should be is a macro where every agent will write a different policy from memory. Lock what’s lockable. - The shape is the warmth. A support macro has three parts: a warm opener that names the problem back to the customer (not “Thank you for contacting us” — that names nothing), a clear middle that states exactly what happened and what you’re doing, and one single next step that tells the customer what to expect and when. That structure is the warmth. Customers experience a clear, fast, honest reply as warm — not because of adjectives, but because of clarity. Every macro you build should have that shape, and the shape should be obvious in one read.
- A macro is a starting line, not a send button. The agent who hits send on a macro without reading it has outsourced their judgment to a template, and the customer will notice — the name is wrong, or the placeholder wasn’t filled, or the specific detail they mentioned in their ticket isn’t acknowledged. Train agents to treat every macro as a 30-second edit task: read it, fill the placeholders, add one sentence that’s specific to this ticket, then send. That one sentence is the thing that tells the customer they were read, not processed.
The Arabic standard — what bilingual support actually means
For a MENA team this is not a translation step bolted on at the end. It’s a parallel foundation, and getting it right is the difference between a reply that feels like a warm, human interaction and one that reads like a foreign vendor’s form letter run through a machine. The rule is author in Arabic, don’t translate into Arabic — and it has four edges most teams miss:
- Arabic replies are authored, not translated. A support reply that was written in English and translated into Arabic carries the rhythm and sentence structure of the original. Arabic readers feel it immediately — not as a conscious critique, but as a slight distance, a sense that the person who wrote this didn’t quite mean it in Arabic. The apology in particular lands differently. “نعتذر عن الإزعاج” is the Arabic calque of “we apologize for any inconvenience” — and it’s just as hollow in Arabic as it is in English. Write the Arabic macro from the Arabic voice document, in the register you’ve decided on, and the warmth will be native.
- The apology lands differently in Gulf Arabic — name the problem first. The register that reads honest and warm to a GCC customer has a specific shape: you name their specific problem back to them before you say anything else, and you say “صوتك مسموع” — your voice is heard — before you move to the fix. That phrase, or something like it, isn’t in any English macro. It’s not a translation; it’s a move that belongs to the register. Build it into the Arabic macro the same way the apology shape is built into the English one.
- Policy thresholds may differ — AED amounts are local. The policy document names amounts in AED because Mizan is a GCC product. Your Arabic macros inherit those same thresholds — there’s no separate Arabic policy tier — but the way the threshold is communicated can adapt to the register. An English macro might say “I can apply a one-month credit to your account.” An Arabic macro in the right register says the same thing in fewer, warmer words, without sounding like a bank approval letter. The number is the same; the framing earns more trust.
- Arabic macros inherit the Arabic register from
support-voice-ar.md, not from the English macro. This means you need a second voice document — a short one, authored in Arabic, that describes the tone for Arabic replies specifically: where on the formal–informal spectrum you sit, which Gulf-natural phrases are in-register, and how the apology pattern translates into Arabic voice. Your Arabic macros cite this document, not the English one. That way a new hire who reads Arabic can onboard from the Arabic voice file and write correct-register Arabic replies from day one, without having to mentally translate from the English standard.
Your assignment
Build the three foundation documents for one support team — your own (recommended: the output is a real asset your agents ramp from and every ticket inherits) or the sample brand Mizan, a GCC bookkeeping SaaS whose support team runs throughout this track. Open a folder with your raw inputs — a week of tickets, your top-rated replies, your current refund thresholds — in Claude Desktop, approve each read in the “Ask permissions” prompt, and work in the chat — no terminal needed.
Module 1 deliverable — the support foundation
1. support-voice.md (one page)
- a plain-language description of how the team sounds (2–3 sentences
someone new could actually follow)
- the apology pattern: where it goes, how specific it gets, what it names
- 5 words / phrases we use consistently
- 5 words / phrases we never use — with a safe alternative for each
- one owner named by role and name
2. support-policy.md (one page)
- a 3-tier authority table:
Solo agent | Manager approval | Never (no role can do this)
with real AED amounts, named ticket types, and explicit conditions
- the escalation line: one sentence that tells an agent when to stop
typing and call the manager before replying
- the never-say list: 5–8 phrases, each with a named safe alternative
and the reason it's on the list
3. macros.md (one page)
- 10 on-voice reply templates for the team's top recurring ticket types
- each with [Customer name], [specific detail], [action taken]
placeholders in the right spots — and only those spots
- each template follows the three-part shape:
warm opener (names the problem) → clear middle → one next step
Bilingual teams: add support-voice-ar.md (the Arabic register spec) and
author the Arabic macro variants from that document, not from the English.The Foundation toolkit gives you a fill-in template for each of these and the prompts that build them, so you’re filling in structure, not staring at a blank page.
How it’s graded — the rubric
This is the part the free playbook doesn’t have, and the part that makes the credential mean something. Your three files are scored against five criteria. Each is meets / nearly / not yet — and “nearly” on any one is a revise, not a pass.
Foundation rubric
1. Voice is recognizable A stranger reads three replies written from this
document and knows it's the same team. The apology
pattern is explicit. The avoid list is specific —
named phrases, not general advice.
2. Policy has real numbers No "use your judgment" on money or timelines.
Every refund threshold, credit limit, and
escalation condition has an amount or a name.
The escalation line is one sentence, unambiguous.
3. Never-say list is bright Named phrases appear in the list — not categories
of badness. Each one pairs with a safe alternative
and a one-line reason it's on the list.
4. Macros are warm A customer receiving any macro cannot tell it is
a template. The opener names their specific problem.
Placeholders appear only for genuinely variable
content. The shape — opener, middle, next step —
is intact in every template.
5. Arabic register is right Arabic macros are authored from the Arabic voice
doc, not translated from English. The apology
lands in Gulf-natural register. AED amounts and
Gulf-specific phrasing are correct. (Bilingual teams.)The discipline is deliberately what a senior CX lead would demand: a foundation that’s vague, inconsistent, or cold fails quietly on every ticket — so it has to be caught here.
The bar, shown — a worked model answer (Mizan)
You don’t have to guess what “meets” looks like. Here’s a passing excerpt for the sample brand — your own doesn’t need to look like this, it needs to clear the same bar. These are Layla Al-Nasser’s documents for Mizan’s five-person support team.
support-voice.md — Mizan (excerpt)
How we sound
Warm, plain, and direct. Short sentences. We own our mistakes in the
first sentence — not buried in paragraph three. We open by naming the
problem back to the customer: not "Thank you for contacting us" but
"Your VAT export didn't generate — here's why and what we're doing."
We never sound like a policy document.
The apology pattern
Name the specific error first. Then own it — "that's on us" or "we
got this wrong" — before any explanation or fix. Don't explain before
owning; it reads like a defense. Don't apologize for the customer's
feelings; apologize for the thing that happened.
RIGHT: "Your account was charged twice for the same month — that's a
billing error on our side, and we're fixing it today."
WRONG: "We apologize for any inconvenience this may have caused."
(Names nothing. Owns nothing. Is nothing.)
Words we use
1. "That's on us" — owns without hedging
2. "You're right" — validates before explaining
3. "Here's what we're doing" — moves to action fast
4. "by [specific date/time]" — concrete, not "soon"
5. "Let me know if…" — leaves the door open
Words we never use — and what to say instead
1. "Per our policy" → "Here's how this works:" [then explain it]
2. "As a one-time courtesy" → just do the thing, don't flag it
3. "Any inconvenience" → name the actual inconvenience
4. "Unfortunately" → own it directly instead of hedging
5. "I understand your frustration" → prove you understand by naming the problem
Voice owner: Layla Al-Nasser (CX Lead) — changes reviewed quarterly.support-policy.md — Mizan (excerpt)
Authority table
Tier Who What they can do
──────────────────────────────────────────────────────────────────────
Solo agent Any agent Apply account credit ≤ AED 150
Comp 1 month's subscription for clear Mizan error
Explain VAT features, walk through export steps
Process a refund ≤ AED 150 on billing errors
Respond to all standard ticket types
Manager Layla only Refund > AED 150
approval Annual plan changes or cancellations
Any timeline or roadmap promise ("will be fixed by…")
Any ticket flagged media / legal / escalation
Responses to repeat contacts > 3 tickets same issue
Never No role Admit legal fault or use the phrase "our liability"
Invent an order number, ship date, or fix date
engineering has not confirmed
Make a policy exception and describe it as policy
Promise a feature on the roadmap without PM sign-off
The escalation line (memorize this)
"If the amount exceeds AED 150, if the customer has mentioned a lawyer
or the press, if the ticket is about an annual plan change, or if you've
replied three times without resolution — stop typing and call Layla
before you send anything."
Never-say list — with safe alternatives
Phrase Why it's on the list
─────────────────────────────────────────────────────────────────────
"Per our policy…" Signals the policy matters more than the person.
Safe alternative: explain the actual rule in plain language.
"As a one-time courtesy…" Implies they're lucky we're helping them.
Safe alternative: just do it. Don't flag that it's exceptional.
"We apologize for any Apologizes for nothing — names nothing specific.
inconvenience." Safe alternative: name the specific error.
"I can guarantee this We can't guarantee it. When it happens again,
won't happen again." they have a screenshot.
Safe alternative: "We're fixing the root cause — here's what we changed."
"That's not something we Closes the door without offering a path.
can do." Safe alternative: "What I can do is [X] —
would that help?"macros.md — Mizan (excerpt, 2 of 10)
─── MACRO 1: VAT export / filing issue ───────────────────────────────────
Subject: Re: VAT export issue
Hi [Customer name],
Your VAT export [describe the specific issue — e.g. "showed a zero total"
/ "wouldn't download" / "is missing the Q1 transactions"] — that's on us
to sort out.
[Action taken — e.g. "I've re-run the export from your account and the
corrected file is ready to download from Settings > VAT > Export" / "I've
flagged this to the team and we're fixing it within 24 hours — I'll
follow up directly when it's done."]
If the deadline is pressing and you need the figures today, reply here and
I'll pull them manually and send them over.
[Your name]
Mizan Support
Placeholders: [Customer name], [describe the specific issue], [Action taken]
Shape check: opens with the problem named → owns it → states the action →
offers a path if urgent.
─── MACRO 2: Login / password reset ──────────────────────────────────────
Subject: Re: Can't log in
Hi [Customer name],
You're locked out of your account — let's get you back in.
[Action taken — e.g. "I've sent a password reset link to [email address]
— it's valid for 30 minutes. Check your spam folder if it doesn't arrive
in two minutes." / "Your account was locked after five incorrect attempts.
I've unlocked it — you can reset your password at [link]."]
Once you're in, let me know if anything else looks off.
[Your name]
Mizan Support
Placeholders: [Customer name], [Action taken], [email address or link]
Shape check: opens with the problem named → states the fix and the
timeline → leaves the door open.What you’ve proven — and what’s next
Clear the rubric and you’ve done something the free path can’t certify: you’ve built a real, professional-grade support foundation and demonstrated the judgment behind it. That’s the Foundation stage of “Certified Customer Support with Claude.”
From here the track turns the foundation into a working support operation, each module assessed the same way:
- Module 2 — the reply engine: the repeatable workflow that turns these three files into fast, on-voice replies at scale — triage, drafting, and the quality check that keeps the voice from drifting under queue pressure.
- Module 3 — triage and the new-hire ramp: routing live queues, spotting the bug in the ticket data, and onboarding Hani Al-Rashidi’s first week from your foundation files instead of from scratch.
- Module 4 — CSAT and VoC: reading the Q1 drop from 4.7 to 4.2, separating the signal from the self-selection bias, and building the improvement plan the data actually supports.
- Module 5 — incident response: running the 47-customer login outage, the three-hour window, the bulk reply workflow, and the post-incident review — then the capstone: one full support quarter, the Support-in-a-Box artifact, graded into the certificate.
First, make what you built reusable. Grab the Foundation toolkit — the support CLAUDE.md and the three templates that turn the documents you just wrote into files your whole team installs and inherits on day one. And if you’re rolling this across a team, the operating guide is the data, escalation, and sign-off layer that goes underneath all of it.