A chatbot should hand over a short issue summary, the customer’s requested outcome, attempted steps, relevant references and anything still unresolved. It should also show where the request went and whether anyone has accepted it. Leave out unnecessary personal details and speculative conclusions.
The goal is to give the support agent a useful starting point without making the customer start again. That benefit depends on the record being accurate, accessible and used by the receiving team. The workflow below is a proposed design for a South African support team, not a claim of completed implementation.
1. Treat the request for a person as the transfer trigger
Start the handoff when the customer asks for a person, rather than making them finish another troubleshooting script. A proposed rule is to stop automated troubleshooting at that point, acknowledge the request and prepare the context already available.
The acknowledgement should distinguish a live transfer from a queued request. Do not say an agent is joining unless the support system confirms that state. If no one is available, explain the actual alternative: a queued ticket, a published support number or another approved channel. Only provide a response-time estimate backed by the team’s current operating arrangements.
For WhatsApp, the Source: WhatsApp Business messaging policy, updated on 23 September 2026, requires prompt, clear and direct escalation paths when using automation during the customer service window. It lists several possible paths, not only an in-chat agent transfer.
Agree the trigger, availability message and fallback with the support manager before configuring AI chatbots. The handoff is a service process, not just a sentence generated by the bot.
2. Summarise the issue without deciding the outcome
Write the summary around the unresolved issue and what the customer wants next. A proposed format is: “Customer reports [problem] about [relevant item] and requests [outcome].” Follow it with the current evidence and open question.
Keep the distinction between a report and a verified fact. In a hypothetical delivery case, “Customer says the parcel has not arrived” is different from “The courier lost the parcel”. The second sentence assigns a cause that may not be established.
Similarly, a request for a refund is not a refund approval. A billing complaint does not establish an incorrect charge. The handoff should prepare these matters for authorised human review, not decide payment, legal or security consequences.
Include a brief quotation only when exact wording matters, such as a disputed promise. Link it to the relevant message rather than copying the whole conversation into the summary.
Avoid personality labels such as “difficult customer”. If routing needs urgency information, record observable facts, such as an approaching deadline reported by the customer, and let the receiving person assess priority.
3. Record attempted steps and their actual results
List what happened, who performed it and what result is known. This allows the agent to avoid repeating a completed step while still checking an uncertain one.
Use separate entries for advice offered, customer-reported actions and system actions. In a hypothetical login case, “Bot suggested password reset” does not mean the customer reset the password. “Customer reports reset completed; sign-in still fails” is more useful.
For an automated lookup, record its result and retrieval time. A timeout should appear as “Lookup unavailable”, not “No matching account”. Those states lead to different human handling.
A proposed action record contains:
- The step or lookup performed.
- Whether the bot, customer or system performed it.
- The observed result or the customer’s reported result.
- A message or system reference supporting the entry.
Include any confirmed change the automation already made so the agent does not repeat it. Do not treat a proposed action as completed. The broader customer-service agent use cases can help a team define which steps belong before escalation and which remain human work.
4. Attach references that the receiving agent can use
Pass record identifiers and controlled links rather than unnecessary copies of personal information. Useful references may include the conversation, an authorised order record, an existing ticket and the policy passage the bot used.
The receiving queue needs permission to open those references. An inaccessible link is not usable context. Test access with the intended support role, not only an administrator account. If identity has not been verified, mark that state and avoid attaching account records whose ownership is uncertain.
The AI CRM integration glossary provides terminology for connecting the conversation to customer records. For this proposed workflow, that connection should expose only the records and fields needed for the support task.
If policy guidance influenced the bot’s answer, include its title, version or effective date and the relevant section. The agent should be able to inspect the basis of the answer rather than accept a paraphrase as authoritative.
A stale policy or unresolved record match should be flagged explicitly. A reference supports review; it does not settle eligibility, liability or the customer’s entitlement.
5. Remove unnecessary personal details before transfer
Apply a field allowlist before generating and storing the summary. Include only information needed to understand, route and continue the issue. Keep contact details in the approved support system where possible, with a reference in the handoff rather than another copy.
Exclude passwords, one-time codes, unrelated personal history and sensitive identifiers. If the customer has already shared sensitive information, do not repeat it in the summary. Flag that restricted content needs handling under the organisation’s approved process.
The Source: WhatsApp policy prohibits asking for or sharing full payment-card numbers, financial-account numbers, personal ID-card numbers and other sensitive identifiers. It also makes businesses responsible for necessary notices, permissions and applicable legal compliance.
Review the whole storage path: messaging platform, model provider, ticketing system, logs and exports. Source: OpenAI’s data controls documentation distinguishes abuse-monitoring logs from application state, with endpoint-specific retention and approval requirements for certain controls. Do not equate “not used for training” with “not stored”.
A responsible privacy or legal adviser should assess the actual South African data-handling arrangement, including POPIA obligations. Redaction alone does not establish compliance.
6. Validate the record and confirm delivery
Check the handoff’s structure and evidence before sending it to the queue. A proposed schema should permit explicit unknown values so the bot does not fill gaps with plausible guesses.
Source: OpenAI’s Structured Outputs documentation describes schema-constrained responses and exceptions such as refusals or incomplete output. A valid structure is not proof that the summary is factually correct. Your application still needs to check required references, allowed fields and whether claimed actions have supporting results.
Keep ticket creation under application control. The Source: function-calling documentation describes model tool requests followed by application-side execution. A request to create a ticket is therefore not confirmation that a ticket exists.
Use a transfer identifier to make retries safe against duplicate creation. Store the confirmed ticket reference and distinguish queued, accepted and failed states. If summary generation fails, a proposed fallback is a minimal transfer record with the escalation request and authorised conversation reference. Do not trap the customer in automation because the summary failed.
Reusable handoff record and release checklist
Use this proposed template as the support record, with unknown values stated explicitly rather than inferred.
Chatbot-to-human handoff
- Transfer: unique transfer ID; request time and time zone; channel; conversation reference.
- Issue: customer’s reported problem and requested outcome, without a guessed cause or approval.
- Evidence: separate customer statements from system-confirmed facts; attach supporting message or lookup references.
- Attempts: step, actor, result and supporting reference; distinguish suggested, completed, failed and unknown.
- Relevant records: authorised order, account or existing ticket references; identity verification state.
- Guidance used: policy title, version and relevant section, or “none used”.
- Open questions: missing details, contradictory statements, stale lookups and possible duplicates.
- Ownership: receiving queue, confirmed ticket reference, transfer state and next human task.
- Customer message: what the customer was told about the transfer, availability and next contact route.
Before release
- Each factual conclusion has supporting evidence or is marked unverified.
- Unnecessary personal details, secrets and sensitive identifiers are excluded.
- The receiving role can open the authorised references.
- Existing-ticket checks are complete, or possible duplication is flagged.
- Ticket creation is confirmed, or failure and fallback are recorded.
- Consequential decisions remain with an authorised person.
Worked walkthrough: normal, missing and duplicate cases
Use hypothetical cases to check what the agent should receive and do. All identifiers and timings below are fictional.
Normal case: A customer asks for a person about hypothetical order ORD-482. They report non-delivery. A lookup at hypothetical 10:15 SAST shows “in transit”; the customer has already checked the tracking page. The bot records those facts separately and requests the delivery-support queue.
The expected human task is to inspect the authorised courier record and explain the next available option. The agent should not ask the customer to check the same page again without a reason. The summary must not claim that the parcel is lost or promise compensation.
Missing and ambiguous case: The customer says “the second order” but gives no reference. A lookup is unavailable. Transfer with “Order not identified; lookup unavailable”, not “Order missing”. The expected human task is to identify the order through the approved verification process. The bot should not force another questionnaire before honouring the transfer.
Possible duplicate case: An authorised lookup finds an open delivery ticket, but the new message mentions a different item. Record “Possible related ticket; relationship unconfirmed”. A person should compare scope before merging or closing anything. If a retry follows a timeout, the application should first check whether the original transfer already created a ticket.
7. Evaluate whether agents can continue without repetition
Evaluate the proposed workflow against source conversations and receiving-agent tasks, not just whether tickets appear. Support staff should review normal transfers alongside missing references, mixed issues, unavailable lookups, sensitive content and failed delivery.
For each sample, ask whether the agent can identify the unresolved issue, see what was attempted and locate the supporting evidence. Record unnecessary repeat questions, unsupported conclusions, inaccessible references, duplicate tickets and exposed personal details separately.
Compare with the team’s existing handoff process using similarly scoped cases. Any improvement claim needs actual evaluation; a neat summary alone does not demonstrate less repetition. Set acceptance criteria with support and privacy owners before expanding use. A proposed release-blocking criterion is any observed secret copied into an ordinary support summary.
For channel-specific planning, consult the WhatsApp business agent use cases. If your business needs help defining handoff fields, exception handling and queue ownership within AI automation, get in touch to discuss the scope before connecting live records.
FAQs
Resolve handoff exceptions by preserving the request and making uncertainty visible to the receiving person.
Should the chatbot send the whole conversation to the agent?
Not as the default summary. Send the structured handoff and an authorised conversation reference. The agent may need surrounding messages to check wording or context, but copying the entire transcript into every destination can spread unnecessary information. Define who may access the original conversation and how restricted content is handled. Keep the summary short enough to scan without hiding unresolved questions.
What if the customer refuses to provide an order number?
Transfer with the order reference marked unknown. The request for a person should not depend on completing every field. State what is missing and whether any lookup was attempted. The receiving agent can explain the approved verification route and why particular information is needed. Do not guess an order from a similar name or attach records that may belong to someone else.
What if nobody is available to accept the handoff?
Create a queued request if that route is supported and confirm it only after successful creation. Explain that no live agent has accepted it, and provide the approved alternative contact route. For WhatsApp follow-up, check the customer service window: the policy permits replies without templates within 24 hours of the user’s message, while messages outside that window require approved templates. Human review should also check applicable permission requirements.
Sources
These primary documents support the channel, data-handling and integration facts referenced above.