AI-Drafted Replies: Agents Approve, AI Types

TL;DR: Most of an agent’s day is writing variations of answers the team has already written. AI drafting collapses that into review-and-edit: a draft grounded in your help center and past resolved tickets appears in the composer; the agent fixes it and sends. The human stays accountable for every word. This guide covers grounding, the tone and accuracy guardrails, when the draft must be skipped, and how to measure it with edit distance and CSAT rather than vibes.

This guide is part of the AI for Customer Support series. For triage, which should ship first, since category labels make drafts better, see AI ticket triage.

Why drafting is the second workflow, not the first

Drafting is where AI touches the customer for the first time, but with a human between the model and the send button on every message. That makes it the right middle step between internal-only triage and the fully autonomous chatbot: you get most of the speed win while an agent still owns accuracy and tone.

The economics are simple. An experienced agent answering a routine billing question spends two minutes finding the relevant macro or past ticket, three minutes adapting it, one minute sanity-checking. A grounded draft compresses that to under a minute of read-correct-send. Multiply by 40 tickets a day per agent. The catch is that a wrong draft can be worse than no draft: reviewing text is cognitively cheaper than writing it, which means plausible errors slide through. Everything in this guide exists to manage that trade.

What a good drafting setup looks like

Three tiers, in ascending order of investment:

Tier	Setup	Grounding	Fits
1. Assistant + paste	Agent pastes ticket into ChatGPT/Claude/Gemini with a standing prompt	Whatever the agent pastes in	Pilots, small teams, mind data policy
2. Helpdesk-native	Zendesk, Intercom (Fin), Freshdesk, Help Scout AI features in the composer	Vendor’s indexing of your help center + macros	Most teams; fastest path
3. Custom pipeline	Your own retrieval over docs + resolved tickets, API-called model, draft injected into the helpdesk	You control it fully	High volume, strict compliance, unusual stack

Tier 1 is a legitimate two-week pilot: five volunteer agents, a shared prompt, measured handle time. Before running it, clear the data question, customer PII pasted into consumer AI tools is exactly what your acceptable-use policy should govern. Use business/enterprise tiers with training opt-outs, or redact identifiers.

Whichever tier, the architecture that matters is the grounding. An ungrounded model asked to answer a billing question will produce something fluent and plausibly wrong, a hallucination in your brand voice is the specific failure this workflow risks. Grounded drafting means the model is handed the relevant help-center articles, the customer’s context, and one or two similar resolved tickets, and is instructed to answer only from those sources. This is the same retrieval-augmented generation pattern that powers support chatbots, with the agent review as an extra safety layer. If your knowledge base is thin or stale, fix that first, the AI knowledge base use case covers building one that both agents and models can retrieve from.

The drafting prompt

The standing prompt (Tier 1) or system prompt (Tiers 2-3) should carry your voice guide and your rules, not just “reply to this ticket”:

You draft replies for [company]'s support team. An agent will review and edit
before sending, but draft as if they won't.

Voice: plain, direct, specific. Second person. No exclamation marks. One empathy
sentence maximum, and only when the customer reported a real problem. Apologize
only if we made an error. Never say "I understand your frustration."
Structure: answer first, steps second, links last. Under 150 words unless the
fix requires more.

Rules:
- State policy ONLY if it appears in the provided sources. Quote or link the source.
- If the sources don't cover the question, say so in the draft and add
  [NEEDS HUMAN INPUT: <what's missing>] instead of guessing.
- Never promise refunds, credits, timelines, or roadmap items. Draft the language
  around the decision and mark the decision point: [AGENT DECIDES: refund y/n].
- Match the customer's language.

Sources:
[retrieved help-center articles]
[1-2 similar resolved tickets with their final replies]
Customer context: [plan, tenure, prior ticket count]

Ticket:
[subject + thread]

The two bracket conventions do real work. [NEEDS HUMAN INPUT] converts the model’s uncertainty into a visible flag instead of a confident guess. [AGENT DECIDES] keeps commercial decisions with the human while letting the model do the typing around them. Agents learn to scan for brackets first.

Guardrails: tone

Models drift toward a recognizable register, over-apologetic, over-hedged, slightly saccharine. Customers read it as canned even when the content is right. Counters that work:

• Write the voice guide from real replies. Pull ten replies from your best agent, extract what makes them good (answer-first structure, concrete steps, no filler), and encode those as rules with examples in the prompt. Rules beat adjectives: “no exclamation marks” outperforms “sound professional.”
• Ban your anti-patterns by name. Every team has phrases it hates. List them. Models follow negative lists well.
• Calibrate empathy to the ticket. A how-to question needs zero empathy sentences; an outage apology needs a real one. Let the triage sentiment label (from your triage system) set the register.
• Let agents keep their signature moves. Drafts are starting points. An agent who always adds a personal sign-off should keep doing it, that residual human variance is what keeps the whole queue from sounding like one bot.

Guardrails: accuracy

Tone failures embarrass; accuracy failures cost money. The layered defense:

1. Retrieval-only policy statements. As in the prompt: no source, no claim. Drafts should cite which article backs each policy statement so verification is a click, not a search.
2. A never-auto-draft list. Some ticket types skip drafting entirely, the agent writes from scratch or from a human-approved macro: legal threats, security reports, data-deletion requests, anything involving a named regulator, harassment reports. Publish the list; wire it to triage flags so the composer doesn’t even offer a draft.
3. Verify-before-send classes. Money (refunds, credits, plan changes), account access, and anything quoting a number: the agent must open the cited source before sending. Make this a checklist item in QA scoring, not an honor system.
4. Freshness discipline. Drafts are only as current as the docs behind them. When policy changes, update the help center the same day, a model retrieving last quarter’s refund policy will confidently draft last quarter’s answer.

Macros: regenerate, don’t just accumulate

Macro libraries rot. The 300-macro library where 40 are used and 60 contradict current policy is the norm, and AI helps in both directions:

• Mine resolved tickets for missing macros. Cluster last quarter’s tickets by category (your triage labels again); where agents hand-wrote the same answer fifty times, draft a macro from the best-rated instances and have a lead approve it.
• Audit existing macros against current docs. Feed each macro plus the current relevant articles to a model and ask for contradictions. Retire or fix what it flags, with a human confirming each verdict.
• Prefer grounded drafts over static macros where you can. A macro is a cached answer that goes stale; a grounded draft is generated against current docs per ticket. Keep macros for the truly fixed (outage acknowledgment, legal-required language) and let drafting handle the rest.

Rollout and measurement

1. Baseline (2 weeks). Median handle time, first-contact resolution, CSAT, segmented by ticket category, because drafting helps routine categories far more than complex ones.
2. Pilot pod (weeks 1-4). Three to five volunteers, not conscripts. Same queues as a control group if volume allows.
3. Track edit distance. How much do agents change drafts before sending? Roughly: <10% edits = the draft is working; 10-50% = useful skeleton; consistently >50% or full rewrites = grounding or prompt problem in that category. Most helpdesk tools expose this; in a Tier-1 pilot, sample manually.
4. Track CSAT per-category, not aggregate. The failure you are watching for is a small CSAT drop on emotional or complex tickets masked by flat scores on routine ones. If it appears, add those categories to the never-auto-draft list.
5. QA both populations. Score AI-assisted and from-scratch replies on the same rubric, AI-scored QA makes 100% coverage feasible. If assisted replies score lower on accuracy, tighten grounding before scaling.
6. Expand by category, not by team. Roll drafting out to the categories where the pilot’s edit distance was low, and hold it back where it wasn’t.

For the ROI arithmetic, what handle-time savings are actually worth, and what to net against tooling and review costs, use measuring AI ROI. A fuller worked example of this workflow lives in AI for customer support replies.

The review habit problem

The known long-term risk of any human-review system: reviewers habituate. Month one, agents scrutinize every draft; month six, they skim and send, and review has quietly become rubber-stamping. Three countermeasures:

• Seed audits. Periodically inject known-flawed drafts (wrong number, stale policy) into QA samples and measure catch rate. Falling catch rate = habituation; retrain.
• Keep edit distance visible per agent. An agent whose edit rate drops to zero across all categories including complex ones is skimming.
• Make accountability explicit. The agent’s name is on the reply; the policy says the sender owns the content. This is a culture line worth stating plainly at rollout, and it belongs in the adoption plan.

FAQ

Will customers notice AI-drafted replies? They notice bad replies regardless of author. Grounded, agent-edited drafts read like your team on a good day. Watch per-category CSAT and edit distance; those tell you before customers do.

Should we disclose AI assistance? For agent-reviewed replies, most teams treat drafts like macros and do not disclose; autonomous responses (chatbots) should be disclosed. Decide once, write it into your acceptable-use policy, and stop improvising per ticket.

How do we keep drafts from inventing policy? Retrieval-grounding plus citation: the model may only state what appears in provided sources, and money/legal/security replies require the agent to verify the cited source before sending.

What handle-time improvement is realistic? Teams commonly see 20-40% on routine, well-documented categories and little to nothing on complex or emotional tickets, which is fine, because those are the tickets you want agents writing by hand anyway. Measure your own baseline; don’t budget from a vendor’s headline number.

---

Part of the AI for Customer Support guide by Webisoft. Not sure where your company stands? Take the free AI-Readiness Assessment.