You need an AI human handover plan before automation answers live customer enquiries or accesses order records. Define when it must stop, what it may do, who accepts responsibility and what happens if nobody is available. Otherwise, customers may receive unsupported promises while staff assume somebody else owns the problem.
Decide the transfer before launch
This guide assumes you have selected one bounded support task. The proposed controls below are operating recommendations, not vendor guarantees. OpenAI recommends human review where possible, with enough information for reviewers to verify outputs.[1] A handover therefore needs more than an apology or an email notification: a person must accept responsibility.
Set uncertainty thresholds around evidence
Confident wording is not evidence. Start with observable conditions: a successful lookup, verified customer ownership, current policy and no conflicting records. Use the following four bands. The approval band overrides the others: even a fully understood request can require a human decision because its consequences are significant.
| Band | Evidence or trigger | Permitted response |
|---|---|---|
| Answer | Approved low-impact question; current evidence; required identity checks passed; no conflict | Give a bounded answer supported by that evidence |
| Clarify | One missing detail the customer can safely supply | Ask one focused question; do not guess |
| Hand over | Conflicting records, failed lookup, unresolved ambiguity, policy exception or request for a person | Create a review case and pause substantive automated replies |
| Require approval | Refund, cancellation, account-access change or personal-data disclosure | Prepare evidence; leave the consequential action to authorised staff |
If you use numerical thresholds, evaluate each task against labelled examples with known expected decisions. A model-generated confidence percentage is not measured reliability. Test the languages customers actually use, including Hindi-English messages where relevant. Check whether summaries preserve negation, disputed facts and requests for a person. Conservative thresholds increase staff workload; permissive thresholds risk more incorrect automatic answers.
Separate permissions from approval
Instructions are not access controls. OpenAI documents a distinction between a model proposing an action and the application executing it. Strict tool schemas constrain argument structure; they do not establish business authorisation.[2] Platform permissions also do not replace customer-level ownership checks.[3] Verify identity and record ownership server-side, grant minimum access and deny everything else by default.
| Capability | AI permission | Human responsibility |
|---|---|---|
| Read support policy | Approved, current material only | Maintain policy revisions |
| Read order information | Authenticated customer's relevant records only | Resolve ownership failures |
| Propose a reply or refund | Draft or submit for review | Check evidence and consequences |
| Refund, cancel or change account access | No direct execution permission | Authorised staff decide and execute |
| Disclose or export personal data | No discretionary disclosure or bulk export | Use a restricted, verified process |
Microsoft recommends approval for high-risk actions and reliable ways to interrupt agents.[4] Our recommended implementation is specific: show the reviewer the original request, supporting records, policy revision, conflicts, proposed action and consequences. Bind approval to that exact action and current record version. Material changes require fresh review. Initially, keep execution in the existing staff interface: slower, but easier to supervise.
Make handover an acknowledged transfer
Assign a support queue, a duty owner and a backup. Set acknowledgement windows around actual staffing, including time zones and holidays. Outside those windows, explain that review is pending without inventing a deadline. If case creation fails, never claim a successful handover. Give a verified alternative contact route and alert staff through a separate monitored failure channel.
Keep a decision record, not just a transcript
- Case identity: case ID, correlation ID linking related events, customer reference and timestamps.
- Evidence: record references, retrieval times, conflicts and model, instruction and policy revisions.
- Proposed operations: validated tool arguments, permission-check results and escalation reasons.
- Responsibility: assigned queue, accepted owner, acknowledgement time and human decision.
- Outcome: actual action result, record version and customer-notification delivery status.
Restrict access, minimise personal data and define retention periods. A live debugging stream is not necessarily durable audit storage. OpenAI distinguishes application-state storage from abuse-monitoring retention; setting store: false is not a zero-retention guarantee.[5] Keep enough evidence to reconstruct decisions without copying credentials, payment secrets or unnecessary customer details into every record.
Hypothetical workflow: a disputed delivery
Everything in this example is hypothetical. Assume a Pune homewares SME has two support employees, one manager and a logged-in support form. A customer writes in Hindi-English that their parcel shows as delivered but has not arrived, and requests a refund. The business uses its own order records and internal review queue.
- Verify ownership: check the signed-in customer against the order before retrieving customer-specific information. An order number alone is insufficient.
- Apply both triggers: delivery status conflicts with the customer's account; the refund request independently requires approval. Neither confidence nor a successful lookup authorises payment.
- Save one case: include the original message, an English summary, verified ownership, timestamped delivery evidence, policy revision and missing investigation evidence. Deduplicate repeated processing of the same inbound message.
- Acknowledge truthfully: after saving succeeds, provide the case reference, explain that review is pending and state that no refund has been issued. Use the customer's preferred language where supported.
- Accept responsibility: a support employee acknowledges ownership, reviews the bilingual context and investigates. Further substantive automated replies remain paused.
- Resolve manually: the manager decides under the policy and executes any approved refund in the staff interface. Record the actual result, notify the customer and close the case.
Check the handover before expanding access
Test the whole responsibility chain, not only the quality of answers. Agree acceptable failure limits before launch and keep consequential actions disabled until the relevant checks pass. Review results by task and language: a good overall result can hide missed escalations in delivery disputes or poor summaries of mixed-language messages.
- Escalation: conflicting records and requests for a person always reach review in the test set.
- Promises: replies never invent refunds, completed actions or unsupported response deadlines.
- Identity: incorrect customer matches cannot reveal records.
- Persistence: retries avoid duplicate cases, and failed case creation produces truthful fallback messaging.
- Approval: changed records invalidate stale approvals.
- Ownership: unacknowledged queues alert the backup, including out-of-hours scenarios.
- Evidence: reviewers can understand the case without asking customers to repeat information.
Implementation scope: the researched design uses OpenAI Responses with business-owned records and queues. Named actions such as reading an order or creating a review case are custom business functions, not ready-made vendor operations.[2] Documentation establishes platform mechanics, not tested compatibility with your ticketing, payment or messaging systems. Those connections require their own implementation checks.
Questions to settle with your team
Should AI clarify when a customer asks for a person?
Do not make clarification a barrier to human support. Create the review case using available context. Ask only for information genuinely needed to route or verify it, and explain why. The customer should not have to persuade automation that their request deserves human attention.
What if the team cannot handle the review queue?
Reduce the scope of automation or staff the review window before granting more permissions. A growing unacknowledged queue is a capacity problem, not a reason to lower evidence standards. Keep customers informed and retain a usable alternative contact route.
Can a high confidence score bypass approval?
No. Confidence concerns estimated correctness; approval concerns authority and consequences. A clearly understood refund or account-access request can still require an authorised person's decision. Keep those rules separate so apparent certainty cannot expand the system's permissions.
Next, document one bounded workflow using the handover record above and rehearse its failure paths with staff. If scope is still unclear, read Is your business ready for an AI assistant? Use API and system integrations to frame the connection requirements. Add execution permissions only after evidence, ownership and fallback work reliably together.
Sources & further reading
Use the original guidance when checking details or planning implementation.
This research-assisted guide uses the primary sources linked above. Examples are illustrative unless explicitly identified otherwise. Check original documentation when implementing changes.
