AI Adoption GuideSupportResolve
Tone and policy compliance review
An adversarial LLM reviews drafted replies for brand voice, empathy, policy adherence, and risky commitments before send.
Support processIntakeTriageAssignInvestigateResolveConfirmClose
By Don, DoneThat’s AI coach · updated
A pre-send check reads the draft, not the customer
One system sits between a written reply and the customer. It reads the draft and returns findings, not a rewrite. It checks four things. Whether the wording matches the brand's voice. Whether it acknowledges the situation the customer described. Whether it follows written policy. And whether it commits the company to something nobody approved. The last one is the reason the check exists at all.
This is the cheapest control in the resolve stage, and it is the last one available. Everything upstream can be right and the reply can still promise a refund that policy does not allow. Once sent, that promise is what the customer holds the company to. Arguing about it afterward costs more than the refund would have. A reviewer that runs before send is worth several that run after.
The checker is adversarial by design. Its job is to find the problem, not to praise the draft. It should not rewrite the reply, because a rewrite hides what was wrong. Findings name the sentence, the rule it breaks, and the severity. The agent then decides what to do with each one. A tool that silently repairs drafts teaches nobody anything.
Turn voice and policy into rules a checker can apply
A style guide written for humans is not a rule set. Phrases like warm but professional cannot be evaluated. Convert them into checks with examples on both sides. Do not open with an apology for the customer's own error. Do not use exclamation marks in billing replies. Each rule needs a name, so a finding can point at it. Unnamed rules produce findings agents cannot argue with.
Policy rules are the ones with money attached. List every commitment an agent may not make without approval. Refund amounts above a threshold, credits, waived fees, and delivery dates the company does not control. Add anything with a legal shape: liability, guarantees, and statements about another company's fault. Those are the findings that should stop a send. Everything else is advice, and it should be labeled as advice.
The rules need an owner and a version. When policy changes, the checker changes the same week, or it starts blocking correct replies. A stale rule that flags the new refund window teaches agents to override findings. Once overriding becomes routine, the check is decoration. Record who changed each rule and when, somewhere agents can read it. A rule nobody can trace is a rule nobody defends.
Separate a hard block from a suggestion
Findings need exactly two weights, and mixing them ruins both. A block stops the send until a person resolves it. A suggestion sits next to the draft and can be ignored. Blocks should be rare, specific, and tied to a written policy line. Tone findings are almost never blocks. Commitment findings almost always are. That split should be visible in the rule table itself.
Severity should also read the situation, not only the sentence. The same phrasing is fine on a routine question and wrong on a complaint about a failed order. Feeding the checker the ticket's priority helps here. The priority score assembled at triage is one source for that signal. Context changes the register, and the rules should state how. A rule that ignores context will be overridden until it is switched off.
Every finding needs the sentence it refers to. A verdict on the whole reply is useless to the person fixing it. Quote the span, name the rule, and say what would clear the finding. Agents act on findings they can act on in ten seconds. Anything vaguer gets dismissed, and the check quietly stops mattering. Specificity is what keeps a review tool alive past its second month.
Screen a delayed-flight reply at a regional airline
The airline in this example does not exist. A regional carrier cancels an evening flight because of a crew shortage. A passenger writes overnight asking for a hotel refund and a seat on the first flight out. An agent drafts a reply in three minutes. The draft is polite and reads well. The checker runs before it can be sent.
Three findings come back. The first is a block: the draft says the airline will cover the hotel and any meals. Meal cover is not in the policy for crew-related cancellations, and the sentence puts no limit on it. The second is a block: the draft states the delay was the airport's fault. Assigning blame to another party is on the legal list. The third is a suggestion about an exclamation mark.
The agent fixes both blocks in under a minute. Hotel cover stays, with the policy limit of $180 stated plainly. The meal sentence is cut. The blame sentence becomes a neutral line about a crew shortage. The exclamation mark stays, because the agent judged the tone right for a tired passenger. The reply sends with two rule names recorded against it, and the override is recorded too.
Over-flagging, blind spots, and the checker nobody reads
Too many findings is the common failure. A checker returning six items on every draft gets clicked through without reading. Tune the rule set until a clean draft returns nothing at all. Silence on a good reply is what makes a finding meaningful. Count findings per draft each week, and treat a rising number as a rule problem. It is rarely a sudden drop in agent quality.
The blind spot runs the other way. A checker tuned on obvious phrasing misses the polite commitment. We will make sure this does not happen again is a promise about the future. So is any sentence naming a fix date the company has not committed to. Collect the misses agents report and add them as named rules. That list grows slowly and ends up worth more than the original rule set.
The third failure is scope confusion. A tone checker asked to verify facts starts second-guessing the account data. Keep it on wording and commitments. Whether the reply is factually grounded is a property of how it was drafted. Whether a technical instruction is correct belongs with the engineer reviewing the generated snippet. One checker doing three jobs does all three of them poorly.
The agent still sends, and the policy owner still decides
An override needs to exist, and it needs a reason field. Agents can dismiss suggestions freely and with no explanation. Overriding a block should require one line saying why. That line is not a punishment. It is the fastest source of rule corrections anyone has. Read the override log every week. Most entries will name the same two or three rules, and those rules are the ones to rewrite.
Some drafts should never be cleared by the checker alone. Replies to a formal complaint, to a regulator, or to a customer threatening legal action go to a manager. So does any reply promising money above the agent's authority, even where policy allows the amount. The checker can flag those; it cannot approve them. Route them by queue rule, not by trusting a model to notice.
The policy owner sits outside support. Legal, finance, or the operations lead owns what the company may commit to. Support owns whether the wording is decent. Those two roles should sign the rule table together. Actions attached to a reply keep their own approvals, since executing a refund is a separate permission. Sampling after send is a review of closed tickets, and it answers a different question.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first