AI Workflows · Guide
Hand Off an AI Customer Support Draft Without Losing Authority
Keep the customer’s request, source policy, draft status, and human approval visible before a reply is sent.
Treat an AI support reply as a proposal. Bind it to the correct case and current policy, show the agent the original request and evidence, require a named approval for consequential promises, and confirm the actual send result before closing the case.
Bind the draft to one case
A support queue contains similar names, repeated messages, and customers with different entitlements. Before an assistant drafts a reply, bind the request to the case identifier, the latest customer message, and the permitted account context. Show the agent what the model saw. A plausible answer for the wrong case can be worse than an obviously broken one. If identity or context is uncertain, stop drafting the specific promise and ask the agent to resolve the case record. Do not let a copied transcript from another ticket silently become the evidence for this customer. The draft should carry a visible case reference and revision so a reviewer knows whether it belongs to the open conversation.
- Check case identity.
- Use the latest customer request.
- Keep cross-case material out.
Show the policy that supports the answer
A support draft may say a refund, replacement, deadline, or exception is available. Require a current policy or authorized case note for each such claim. Put that evidence beside the draft rather than making the agent search after reading a persuasive paragraph. If the policy is missing, outdated, or ambiguous, the model should say that the answer needs review. It should not fill in a standard-sounding promise. Separate a courteous explanation from an action the organization has actually approved. This protects both the customer and the agent. It also makes policy changes easier to manage: when the source changes, drafts tied to old language can be identified and reviewed before they are sent.
- Link promises to current policy.
- Flag exceptions for a person.
- Do not infer approval from polite wording.
Illustrative prompt · adapt before use
Prepare a support handoff, not a message to send.
Illustrative case C104: customer requests a refund after 35 days. Policy P2 permits agents to approve refunds within 30 days; later requests need supervisor review. No exception is approved.
Return case ID, policy passage, proposed response, unresolved decision, responsible role, and current state.
Keep state DRAFT. Explain escalation without promising a refund. Do not invent approval, contact the customer, or close the case.Give the agent a focused review task
A generic “check this answer” button invites superficial review. Ask the agent to verify identity, factual claims, commitments, tone, and the requested next action. The original customer message, relevant history, policy passage, and proposed reply should be visible together. The agent needs an easy way to correct or reject the draft without sending it accidentally. For routine questions, this may be a quick check. For a complaint, safety concern, or account change, route to the person with the right authority. Human review is meaningful only when the reviewer sees the evidence and can change the outcome. NIST's AI RMF describes human oversight as a defined role; in support work that role must be explicit at the send boundary.
- Make review criteria visible.
- Allow rejection and revision.
- Escalate high-consequence commitments.
Distinguish draft, approved, and sent
A reply can be drafted, approved, queued, sent, or of unknown send status. Do not collapse these states into “done.” Record who approved the final wording and which version was sent. If a send operation times out, read the mail or support system result before trying again; a blind retry can produce two messages with different promises. Keep the case open while delivery is unknown. The customer-facing record should contain the actual response, not only the AI suggestion. This small state distinction prevents a draft from being mistaken for an answer and gives the next agent a reliable history. It also avoids closing a case that the customer has never heard back about.
- Record the approved version.
- Confirm send result.
- Investigate unknown status before retry.
Test exceptions with real support work
Use approved, de-identified examples that include a normal information request, an outdated policy quote, an angry customer, a duplicate ticket, an identity mismatch, and a request beyond agent authority. Write the expected route before running the assistant. Compare not only tone but whether the case reaches the correct person and whether a false promise is withheld. A support tool that handles easy questions well may still be valuable if difficult ones are safely escalated. Measure correction time and wrong-route cases during a small trial. Do not expand to all tickets because a few polished samples look good. Document which intents are supported and who owns the exceptions.
- Include identity and policy failures.
- Measure wrong routes.
- Release only proven intents.
Learn from corrected drafts
Collect a few categories of agent corrections: missing context, wrong policy, invented promise, unclear tone, and poor handoff. Review whether the issue came from source selection, instructions, or model behavior. Fix the source or route when that is the actual cause rather than adding another generic prompt rule. Keep the agent's final answer as the authoritative customer communication. Over time, sample sent replies and customer follow-ups for evidence that the workflow helps rather than merely moving labor into review. If agents repeatedly rewrite every draft, narrow the assistant's job to a useful step such as retrieving policy passages or proposing an outline. The tool should support the agent's judgment, not obscure it.
- Classify corrections by cause.
- Retain the actual sent reply.
- Narrow the task if review overwhelms value.
Sources and update note
Follow the linked official source before a product, price, plan, or policy decision.