Chatbot Handoff Design

The Trigger Is the Easy Decision, the Rota Is the Expensive One

Quick answer: Almost every handoff guide, including our own escalation playbook, is about when the bot should give up. That decision is a morning's work. The decisions that determine whether the handoff succeeds all live on the receiving side, and they are arithmetic. A single nine-to-five weekday shift covers 40 of the week's 168 hours — 23.8 percent, so unless your customers only ever have problems on your schedule, a substantial share of every escalation you trigger arrives at an empty desk. And when the desk is not empty, small teams pay a queueing penalty that no amount of good intent removes: at the same 70 percent occupancy, one agent makes a customer wait 70 percent of the time and ten agents make them wait 22 percent of the time. Same effort per person, wildly different experience. This guide is about those two numbers and the four you should instrument.

Step 1. Count the hours you actually cover

Write down your staffed hours as a fraction of 168. One person, nine to five, Monday to Friday, one timezone: 40 hours, 23.8 percent of the week. Add a second shift running eight to eight on weekdays plus a four-hour Saturday morning and you have 64 hours, 38.1 percent — a 60 percent increase in payroll hours that still leaves the majority of the week uncovered.

That fraction is not your exposure, because escalations do not arrive uniformly. It is the denominator you need before you can find out what your exposure is, and most teams have never written it down. Write it down.

Step 2. Measure the share that arrives in hours, and refuse to guess it

Call the share of escalations arriving inside staffed hours p. Your offline share is 1 − p, and every honest decision below depends on it.

Nobody can tell you which row you are on, and vendors will not, because p is a property of your customers rather than of the software. Measure it: export the timestamps of conversations that hit your escalation trigger over four weeks, bucket them by local hour, and sum the buckets outside your rota. It is one spreadsheet pivot and it is the single most decision-relevant number in this guide.

Two things reliably push p down. Consumer businesses skew evenings and weekends. Any customer base outside your own timezone skews everything. If you sell to two continents on one rota, p can be below 0.5 before anything is wrong with your bot.

Step 3. Treat the offline path as a third of the product, not an edge case

At p = 0.7, three of every ten handoffs your bot triggers will be handled by whatever you wrote for the hours nobody is there. That is not an edge case; it is a major surface, and it is usually one unedited default sentence.

What it should contain, in order:

1. An honest statement of state. "Our team is offline right now" beats silence and beats a spinner. The customer has already been told a human is coming.
2. A window, not an adjective. "Someone will reply by 10am tomorrow, Monday to Friday" is checkable. "Shortly" is not, and it converts a wait into a grievance.
3. A capture step that survives the channel. Email or phone, because a website session will not exist tomorrow. On WhatsApp or Instagram the thread persists and the capture is less urgent, which is a real argument for handling out-of-hours volume on a messaging channel rather than on a web widget.
4. A route out for the genuinely urgent. One line naming what counts as an emergency and what to do about it. Most small businesses have exactly one such category, and it is usually a phone number.
5. A promise you keep. The window in point 2 is a service commitment. Missing it is worse than not making it.

Then check the promise against step 2's histogram: if a third of your offline volume arrives on Saturday afternoon, "by 10am Monday" is a 44-hour wait dressed up as reassurance.

Step 4. Size the desk, then check the queue — they are different questions

Load first. Escalations per week × average handling minutes ÷ 60 = agent-hours. A desk seeing 500 conversations a week with a 15 percent escalation rate produces 75 escalations; at 12 minutes each that is 900 minutes, 15 agent-hours, or 37.5 percent of one full-time week. Every capacity conversation ends here, and it is the wrong place to stop, because 15 hours of work does not arrive in a tidy 15-hour block.

Then the queue. The standard model for this is Erlang C, which asks: given an arrival rate and a handling time, how often does somebody have to wait? It assumes random independent arrivals, exponentially distributed handling times, no abandonment and infinite patience. Every one of those is false about real chat. Use it for shape, not for digits.

The shape is the point. Hold occupancy fixed at 70 percent and vary only the number of agents:

Every row works exactly as hard as every other row. The only difference is team size, and between the one-person and ten-person rows it changes the customer's experience by a factor of three — by a factor of seven between the one-person and twenty-person rows. Read it as six different-sized desks at identical occupancy rather than as six staffing options for one desk: adding agents without adding volume lowers occupancy, which is a second and larger effect on top of this one. This is why service-level advice imported from large contact centers does not survive contact with a two-person desk: a big team can run hot because somebody is usually free, and a small team cannot. If you have two agents, your options are to lower occupancy — that is, to carry visible slack — or to accept waits. There is no third option, and a promise of "under a minute" made by a two-person desk at 70 percent occupancy will be kept 45 percent of the time.

The lever that actually helps a small team is concurrency, because a chat agent holding several conversations at once behaves like several servers. Two agents at 70 percent occupancy, varying only how many chats each can hold:

Occupancy is held at 70 percent across these rows too, so each is a busier desk as well as a wider one; on a desk whose volume is fixed the improvement is substantially larger, which is why the ceiling below rather than the arithmetic is the binding constraint. Two agents at three chats each queue like a six-person voice desk. That is the mechanism behind chat's economics, and it has a hard limit that the arithmetic hides: concurrency lengthens handling time and degrades answer quality, so somewhere around three or four the model's assumption that slots are interchangeable stops being true. Treat the table as a reason to invest in agent tooling and conversation load balancing, not as license to set concurrency to eight.

Step 5. Deflection is a queueing lever, and it is nonlinear

The other way to cut waiting is to send fewer conversations to the queue. A two-slot desk, twelve-minute handling, varying only arrivals:

Halving arrivals from eight to four cuts waiting by two thirds, not by half. That convexity is the strongest financial argument for improving what the bot answers on its own, and it is why containment and deflection are worth measuring properly rather than as vanity numbers. It also cuts the other way, which is the part nobody mentions: a bot that quietly degrades — a stale knowledge base, a new product line it has never seen — moves you up this table, and the first symptom is not a bad answer, it is a queue.

Step 6. Instrument four numbers and nothing else

• Time to first human sentence, not time to assignment. Assignment is a database write. See first response time.
• Share of escalations arriving out of hours — the p from step 2, refreshed quarterly.
• Abandonment while waiting. Customers who left after the handoff fired and before a human spoke. This is the number that tells you whether your wait is actually costing anything, and almost nobody tracks it.
• Reassignment rate. How often a conversation gets passed on again after the first human takes it. Rising reassignment usually means your routing is guessing.

Four numbers, all cheap, and they answer different questions than the chatbot metrics most dashboards default to.

What our fifteen reviews mention about the receiving side

Very little, and the gap is worth knowing before you shop. Searching all fifteen files for the vocabulary of agent availability — business hours, working hours, operating hours, away messages, availability scheduling — matches four: Blip, whose flow template lists an operating-hours check and an attendant-availability check; Tidio, where "Operating hours" appears only in the alt text of a plan-comparison screenshot; SendPulse, whose flow canvas shows a day-of-week and run-time filter with an after-hours branch sending two confirmation bubbles; and Chatfuel, where the admin copilot was asked to configure an after-hours pattern, explained it, and then stated it could not complete the step.

None of the four is a test. No review in the corpus ran its handoff scenario outside staffed hours, so of the thirteen handoff figures we publish — median 4.0, tabulated in the warm transfer entry — every one that rests on a session somebody ran describes a transfer that arrived when somebody was there, and the rest carry no hour at all. Five of those thirteen describe no transfer anybody watched at all: the Intercom, AiSensy and Landbot reviews each disclose that six-scenario measurement is scheduled for 2026-06 and that their published figures derive from anchored structural evaluation, Blip's scenario section is headed PROJECTED, and Chatfuel's review states the full handover flow was not exercised. Strip those five and the remaining mean falls from 4.0 to 3.9. Two structural notes do carry over to a purchase decision: Botpress holds the corpus low of 3/5, in its case because routing and role-based access are Team-tier configuration rather than defaults, and Typebot has no native handover surface at all — our review measures a 14-minute Slack-webhook setup and rates the result 3.5/5, which is a figure about somebody else's software rather than about Typebot. If your handoff leaves the platform, everything in this guide has to be built in whatever it lands in.

FAQ

What is chatbot handoff design?

Designing the human side of an escalation: who receives it, whether they are there, how long the customer waits, and what happens when nobody is available. Trigger design — deciding when the bot should escalate — is the other half and is covered in our escalation playbook.

How many support agents do I need for a chatbot?

Start with load: escalations per week times average handling minutes divided by 60 gives agent-hours. Five hundred conversations at a 15 percent escalation rate and 12 minutes each is 15 agent-hours, under half a full-time week. Then check the queue, because that half-person is not enough to answer promptly at the moments the work actually arrives.

Why do small support teams have longer waits at the same workload?

Because waiting depends on how often every server is busy at once, and with few servers that happens far more often. At 70 percent occupancy a one-person desk makes somebody wait 70 percent of the time; a ten-person desk at the identical occupancy does it 22 percent of the time. Small teams buy service level with slack, not with effort.

What should a chatbot do when no agents are online?

Say so, give a checkable window rather than "shortly", capture a contact method that outlives the session, name the one thing that counts as urgent and where to take it, and then keep the promise. At a plausible 70 percent in-hours share this path handles about three in ten of your handoffs, so it deserves real editing.

How many chats can one agent handle at once?

The queueing arithmetic improves steeply up to about three and then runs into reality: concurrency stretches handling time and thins attention. Two agents at three chats each queue like a six-person voice desk, which is a good target; treating the table as license to set concurrency to eight is how average handling time quietly doubles.

Should I use business-hours routing or just let the bot handle everything?

Both, in sequence. Business-hours routing decides which of the two paths a conversation takes; the offline path in step 3 decides whether the second one is any good. Note that only four of our fifteen reviews mention availability scheduling at all — which is as much a gap in our coverage as in the products — so confirm it exists before designing around it.

Does a higher containment rate really reduce wait times?

More than proportionally. Cutting arrivals from eight an hour to four on a two-slot desk drops the chance of waiting from 71 percent to 23 percent — a two-thirds reduction from a halving of volume. The same convexity means a quietly degrading bot shows up as a queue before it shows up as a bad answer.

Related guides

• Chatbot escalation playbook — the trigger half of this decision.
• Warm transfer — the companion entry, and what our corpus can and cannot say about transfer quality.
• Chatbot handoff rules — the six trigger families in detail.
• Round robin lead assignment — the same receiving-side problem for sales leads rather than support.
• Human handoff — the definition and the technical mechanics.
• Chatbot metrics guide — where the four numbers in step 6 sit among everything else you could measure.
• Improve chatbot resolution rate — the other end of the deflection lever in step 5.
• Response time SLA calculator — the Erlang C tables in step 4 as an interactive tool: enter your peak hour and get the service level, the human wait, and the smallest team that meets the target.

Sources

• The queueing model is Erlang C, computed for this page rather than quoted. Erlang B was evaluated with the standard recurrence inv(0)=1, inv(i)=1+inv(i-1)·i/a, B=1/inv(N), and Erlang C as C = B ÷ (1 − ρ(1 − B)) with ρ = a/N; the service-level column is 1 − C·exp(−(N−a)·t/AHT) at t = 60s and AHT = 12 min. The implementation was validated against the two closed forms it must reproduce: for N=1 it returns C = ρ exactly (0.700 at ρ = 0.70, the M/M/1 result), and Erlang B(2, a=1) returns 0.200, matching (a²/2!)/(1+a+a²/2!). Stated assumptions, all of which real chat violates: Poisson arrivals, exponentially distributed handling times, no abandonment, infinite customer patience, and interchangeable servers — the last of which is why the concurrency table is presented as a mechanism with a ceiling rather than as a dial. The figures are a shape, not a forecast for your desk.
• Coverage arithmetic. 40 ÷ 168 = 0.2381 and 64 ÷ 168 = 0.3810, on a 168-hour week. The offline-share table is 1 − p applied to a 75-escalation week and rounded to whole conversations, halves rounded up. The 75 comes from 500 × 0.15; the 15 agent-hours from 75 × 12 ÷ 60; the 37.5 percent from 15 ÷ 40. All are worked examples with round inputs, not measurements of anybody's desk.
• Chatbotscape review corpus, searched 31 August 2026. Denominator: ls sample-reviews/*-review.md | wc -l returns 15. The availability search was grep -cEie 'business hours|office hours|working hours|operating hours|away message|agent availability|availability schedul' sample-reviews/*-review.md, executed verbatim from the repository root, returning non-zero for exactly four files: blip-review.md (1), chatfuel-review.md (2), sendpulse-review.md (1), tidio-review.md (1). Each of the four observations is quoted from the review that recorded it, and each sits in a screenshot caption, screenshot alt text, a plan-comparison line or the editorial prose reading a screenshot — never in a scenario result — which is the basis for the claim that none is a test.
• The claim that no review tested an out-of-hours handoff is an argument from absence: no file in the corpus states the time of day at which its handoff scenario ran, and no file reports a transfer arriving into an unstaffed inbox. It is stated that way in the body rather than as a positive finding.
• Platform structure notes, quoted from the reviews that recorded them: botpress-review.md (3/5, "routing rules require manual Team-tier setup (routing + RBAC are Team-tier features)"); typebot-review.md ("Typebot does not ship native human-handover surface"; handover routed to "Zendesk, Intercom, Slack, or custom HTTP webhooks"; 14-minute Slack-webhook setup on Pro tier, tabulated in that review's test summary as "14 min setup; 3.5/5 friction"). The thirteen handoff figures, their median, the evidence-class split (five anchored, eight from a claimed session), the five different names our reviews give that one score, and the four near-identical source sentences behind four of them are tabulated and criticized in the companion entry at /glossary/warm-transfer rather than restated here.
• Ahrefs Keywords Explorer, US overview and volume-by-country, queried 31 August 2026 — the demand, difficulty, CPC, global-volume and parent-topic figures in this page's keyword note, including the checks behind declining 'service level agreement', 'queue management' and 'erlang c'.
• Chatbotscape evaluation methodology. /methodology (continuously updated).

About this guide

Chatbotscape launched in 2026 as an independent review site for chatbot platforms. This guide is part of our SMB chatbot Academy and is written for the owner or support lead of a small business that already has a bot and needs to design what happens after it escalates. It names no best platform for handoff, because the decisions it covers are almost entirely yours rather than the vendor's: the rota, the promise, the concurrency ceiling and the offline copy are not features on any pricing page.

Methodology

The queueing figures were computed and validated in this session against two closed forms before publication, and the model's assumptions are printed next to the tables rather than in a trailing caveat, because a queueing number without its assumptions is a sales tool. Every corpus search printed here was executed in the form the page states. Every platform claim is attributed to the review that recorded it, and where a review recorded an observation in a screenshot caption rather than in a scenario result, the page says so.

The editorial judgments on this page, listed rather than flagged line by line:

1. Treating the rota, not the trigger, as the expensive decision. That inversion is the argument and the reason this page exists alongside our own escalation playbook.
2. Publishing the small-team queueing penalty as the central table. It is unwelcome news for the audience we write for, and softening it would make the page useless to exactly the readers who most need it.
3. Presenting concurrency as a mechanism with a ceiling rather than as a dial, on the ground that the model stops being true before the table stops improving.
4. Calling the offline path a third of the product. That rests on a plausible p of 0.7 that we tell readers to measure rather than assume, and it is labeled a worked example throughout.
5. Publishing the corpus gap — four availability mentions, none of them a test — instead of a shortlist. A reader who wanted a ranked list of platforms by handoff quality will be disappointed; inventing one from four screenshot captions would be worse.
6. Bounding the guide at the receiving side and handing triggers, rotation and transfer quality to three other pages. That boundary was declared before drafting rather than at rater stage, and it is the mechanism that cut the overrun from 25.6 percent at its previous best, and far worse before that, to 12.8 percent.

We have run no hands-on staffing deployment, and no figure on this page is a measurement of a real desk. See our methodology for how platform facts are verified.

Last updated

1 September 2026.