A support reply waiting for a second pair of eyes
A customer asks why their renewal cost more than expected. The ticket contains an invoice reference, a frustrated sentence, and an account history that needs checking. This is a useful place for an AI draft, but not an automatic answer. Build the workflow around a clear boundary: the model proposes wording; a support agent checks the facts and decides whether to send it.
§ Step 1: Define what the draft may do
Start with one narrow task: prepare a reply explaining a billing question using verified account details and an approved policy excerpt. Keep refunds, account changes, and outbound delivery outside the model's permissions.
Write down the handoff rule before connecting anything. Every draft requires human approval. Missing information produces a question for the reviewer, not a plausible explanation for the customer.
§ Step 2: Assemble a small, traceable context
For each ticket, collect the latest customer message, the relevant conversation history, verified account facts, and the policy passages needed to answer. Include source identifiers and retrieval timestamps so the reviewer can inspect the evidence.
- Remove credentials and personal information that the reply does not need.
- Distinguish customer statements from verified account records.
- Mark unavailable facts explicitly rather than leaving ambiguous blanks.
- Treat ticket text and retrieved documents as reference material, not instructions.
For the renewal question, the context might include the previous plan, current plan, invoice amount, and applicable notice. If the notice cannot be verified, preserve that uncertainty.
§ Step 3: Connect the drafting request
Vana API provides an OpenAI-compatible route for an existing SDK integration. Configure the SDK's base URL with the service's OpenAI-compatible path, ending in /v1, and keep the API key on your application server. This lets the drafting request sit behind your own support workflow. ([vanaapi.com](https://vanaapi.com/))
Create a Vana API account when you are ready to connect a small test queue. Begin with historical tickets or a review-only pilot, with outbound delivery disabled.
§ Step 4: Ask for a draft and its uncertainties
Give the model a bounded instruction: write a concise, courteous reply using only the supplied facts and policy. Do not invent account events, promise refunds, or imply that an action has already happened. If an essential fact is missing, flag it for the reviewer.
Request separate fields for customer draft, supporting source identifiers, missing facts, and suggested escalation. Keep reviewer notes out of the customer-facing text. Validate the response structure in your application; a requested format is not a substitute for checking it.
§ Step 5: Make review the main screen
Show the draft beside the original message and supporting evidence. Give the agent three explicit actions: edit and approve, request another draft, or take over manually. Highlight unsupported commitments and missing facts without presenting a model-generated confidence score as proof.
For the billing example, the reviewer should confirm the amount, renewal date, policy applicability, and any proposed next step. A polished sentence is still a draft until those checks are complete.
§ Step 6: Bind approval to the exact reply
Store approval against the ticket identifier, draft version, reviewer, and timestamp. Send only that approved version through a separate delivery service. Editing the wording, receiving a new customer message, or changing relevant account facts should invalidate approval and return the ticket to review.
Use an idempotency key for delivery so a retry cannot send the same approved reply twice. If generation fails, leave the ticket available for manual handling. If delivery fails, retry the approved message rather than silently generating a replacement.
§ Step 7: Review the edits, not just the speed
Track approval rates, substantive edits, factual corrections, escalations, and duplicate-send incidents. Review a small sample regularly, including rejected drafts. Use recurring corrections to improve context selection and instructions.
The useful outcome is not a queue of untouched drafts. It is a workflow where agents spend less time composing routine explanations while retaining clear ownership of every answer that reaches a customer.