AI customer service: a practical human handover checklist

Separate a human handover from an approval

An approval permits a specific proposed action; a handover changes who handles the request. The OpenAI Agents SDK documents approval flows that pause execution. Its “handoffs” feature transfers work between agents, so that technical label alone does not establish that a human has taken responsibility.

Ask what your business actually needs. A routine request might need a staff member to approve a date change while the assistant remains responsible for the conversation. A complaint might need a person to take over the whole case. Write those two outcomes separately in the workflow brief.

Sources: OpenAI Agents SDK: human-in-the-loop approvals · OpenAI Agents SDK: handoffs between agents

Define the requests that need a person

Use representative examples from your own work, with personal details removed. For an illustrative salon, a question about published opening hours can follow approved information. A dispute about a charged cancellation fee needs someone who can review the policy and the circumstances.

For a restaurant, answering where the menu is published differs from making a commitment about an allergy or an exceptional group booking. Decide which questions may use approved information, which require qualified staff and which actions are unavailable to automation. Do not treat an uncertain answer as permission to proceed.

Useful triggers include the customer explicitly requesting a person, conflicting information, a failed system action and a request outside the agreed permissions. Your team should also be able to take over deliberately. Define a fallback when the assistant or the connected service is unavailable.

1. List the routine questions the assistant may answer from approved information.
2. List actions that require approval, such as an exception to booking rules.
3. List cases that move fully to a person, including complaints and explicit requests.
4. Name the responsible team and its actual coverage for each case.
5. Choose the response customers receive when that team is unavailable.

Give the person a usable handover record

The receiving person needs the customer’s request, relevant conversation, attempted action and outcome. If a booking change failed, say that it failed; do not present it as confirmed. Include the reason for handover and the next decision needed, with only the information necessary to handle the case.

An example record could say: “Customer requests Friday instead of Thursday. Availability was checked, but no change was made because the notice period requires staff approval. Please confirm whether an exception is permitted.” This is an illustrative record, not a claim that a particular integration is available.

Decide where that record lives and who can access it. A notification by itself is easy to lose. The agreed system should preserve the request and make ownership visible. Staff should distinguish the original customer text from an AI summary and correct a misleading summary before using it.

Pause automation while the person is responsible

A late AI response should not arrive after a staff member takes over with different instructions. Test whether takeover prevents new automated actions and suppresses an answer already being generated when appropriate. The conversation should make clear when a reply comes from the team.

Agree what happens outside staffed hours. Recording a request for follow-up is different from providing live support. Do not advertise an immediate human response unless the agreed coverage supports it. Confirm whether your own staff or OneSync’s managed team owns each type of escalation.

Also define when a case is closed and how a later enquiry starts. Closing one request should not silently discard a new question. Conversely, retrying an old action must not reopen a resolved case or apply the same booking change twice.

Run a small, deliberate test set before launch

Use invented test identities and agreed test systems, rather than a real customer’s booking. Check the stored outcome, the person’s queue and what the visitor sees. A reassuring message on screen is not evidence that a request arrived or a record changed.

The following checks cover different failure modes. Record the expected behaviour, the actual result and who owns any correction. Retest the affected flow when permissions, booking rules or the receiving team change.

1. Ask a routine question and verify the answer against the approved source.
2. Request an unavailable or restricted action and check that it is not executed.
3. Ask for a person and confirm that the request and context reach the correct queue.
4. Take over while an AI answer is running and check for conflicting late replies.
5. Retry the same request and verify that no duplicate record or action appears.
6. Simulate an unavailable service and check that the original question survives.
7. Test an after-hours request and verify the stated follow-up expectation.

Review the workflow, not only the number of chats

Look at recurring handover reasons, failed actions, missing context and the time until a responsible person responds. A high automation rate is not useful if customers have to repeat themselves or staff spend time correcting unsupported commitments.

OneSync automates what should be automated and manages work that still needs people. For your setup, the available channels, actions, records and human coverage must be agreed explicitly. Bring one repetitive request and one difficult exception to the discussion; they reveal more than a generic chatbot demo.