KB-grounded draft reply

Agents spend much of the day rewriting the same explanation. A grounding model takes that first pass. It reads the ticket and finds the help articles that cover it. Then it writes a reply in the company's voice. Every claim in the draft points back to the article it came from. Zendesk Generative AI and Intercom Fin both work this way. The citation is not decoration; it is the thing that makes review fast.

The draft is a suggestion in a text box, not a sent message. Nothing leaves until a person clicks send, unless a written policy allows otherwise. That default matters more here than at most steps. A reply is the company speaking. A wrong account change can be reversed, but a wrong sentence has already been read. The customer keeps the screenshot.

Grounding is a restriction, not a boost. The model may only assert what the retrieved articles say. When the articles do not cover the question, the honest draft is short and says so. An ungrounded paragraph that sounds plausible is worse than an empty box. The empty box sends the ticket to a person. The plausible paragraph gets sent to the customer. Configure that failure on purpose.

Retrieval quality is a content problem before it is a model problem. Most help centers carry three kinds of rot. Articles for features that no longer exist. Two articles that quietly disagree. And unpublished drafts that the search index picked up anyway. Clean those out before the first draft is generated. The model will retrieve whichever one ranks highest, and it has no way to know which is current.

Decide which sources the model may quote to a customer. Public help articles, yes. Internal runbooks and engineering notes, usually not. Those documents hold workarounds, known defects, and language nobody cleared for customers. Mark each source with an audience field and filter on it at retrieval time. Publish that filter as a rule, not as a habit. One mislabeled internal note can put an unreleased feature in a customer's inbox.

Each article needs an owner and a review date. A grounded system spreads whatever is in the library faster than any human could. That is useful when the library is current and expensive when it is not. Pull articles past their review date out of the retrieval set rather than trusting them. A missing answer costs one escalation. A confidently outdated answer costs the customer's trust in every answer after it.

The order matters. Retrieval runs against the ticket text and the account context. Drafting then runs against the retrieved passages only. A model that drafts first and cites afterward will find sources for whatever it already wrote. That is backwards, and it produces citations that look right at a glance. Reviewers stop checking links after they find five good ones in a row.

Account specifics come from records, not from inference. The plan name, the billing date, and the order number belong in the draft as retrieved values. Where account and order data is attached at intake, the draft can use it directly. A model asked to guess a billing date will produce a very confident wrong one. A reviewer can fill a blank faster than they can catch an invented date.

Draft structure should be fixed, not left to the model's taste. One line that names the specific problem. The answer, in as few sentences as it takes. The exact steps, numbered, when there are steps. And one line about what happens next. Fixed structure makes bad drafts obvious, because the broken part sits in a known place. Reviewers get faster when every draft looks the same.

Everything below is invented. A platform hosts courses built by independent instructors and pays them monthly. An instructor writes on the 9th. Her payout has not arrived, and she wants to know whether her account is on hold. Her tone is worried rather than angry. The help center has one article on the payout schedule and one on payout holds. Both are current.

Retrieval returns both articles and one internal note, which the audience filter drops. Account context shows a payout of $2,140 sitting in a pending state since the 5th. It also shows an unverified tax form on the account. The schedule article says pending payouts settle within five business days. The holds article names an unverified tax form as a common cause. The draft uses both.

The generated reply names the amount, the pending date, and the tax form. It links the holds article and gives the one action she needs to take. It does not say when the money will land, because no source states that. The agent adds a sentence confirming the form is the only outstanding item. She checks the amount against the ledger, then sends. Total handling time is about ninety seconds.

The first failure is quiet grounding drift. The model cites an article that is broadly on topic, then adds a sentence the article does not support. Reviewers approve it because the citation is there and the tone is right. Check drafts against sources at the sentence level during rollout, not at the paragraph level. Sample a fixed number every week after that, and keep sampling once the novelty wears off.

The second failure is a retrieval miss that reads like an answer. A customer asks about an edge case, retrieval returns the general article, and the draft answers the general question. The customer then reads a reply that does not address what they asked. Reopen rates catch this later than the agent could have. Give reviewers a one-click way to mark a draft as off-target.

The third failure is tone applied to the wrong situation. A cheerful template on an outage or a billing error reads as indifference. Severity should change the register, and that judgment does not come from the article. Signals from a priority score built on sentiment and tier can gate which template is used. A separate pass for commitments and empathy is its own review before send.

The person who clicks send owns every sentence in the reply. That stays true even when they changed nothing. Support leads should say it out loud when the tool is introduced. Draft assistance moves the work from writing to checking, and checking is real work. An agent approving forty drafts an hour is not checking them. Volume targets should move when the tool arrives, not stay where they were.

Some replies should never be auto-approved, whatever the confidence score says. Anything touching money owed, legal terms, data deletion, or an open complaint goes to a human every time. So does any reply to a customer who has already escalated. Write that list next to the queue, not inside a model prompt. Prompts get edited without a change record. Queue rules do not.

Where a reply also changes the account, the two decisions stay separate. Executing the change belongs to an agent with caps and an audit trail, under its own approvals. The words describing the change belong to the person sending them. After the send, the follow-up asking whether it worked is its own message on its own timing. Drafting, acting, and confirming are three jobs, and merging them removes two review points.