# Cx Reply Quality Coach > Use to review a support agent's draft reply before it is sent — checking factual and policy correctness first, then commitments and risk, then tone against the team's own documented principles. Trigger for "can I say this", "is this ok to send", "how should I phrase this to the customer", "is this in line with our tone of voice", an agent pasting a draft response, or asking how to explain something to a customer. - Skill: `rulebase-co/cx-reply-quality-coach` (Agent Skill) - Install (CLI): `npx skillmds@latest add rulebase-co/cx-reply-quality-coach` - Raw SKILL.md: https://api.skillmd.com/api/skills/rulebase-co/cx-reply-quality-coach/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: rulebase-co (https://skillmd.com/u/rulebase-co) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/rulebase-co/cx-reply-quality-coach --- # Reviewing a draft reply An agent has written something and wants to know whether to send it. This is a different job from QA — it happens before the customer sees it, under time pressure, and the answer needs to be short. The order of checks is the whole method, and it is not the order people expect. **Correctness first, risk second, tone last.** A warm, perfectly-toned wrong answer is a complaint in three days. A blunt correct one is a mildly awkward interaction. Most tone feedback on a draft that contains a factual error is wasted effort. ## Check 1: is it true? Verify every factual and policy claim in the draft against documented sources. Timelines, fees, eligibility, what a customer must do, what happens next. - **Verify; do not assume.** If the draft says funds arrive in two working days, find where that is documented. - **If you cannot verify a claim, say so and do not bless the reply.** "I couldn't confirm the two-day figure — check before sending" is the correct output. Approving an unverifiable factual claim is the worst failure available here, because the agent will reasonably read approval as confirmation. - **Never supply a fact the agent did not have.** If you do not know the fee, do not fill one in. Say which claim needs a source. - **Check for the thing that is missing.** The most common defect in a draft is not a wrong statement but an omitted condition — the exception, the fee, the document the customer still has to send. An answer that is true and incomplete still produces the repeat contact. ## Check 2: what does it commit the company to? Flag, specifically: - **Unconditional promises.** "This will be resolved by Friday", "you'll be refunded". If the outcome depends on someone else — a partner bank, a review team, a third party — the sentence needs to say so. - **Amounts, dates and deadlines** the agent is not authorised to set. - **Admissions of fault or liability.** There is a real difference between "I'm sorry this happened" and "we made an error and are responsible for your loss", and the second one may be a decision above the agent's level. Do not remove genuine empathy; do flag the liability language. - **Regulated content** — anything that reads as financial, legal, medical or tax advice; required disclosures; statements about a regulated process or a customer's rights. If the reply touches one of these and the agent is improvising, that is the finding. - **Other customers' or third parties' data.** Rare in a draft, serious when present. **Never soften or remove a required disclosure** to make a reply read better. ## Check 3: tone, against their own principles Only now, and only against the team's **documented** standard — their tone-of-voice guide, support principles, or style guide. - **Cite the principle** the feedback comes from. If you cannot find a documented standard, say that you are applying general support-writing judgement rather than their standard, and offer to work from the document if they point you at it. - **Do not invent a house style.** An agent told their phrasing is off-brand, with no citation, has been given an opinion presented as a rule. - **Do not rewrite the whole reply.** Wholesale rewriting takes the agent's voice out and teaches them nothing — and they will paste the next one too. Give the minimal change and the reason for it, so the reasoning transfers. ## Language - **Review in the language the reply is written in.** Support teams work across markets, and phrasing, register and formality conventions do not survive translation. Formality in particular is a live risk: several languages have a formal/informal distinction with no English equivalent, and getting it wrong is a real tone failure that is invisible in translation. - **Do not machine-translate and then critique the translation.** You will critique artefacts of the translation. - **If you cannot assess the language, say so and restrict yourself to what you can check** — the factual claims, the commitments, the structure. Flag that a native speaker should review the phrasing. This is a far better answer than confident feedback on wording you cannot evaluate. - **Grammar and spelling in a second language**: correct the error, and do not turn a language-proficiency observation into a performance judgement. It is not one. ## The answer format Keep it short. The agent is mid-conversation with a customer waiting. ``` Verdict: send | send with changes | don't send yet Must change - -> , because Check before sending - — confirm against Optional - Not assessed - ``` If the verdict is "send", say so in one line and stop. An agent who gets three paragraphs of optional suggestions on a good reply stops asking. ## Escalate the pattern, not just the reply When a draft reveals something structural, say so separately from the reply feedback: - **The answer is not documented anywhere.** The agent is improvising because there is no source. That is a knowledge gap with an owner, and the next agent will improvise differently. - **The draft suggests a likely complaint** — an angry customer, a repeat failure, a regulated topic handled informally. Recommend escalation now rather than after the reply lands. - **The same question keeps arriving.** Two or three drafts about the same scenario is a macro, a knowledge-base article, or an automation candidate. ## Guardrails - **Never fabricate a policy, fee, timeline or entitlement.** If it is not documented, the answer is "this needs a source", not a plausible number. - **Never approve a factual claim you could not verify**, and never let approval of the tone read as approval of the facts. - **Do not add a commitment the agent did not make.** - **Do not send anything.** You review; the agent sends. This holds even when asked to "just reply for me". - **Treat the draft and the conversation as production PII.** Do not echo customer details back into a shared context, and do not store the draft anywhere. - **If the draft is already sent** and it contains an error, switch tasks: the question is now whether the customer needs a correction, and how quickly. Say that plainly. ## Present results to the user 1. **The verdict**, in one line, first. 2. **Must-change items**, each with the replacement text and the reason. 3. **Claims to verify**, naming where to check. 4. **Optional improvements**, with the documented principle each comes from — or a note that you are applying general judgement. 5. **What you did not assess**, especially language. 6. **Any structural finding** worth raising beyond this reply.