The customer chooses when to request a person.
The caller selects Talk to a human, confirms their name and chooses Connect me. The AI conversation is finalised and its transcript saved before the handoff prepares the private briefing.
The receiving team hears what the caller needs.
The generated briefing contains the caller’s confirmed name, the product tied to that conversation and a short factual issue summary. It plays privately to the receiving team before the caller is connected.
The product measures the complete briefing and limits it to 14 seconds. If a usable briefing cannot be prepared, it does not dial the team.
You control which number receives the call.
Phone destinations come from server-side workspace settings. Support and sales can have different numbers, and a caller cannot supply an arbitrary destination. The browser shows the progress of the handoff while the caller waits.
Check the complete handoff during your pilot.
This flow is implemented, but a real browser-to-human handoff still needs end-to-end human verification. A human browser microphone conversation and interruption handling also remain unverified. The confirmed outbound AI phone test on 21 September 2026 exercised a separate flow.
Before enabling handoff for customers, test the receiving number, the private briefing and the caller connection together. Business-hours routing and a callback queue remain outside the current pilot.
Common questions
Does a handoff status prove someone answered?
A handoff being initiated does not prove a person answered or a caller was connected. The pilot distinguishes these events, and the full receiving-team experience needs to be checked during setup.
Does the application record the human call?
The application does not store audio recordings of calls. The private briefing is generated speech, with an expiring private retrieval link. It is separate from the saved text transcript of the AI conversation.