Design a handoff a customer can trust
by Rasa team
The customer has already explained the problem. A handoff that makes them repeat it can erase the value of the conversation that came before.
For a conversation designer or customer-experience specialist, the useful deliverable is a handoff contract: when it happens, what the customer hears, what context travels, and what happens if nobody can receive it. You can design that contract before an engineer connects a support tool.
Start with the customer’s choice
In this fictional Horizon Travel example, a traveller asks to dispute a booking-change fee. The agent can retrieve a policy, but a staff member must decide exceptions. The names and dialogue below are invented for this exercise.
Customer: The fee doesn’t match what I was told. I want someone to review it.
Agent: I can ask the support team to review the fee. I’ll include the booking reference and your explanation so you don’t have to start again. Would you like me to send that?
Customer: Yes, but don’t include the medical reason I mentioned earlier.
Agent: I’ll leave that out. I’ll share the fee question and booking reference only.
The last turn changes the payload. A warm sentence followed by a full transcript would break the promise. Ask the engineer to show the actual receiving record during testing.
Specify the context packet
| Field | What belongs in it | What to leave out |
|---|---|---|
| Task | Review the disputed change fee | A guessed resolution |
| Reference | Authorized booking reference | Unnecessary identity documents |
| Customer explanation | The approved summary | Details the customer excluded |
| Agent actions | Policy retrieved; no booking changed | An unsupported claim that staff approved a change |
| Outstanding question | Whether an exception applies | A fabricated urgency label |
The receiving team should help define these fields. A summary is useful only if it supports their work. The tools and memory tutorial gives engineers an implementation starting point for deciding where context belongs; it does not by itself establish your privacy rules.
Design the failure path too
Write and test the following conversation states:
- Offer: explain why a human is needed and what information will be shared.
- Confirmation: allow the customer to correct or limit the summary.
- Delivery: wait for the receiving system’s result before claiming success.
- Recovery: if delivery fails or the team is unavailable, say what remains unresolved and offer the verified alternative channel.
For example: “I couldn’t send the request just now. No booking change has been made. You can try again or contact support through the help page.” Link only to a channel your team has verified. Do not invent a response time to soften the message.
A particularly awkward case is a timeout after the support system created a ticket. Repeating the action can produce duplicates. The designer’s requirement should be “check whether a request already exists before offering another send”; the engineer decides how the receiving system supports that check.
Run a short design review
Ask a support colleague to play the customer and another to inspect the received context. Test a normal request, a correction to the summary, an excluded sensitive detail, an unavailable queue, and a request to cancel before sending.
For each case, record what the customer was promised, what was actually sent, and what the receiving team could do next. Pass the case only when those three agree. Capture disagreements as changes to the contract, not as a judgement about whether the dialogue “sounds human.”
Leave the review with a revised example conversation and the fields engineering must verify. Bring them to Build Day if the integration is your current blocker.
NIST describes human-factors and domain-expert participation in its AI actor tasks. This handoff contract is our practical application of that perspective; it is not a claim that a particular dialogue guarantees trust.