Preparing a live transfer
What should an AI receptionist do before it transfers a call?
By ByTomorrow · Published
A caller has explained the issue once. If the next person starts from the beginning, the transfer has moved the call but lost the conversation. At the other extreme, a long intake can keep someone from the human they explicitly requested.
The right preparation is the minimum information needed for that handoff. The record and fictional examples below are a proposed operating pattern, not a report of a deployed ByTomorrow phone system.
What to look for
Where the decision can go wrong
The script treats every field as compulsory
A complete form is not always the goal. A caller asking for a person should not have to finish sales qualification before the agent attempts that connection.
The handoff hides uncertainty
A guessed name, an inferred urgency or an unconfirmed promise can become an apparent fact when a brief reaches the next person. Preserve what was actually said and what remains unknown.
Practical worksheet
Use this with your own business details
Minimum handoff record
Create fields for caller name if supplied; stated reason; destination or role; confirmed callback number if supplied; details already checked; unresolved question; any promise actually made. Mark missing fields unknown. Do not invent details to complete the record.
A short fictional example
Caller: Morgan. Request: change an existing estimate appointment. Destination: scheduling. Callback: caller confirmed the number already on the record. Appointment: not yet identified. Next action: scheduler checks which appointment Morgan means. No change has been promised.
The immediate-human exception
Fictional caller: "Please put me through to a person." Suggested reply: "I can try to connect you. Is there a particular person you need?" Attempt the permitted route without demanding project, budget or qualification answers.
Choose how context arrives
For a spoken brief, prioritize the reason and unresolved decision. For a written note, include the source call reference so staff can find context. Verify that the chosen transfer mode actually supports the intended delivery; do not assume the destination received a note.
Prepare the unanswered branch
Write the approved wording for an unavailable destination. Offer a callback request only if a named team member or queue will receive it. Keep transfer attempted separate from human connected and callback requested.
Put it to work
Work through the decision
Name the transfer conditions
Write the cases that require a person and the permitted destination for each.
Trim the required intake
For each condition, identify the details necessary to route it. Make every other field optional.
Test the receiving side
Use fictional details and have the recipient repeat the request and outstanding question. Correct missing or misleading context.
Test nobody answering
Make the destination unavailable during an authorized test. Check the caller hears the approved fallback and a real follow-up record exists if one was offered.
Record acceptance
Mark the handoff complete only when its defined outcome is observed. The attempted transfer and accepted callback are different outcomes.
Questions
Straight answers.
No. The next person needs enough context to act. A brief with the requested action and unresolved point is more useful than a transcript read aloud.
Leave the field unknown and follow the routing policy. Do not fabricate a name or block a general human request merely to complete the form.
No. Retell documents different human-transfer modes. Choose and test the mode that meets your handoff needs rather than treating a mode name as a quality guarantee.
Sources and further reading
- Retell call-transfer documentation
Retell documents cold and warm human transfers; destination availability and failed-transfer behavior need configuration.
Checked .
Make the next step specific
Use one real transfer problem to define the minimum record and the fallback your team can own.
Talk through your workflow