Chatbot-to-human handoff: context, ownership and a worked example

A useful chatbot-to-human handoff moves the conversation to a person without restarting it. The person who takes over can see what the customer asked, what the chatbot already answered and tried, and the evidence available. One named owner is responsible for the next reply, and the customer is told honestly when they will hear back. If the customer has to repeat the story, or nobody owns the reply, the handoff has failed, even if the transfer technically worked.

FullSession Support & Sales Desk is built around that standard. Max AI answers the question, and customers always know when they are talking to Max and can ask for a person at any time. Your team takes over in the same thread, with Max's answers already there, from one shared inbox that holds the conversation and available context. You can assign the conversation, set office hours with an away message, and let customers leave a question after hours. Add Core CX / UX and the handoff also carries the recorded session when one was captured. Human chat is free, and there are no seat fees. See the Desk's published capabilities.

Below: the triggers, the context to transfer, ownership, waits, and an annotated before-and-after conversation for a fictional SaaS company. A downloadable handoff checklist includes an availability test record. Desk capabilities and prices come from FullSession's published pages, checked 19 October 2026. The example conversation is illustrative, not a product recording or a customer result.

What a complete chatbot-to-human handoff includes

A handoff is an ownership change. Before it, the chatbot owns the next reply. After it, a person does, and the customer should be able to tell which is which. Five pieces of information make that change useful, and they are also the five fields of the checklist.

Scroll horizontally to see all columns on smaller screens.

The five parts of a useful chatbot-to-human handoff

Part	What the receiving person needs	What goes wrong without it
1. The question	The request in the customer's own words, and what they are trying to get done.	The teammate answers a different question, or asks the customer to start again.
2. Attempted steps	What the chatbot answered and from which source, what the customer already tried, and whether any attempted change was completed, failed or is unknown.	The teammate repeats troubleshooting the customer already did, or retries a change that may have succeeded.
3. Available evidence	The transcript, the account context your connection permits, the page, and a session recording where one was captured.	The teammate reconstructs the problem from a one-line description.
4. Next owner	One named person or team responsible for the next reply.	Everyone assumes someone else has it, and the conversation waits.
5. Promised next update	When and where the customer will hear back, in terms the team can meet.	The customer opens a new chat or emails another address, and the team now has duplicates.

The conversation itself is the container. When the person replies in the same thread, the first three parts are already on screen above the reply. Assignment supplies the fourth, and the teammate's first message should state the fifth.

When the conversation should move to a person

Write handoff triggers as rules you can test, not as a general instruction to escalate when needed. These six triggers cover the common cases. The first one should never depend on the others.

Scroll horizontally to see all columns on smaller screens.

Handoff triggers to define and test

Trigger	Example in a SaaS support queue	What should happen
The customer asks for a person	“Can I talk to someone?” at any point in the conversation.	Hand over at once. Do not make the customer rephrase the request or argue with the chatbot.
Unsupported or unpermitted action	A change the chatbot cannot make, or one the customer's role does not allow.	Explain the limit once, then hand over with the requested change written down.
Account or billing exception	A refund outside policy, a disputed charge or a plan exception.	Route to someone who can approve it. The chatbot should not improvise policy.
Low confidence or repeated failure	No approved source covers the question, or the problem persists after two attempts.	Stop guessing. Hand over with the open question and what was already tried.
Policy-sensitive topic	Security, data deletion, legal or contract questions.	Hand over by rule wherever your policy requires a person, even if documentation exists.
Frustration	“This is the third time I've asked,” or the same message sent repeatedly.	Acknowledge it and offer a person rather than another answer.

In Desk, the first trigger is part of the product: customers can ask for a person at any time, and on your website you can let visitors choose Max or a person. Write the other five as team policy, confirm in your walkthrough how each one is set up for Max, then test each with a real question from your own queue.

A handoff is the correct result when a person is needed. A lower handoff rate is an improvement only if the conversations that stay with the chatbot end with the problem solved.

What context should travel with the handoff

The receiving person needs enough to act without interviewing the customer again. Transfer these items:

• The full transcript. The teammate should read the conversation, not a ticket subject line. In Desk, replies from Max are labeled in the transcript, so no one mistakes them for a colleague's.
• What the chatbot answered, and from which source. The teammate can then check whether a help article was wrong, out of date or misapplied.
• The steps already attempted, with their state. “Clicked Save twice, value reverted” is useful. “The change may have saved” and “the change failed” lead to different next steps.
• The customer and account context you permit. Plan, role or workspace details, limited to what your connection is allowed to expose. With Max, your MCP server supplies the data you choose to expose.
• The page and the session, when captured. Where the customer was and what they did. With Core CX / UX, the teammate sees what Max said, the page and the recording of a captured session before replying.
• The open question. The one thing still unresolved, in a sentence.

A recording answers a question the customer often cannot. “Save does nothing” could be a validation error, a permission rule, a network failure or a defect. A recording shows the click and the page's response, helping the teammate narrow the cause and choose the next check before asking the customer to repeat the steps. In FullSession, recording comes with Core CX / UX, a separate plan from $39.20/mo billed annually. Recordings depend on your Core plan, capture settings and retention, so a handoff includes one only when that customer's session was captured. If your chatbot and replay tool are separate products, check how they connect and which plans that needs: Fullstory, for example, documents a Fin integration that returns its AI session summary to Fin and is part of its Anywhere: Activation product. See how FullSession session replay works.

Keep the transfer inside your data rules. In Desk, what customers type in the chat follows the same masking rules as every other input FullSession records, and replay masking happens at capture, in the browser.

A worked FullSession Desk handoff, before and after

The example uses a fictional SaaS company, Acme Reports, and a fictional customer, Priya, who is a workspace admin. Priya changes her workspace's default time zone and clicks Save. The page appears to accept the change, then the old value returns. Acme's help center has an approved article on workspace settings. Both versions start with the same message. The transcripts are illustrative designs, not recordings from FullSession or results from a customer deployment.

Scroll horizontally to see all columns on smaller screens.

Before: a cold transfer that loses context and ownership (illustrative, fictional company)

Turn	Message	What went wrong
1. Priya	“The workspace time zone won't save. I've tried twice.”	Nothing yet. The question is clear.
2. Chatbot	“Here are some articles about workspace settings.”	A list of links instead of an answer, and no record that Priya already tried twice.
3. Priya	“I need a person.”	The customer has to ask, and the chat is about to end.
4. Chatbot	“I've created a ticket. An agent will contact you soon.”	The conversation ends. “Soon” is a promise nobody owns.
5. Agent, by email the next day	“Hi, can you tell me what's happening and which workspace you're in?”	The context stayed in the chat. Priya starts again on another channel.
6. Priya, in a new chat	“Still broken. Is anyone looking at this?”	A duplicate conversation, and still no named owner or update time.

Scroll horizontally to see all columns on smaller screens.

After: a same-thread handoff in FullSession Desk (illustrative, fictional company)

Turn	Message or action	Annotation
1. Priya	“The workspace time zone won't save. I've tried twice.”	The question, in the customer's words, opens the thread.
2. Max	“The workspace time zone is in Settings, under Workspace. Only workspace admins can change it, and the new zone applies to reports scheduled after the change.”	An answer from Acme's approved help article. The reply is labeled as Max in the transcript.
3. Priya	“I'm the admin and it still reverts. Can I talk to a person?”	Trigger: the customer asks for a person. No third attempt at an answer.
4. Shared inbox	The conversation is open in Acme's shared inbox. Sam on the support team assigns it to himself.	One named owner. Desk lets you assign conversations and control who can view them.
5. Sam reviews	Sam reads the transcript. Acme uses Core CX / UX and Priya's session was captured, so he opens the recording: two Save clicks, the field returns to the old value, no error message.	Evidence Priya could not describe. Without a captured session, Sam works from the transcript and asks one targeted question.
6. Internal note	“@Lee: admin cannot save workspace time zone. Value reverts after Save, no error shown. Session linked. Priya told to expect an update by 3:00 pm Central.”	Internal notes and @mentions stay internal; Priya never sees them. The engineer gets the same evidence.
7. Sam	“Hi Priya, I'm Sam from support. I can see both Save attempts, so you don't need to repeat anything. Engineering is checking the setting now, and I'll update you here by 3:00 pm Central today.”	The promised next update: a time the team can meet, in the same thread. The reply reaches Priya live.
8. Priya returns later	Priya comes back later and finds Sam's update in the same conversation: the cause is fixed, and he asks her to try Save once more.	Priya picks up the same thread when she returns. No second ticket and no repeated story.

The teammate is equally capable in both versions. What changed is what the handoff carried: the question, the attempted steps, the evidence, the owner and the next update. The 3:00 pm promise is Acme's commitment, not a product timer: Desk keeps the conversation, labeled answers and assignment together, and the team staffs for the reply time it states.

The same flow, step by step, including the path when nobody is available:

1. Max answers from approved knowledge, and every Max reply is labeled.
2. A trigger fires: the customer asks for a person, or your policy requires one.
3. Your team takes over in the same thread, from the shared inbox.
4. A teammate is assigned and reviews the conversation, available context and, with Core CX / UX, the recording when a session was captured.
5. The teammate replies with the next update and keeps the conversation until it is resolved.
6. Outside office hours, the away message says when the team is back, the customer can still leave a question, and the team replies in the same thread, where the returning customer picks it up.

What happens when a teammate is unavailable

An honest wait is better than a fast promise nobody keeps. In Desk, you set hours in your team's time zone with an away message, customers can still leave a question after hours, and a returning customer picks up the same thread. That gives you the parts of a good after-hours handoff. The wording and the staffing are yours.

Write the away message as a promise you can keep. Say when the team is back, invite the customer to leave the question in the conversation, and say where the reply will appear. For example: “Our support team is offline until 9:00 am Central on Monday. Leave your question here and we'll reply in this conversation when we're back.” Avoid “someone will be with you shortly” unless someone is watching the inbox. If your message mentions another channel, such as email, confirm in your own setup that replies actually reach the customer there before you promise it.

During office hours, when everyone is busy, the same rule applies: assign quickly, and make the first human reply state the next update time rather than a minute estimate. Keep the customer in the same thread instead of sending them to a form. Start each business day with the questions left overnight, assigning each one and replying with an update time.

Test this before customers find the gaps. The handoff checklist includes an availability test record with blank fields for what you observe:

Scroll horizontally to see all columns on smaller screens.

Availability test: what to do and what to expect from the documented Desk behavior

Step	What to do	What to expect
1. Configure	Set office hours in your team's time zone and write the away message.	Hours and message saved as written.
2. Ask after hours	Outside those hours, open the chat as a visitor (or as a test customer in your app) and ask for a person.	The away message appears. Nothing promises an instant reply.
3. Leave a question	Leave a specific question in the conversation.	The question is accepted and reaches the shared inbox.
4. Reply next business day	A teammate assigns the conversation and replies in the same thread with a next update.	Assignment is visible and the reply is in the original thread.
5. Return as the customer	Come back as the same visitor (or as the same test customer in your app).	The same thread, with the reply, and nothing to restate.
6. Recording, if used	With Core CX / UX, check whether the customer's session was captured and whether the teammate could open it.	A recording only when the session was captured under your plan, capture settings and retention.

Expected results describe documented behavior. Record what you actually observe, with the date and device. If a step differs, fix the setup or change the promise before launch.

What a handoff costs with Max AI

With Max, a handoff never adds a charge of its own. A handoff before substantive Max help is not billed. Once Max has delivered substantive help, the one $0.39 conversation charge stands, and human replies add no charges. The Desk app, shared inbox and human chat are included, with no seat fees. There is no additional Desk seat fee for the teammate who takes over. One conversation covers one user in one thread for a fixed 24 hours from Max's first substantive answer, guidance or supported action, and the $99 monthly minimum is credited toward conversations, not added. See current Max pricing. For a full budget across vendors, use the AI chatbot pricing guide.

Scroll horizontally to see all columns on smaller screens.

Illustrative monthly charges: 1,000 Max AI-assisted conversations and 1,000 Fin service outcomes, USD before tax

Path	Calculation	Illustrative charge
Max AI with included Desk	1,000 × $0.39; above the $99 minimum	$390, with human chat and no seat fees
Fin on an existing helpdesk	1,000 × $0.99; above its 50-outcome monthly minimum, no additional Fin seats	$990, plus the retained helpdesk subscription
Intercom Essential + Fin, 10 full seats	1,000 × $0.99 + 10 × $29	$1,280 monthly equivalent; annual seat commitment

The vendors count different things. Max bills AI-assisted conversations. Fin bills outcomes at most once per conversation, such as a resolution or a Procedure handoff, where Fin completes a Procedure you configured to end in a handoff; Fin does not bill escalations when a customer asks for a human or shows frustration. Equal counts are illustrative and do not establish identical workloads or guaranteed savings. The example excludes taxes, optional Core recording, Fin sales qualifications and other add-ons. Sources checked 19 October 2026: Fin pricing, Fin outcome definitions and Intercom plan terms.

How to test and measure the handoff

Before launch, take one real question that ended in a transfer last month and run it through the before-and-after checks above. Then run each trigger once, and run the availability test. If you keep Zendesk, HubSpot, Freshdesk or another supported helpdesk, Max also works inside it, so run the same tests in the inbox your team actually uses. After launch, review handoffs weekly with these measures:

Scroll horizontally to see all columns on smaller screens.

Handoff measures and how to read them

Measure	How to count it	Read it with
Handoff rate by reason	Conversations handed to a person, divided by conversations the chatbot handled, split by trigger.	Resolution after handoff. A falling rate helps only if the remaining conversations are resolved.
Time to first human reply	From the request for a person to the first teammate message, reported separately for office hours and after hours.	The next update time your team promised.
Context-sufficient handoffs	The receiving teammate answers: did I have to ask for anything already in the thread? Count the “no” answers.	A weekly sample of the “yes” cases, with the missing item named.
Reopen or repeat contact	The same customer returns about the same issue within seven days, in the thread or a new conversation.	Ownership and update notes. Repeats often trace to a missing owner.
Resolution after handoff	Handed-over conversations closed with the problem confirmed solved, not just closed.	Reopen rate, so a quick close does not hide an unsolved problem.
After-hours questions answered next business day	Questions left outside office hours that received an owned reply by the end of the next business day.	The promise in your away message.

Set targets from your own baseline; another company's rates do not predict yours. When a measure moves, read the transcripts behind it before changing a trigger.

Chatbot handoff questions support teams ask

What should a chatbot transfer when a person takes over?

The conversation itself, plus five items: the question in the customer's words, what the chatbot answered and tried, the available evidence, the next owner and the promised next update. In FullSession Desk, the teammate takes over in the same thread, so the transcript and Max's labeled answers are already there.

What should happen when no teammate is available?

Say so plainly, say when the team is back, and let the customer leave the question in the same conversation. In FullSession Desk, you set office hours in your team's time zone with an away message, customers can still leave a question after hours, and a returning customer picks up the same thread. Never promise an instant reply.

How can a session recording help explain the support question?

It shows what the customer did and how the page responded, such as a Save click that changed nothing, so the teammate can diagnose before asking more questions and share the session with engineering. In FullSession, recording comes with the separate Core CX / UX plan, and a handoff includes one only when that customer's session was captured.

See a support handoff in a Desk walkthrough

Bring one support question your team hands over today, plus the after-hours case you worry about. We will walk through Max's answer, the takeover in the same thread, assignment and office hours, and, if you use Core CX / UX, the recorded session behind the question.

See a support handoff in a Desk walkthrough.