The most important support-draft problems are often factual or operational rather than stylistic: a missed request, an unsupported promise, a policy exception that was never approved, or an instruction the customer cannot safely follow.
Review a Claude draft against the original message and the approved sources before judging its tone. The question is whether the reply is supported and actionable, not whether it sounds like good customer service.
This guide starts with my observations about support tone, then provides a broader checklist of issues to inspect in your own drafts.
The Courtesy That Needed Cutting
When we tried Haiku for learner FAQ drafts, I found that a vague tone instruction could produce too much formal, repetitive courtesy. I had to remove substantial wording before the response sounded like a person addressing a specific question.
Refund complaints made the problem more consequential. A dissatisfied learner needs an acknowledgment of the actual concern and an authorized next step, not a paragraph that merely sounds sympathetic. Our rule keeps emotion- and money-related replies under human control.
The error categories below combine those observations with additional problems worth testing. They are not measured failure rates. When reviewing a draft, note what actually occurred: an unsupported promise, missing question, outdated rule, or empty wording. Specific labels help you fix the source, prompt, or process instead of treating every disappointing reply as the same model problem.
Use an Error Taxonomy Before Scoring Drafts
An error taxonomy helps reviewers record what actually needed correction. Without one, “bad reply” can mean anything from awkward wording to an unauthorized commitment.
Keep the categories tied to consequences and your business’s rules. You can refine them after seeing real pilot material, but preserve earlier definitions when comparing results over time.
Category | Example of a problem to inspect |
|---|---|
Request coverage | Answered one question and ignored another |
Unsupported fact | Treated a customer’s report as a verified account fact |
Policy fidelity | Omitted a condition or invented an exception |
Commitment | Promised a refund or deadline without authorization |
Information handling | Included unnecessary private or internal details |
Action clarity | Told the customer to take an unclear or unavailable step |
Escalation | Failed to flag a case the reviewer cannot resolve |
Tone | Used dismissive, excessive, or misleading reassurance |
The categories are a review design. Their inclusion does not imply a measured frequency for any model.
1. A Reply Can Miss the Main Request
A long customer message may include several issues. The draft can focus on the easiest one and leave the blocking problem unresolved.
For a fictional example, a customer says they cannot sign in and also asks how to export a file. A reply explaining export settings without addressing access is incomplete.
The reviewer should compare the whole message with the draft, not rely exclusively on a generated summary. A summary can omit the same issue the reply misses.
Ask for a coverage check listing each customer question and where the draft addresses it. Verify that list against the original message yourself.
A useful revision should preserve any unanswered issue as a clarification or escalation, rather than pretend the reply resolves everything.
2. Reported Facts Are Not Verified Facts
A customer may report a duplicate charge, missing data, or an account change. Their report deserves attention, but it is not the same as verification from the appropriate records.
A draft should not state “you were charged twice” unless that fact has been confirmed through the business’s process. It can acknowledge the report without making an unsupported conclusion.
Likewise, the model should not infer account status from a fragment of context. Supply only information the workflow is permitted to use and identify the source of important facts.
The reviewer needs to know which claims come from the message, current product documentation, and verified records. Combining them without distinction makes the reply harder to check.
3. Policy Conditions Can Disappear
A policy might allow an action only under specified conditions. A summary that retains the action but drops the conditions changes the rule.
In a fictional policy, “requests received within the stated period may be reviewed” does not mean every request qualifies for an automatic outcome.
Check the exact source passage and its current version. If the draft applies a policy to the customer, verify that the relevant facts have been established.
Do not ask Claude to create an exception because the customer’s circumstances seem reasonable. The authorized person decides exceptions under the organization’s procedures.
I would keep policy passages beside the draft during review. A source reference is useful only if someone actually inspects the support.
4. Helpful Language Can Become a Promise
Phrases such as “we will resolve this today,” “your refund is on its way,” or “you can recover everything” can create commitments beyond the available evidence.
A reviewer should scan for definite outcomes, dates, guarantees, and actions already described as completed. Ask whether the business has authorized and can fulfill each one.
When the next step is review rather than a decision, the reply should say that. Clear process language is more useful than unsupported reassurance.
A model can help rewrite the sentence after the boundary is identified, but it should not decide what the business is entitled to promise.
5. More Context Can Mean More Exposure
Supplying additional internal context may improve a draft, but it can also introduce information that should not appear in a customer reply.
Check whether the output quotes internal notes, identifies another person, or discloses details unnecessary to the request. Remove inappropriate information and examine why it entered the workflow.
For a pilot, use sanitized or fictional material where possible. For live work, follow the business’s data handling and access procedures.
A prompt telling the model not to reveal private information is not a substitute for controlling what it can access. The safest draft source is not automatically the largest source set.
6. The Next Step May Be Unclear or Impossible
A reply can end with an instruction the customer cannot carry out: use an unavailable menu, contact a nonexistent role, or provide information through an inappropriate channel.
Verify steps against current product documentation and the actual support process. If a step depends on account state or product version, preserve the condition.
Avoid sending several speculative troubleshooting steps simply to make the reply look useful. A supported clarification can be better than a long list of guesses.
Also distinguish asking the customer to act from performing an action on their behalf. The latter may require separate permission and authorization.
7. Tone Can Hide an Unresolved Problem
Friendly language is useful when it accompanies supported content. It is harmful when it makes uncertainty disappear.
A calm reply can state what is known, what needs checking, and what the customer can expect next under the approved process. It does not need exaggerated empathy or certainty.
I would judge tone after factual and policy review. Polishing an unsupported promise does not make it acceptable.
If a stylistic revision changes a factual claim or commitment, recheck that sentence. Tone editing can affect substance.
Turn Corrections Into a Better Pilot
Record the error type, supporting source, necessary correction, and final disposition. Separate minor edits from problems requiring rejection or escalation.
Look for recurring causes. The prompt may need clearer boundaries, the policy may be ambiguous, or the input may lack required facts. A model change is not always the right remedy.
If a failure has meaningful consequences, pause the affected workflow rather than asking reviewers to absorb it indefinitely. A draft-only pilot should remain reversible.
Do not publish error rates until the input set and review definitions are clear. A future report should explain the model, date, policy version, task set, and corrections.
When I Would Use This—and When I Would Not
I would use this taxonomy to inspect support drafts and design representative pilot cases. It helps turn vague dissatisfaction into specific repair work.
I would not generalize my tone observations into error rates for every support task, or treat a friendly response as evidence that the workflow is ready to send automatically.
Start with one fictional message containing two issues and one missing fact. Draft, review, and log the correction categories. Use [the human review checklist](14-support-review-checklist.md) to decide whether the final reply is ready.
No letters yet — be the first to write.