Containment Rate Calculator
Containment rate is one of the most quoted chatbot metrics and one of the least consistently defined. The number on your dashboard usually means «the session ended without a handoff», which counts everyone who gave up, everyone the bot could not understand, and everyone who emailed you the next morning instead. This calculator takes one period of session counts and reports containment under four definitions at once, so you can see how much of your headline figure is resolution and how much is exit.
Work out what your containment rate really is
Enter one period of session counts. The calculator reports the same data under the four definitions teams use, so you can see how much of your dashboard number is resolution and how much is people giving up. Everything runs in your browser, and nothing you type is uploaded or stored.
Sessions in the period
Every session your platform opened, before any filtering.
Widget opens, misfires, bounced page loads. Nobody asked anything, so there was nothing to contain.
How sessions ended
Handed to an agent, whether the customer asked or a rule fired.
The customer stopped replying before an answer was delivered. Your dashboard almost certainly files these as contained.
The last thing the bot said was some version of «I did not understand».
Self-served sessions are the residual: whatever is left after these categories come out of the total. Count each session once, in the outcome it ended with.
Did the resolution hold?
Same customer, same issue, back through any channel inside the window. Enter 0 if you cannot measure this yet.
24 to 72 hours is the usual range. Longer windows catch more, and are harder to attribute.
Value and target
Fully loaded, including overhead and occupancy. The default matches the bot vs human calculator's example: an $18 wage at a 1.35 multiplier, 75% occupancy, 8-minute handle time. Set 0 to hide the value readout.
Measured on the defensible definition, not the dashboard one.
Reported containment
77.5%
Defensible containment
42.6%
Gap
+34.9 pp
The same period under four definitions
| Definition | Sessions | Rate |
|---|---|---|
| Vendor defaultEvery session that ended without a handoff, over every session started. | 3,100 / 4,000 | 77.5% |
| Answer deliveredAbandoned and fallback-ended sessions removed from the numerator. The bot said something useful. | 1,700 / 4,000 | 42.5% |
| Resolution verifiedAlso removes sessions where the customer came back inside 48h. | 1,450 / 4,000 | 36.3% |
| Defensible containmentVerified resolutions over sessions where the customer actually asked something. | 1,450 / 3,400 | 42.6% |
Each row narrows the numerator except the last, which also cleans up the denominator by dropping sessions where nobody asked anything. That is why the strictest definition can read higher than the row above it.
Where your 4,000 sessions ended
- Resolved, no repeat 1,450
- Resolved, came back 250
- Escalated 900
- Abandoned 480
- Fallback dead-end 320
- No user message 600
| Escalation rate | 22.5% |
| Abandonment rate | 12.0% |
| Fallback dead-end rate | 8.0% |
| Repeat contact rate (of self-served) | 14.7% |
| Sessions where someone asked something | 3,400 |
One point of defensible containment is worth $147 a period in human handling you do not pay for, at $4.32 per conversation. That is a gross figure: it ignores what the bot itself costs, which is the job of the bot vs human cost calculator.
The +34.9 pp gap between your dashboard and the defensible number is $5,119 of saving counted but not banked each period. It shows up later as agent workload nobody forecast.
Reaching 65% needs 760 more genuinely resolved sessions in a period of this size. The cheapest source is usually the fallback dead-ends (320 sessions): those customers asked something the bot could not parse, which is a coverage problem you can fix from the transcript.
Embed this calculator on your site (free)
<iframe
src="https://chatbotscape.com/embed/tools/containment-rate-calculator/"
width="100%" height="1200" frameborder="0"
title="Containment Rate Calculator by Chatbotscape"
loading="lazy">
</iframe>What containment rate measures, and what it does not
Containment rate is the share of conversations a bot handles end to end, with no human involved. That definition is easy to say and hard to operationalise, because «handled» is doing a lot of work in the sentence. A session that ended with the customer thanking the bot is contained. A session that ended because the customer closed the tab in frustration also ended without a handoff, and most analytics packages cannot tell the two apart. Neither can the executive reading the slide.
The metric is also frequently confused with deflection rate, which counts contacts kept away from an agent queue regardless of what happened to the customer afterwards. Our deflection versus containment entry walks through where the two diverge. In short: deflection is a queue metric, containment is meant to be an outcome metric, and the moment you measure containment by absence of a handoff you have quietly turned it back into a queue metric.
The four definitions this calculator reports
Feed one set of counts in and you get four rates out. They are not competing estimates of the same quantity. Each one answers a different question, and the spread between them is the finding.
1. Vendor default
Every session that ended without a handoff, over every session started. This is what most dashboards display, and it is the number that appears in vendor case studies. It is not dishonest so much as cheap to compute: a handoff event is easy to log, an outcome is not.
2. Answer delivered
Same denominator, but abandoned sessions and fallback dead-ends come out of the numerator. A session where the last bot turn was «Sorry, I did not understand that» is not containment by any reasonable reading, yet it is indistinguishable from success in definition one. Watch your fallback rate and abandonment rate for the size of this correction.
3. Resolution verified
Also removes sessions where the customer came back inside a follow-up window. This is the adjustment almost nobody makes and the one that changes decisions, because a bot optimised for containment without a repeat-contact check will happily close conversations that generate a second contact tomorrow. The cost does not disappear. It moves to a different report.
4. Defensible containment
Verified resolutions over sessions where the customer actually said something. This is the headline the calculator highlights, and it is the only one of the four that moves in both directions: stripping zero-input sessions out of the denominator is a fair adjustment that usually raises the rate. If a third of your «sessions» are widget opens on a pricing page, including them punishes the bot for traffic it never had a chance to serve.
A worked example
The figures the calculator loads by default are a deliberately ordinary month: 4,000 sessions, 600 of them widget opens where nobody typed anything, 900 escalated, 480 abandoned mid-flow, 320 ending on a fallback message, and 250 customers who came back inside 48 hours after a session the bot appeared to close. That leaves 1,700 self-served sessions and 1,450 that survived the repeat-contact check.
| Definition | Sessions | Rate |
|---|---|---|
| Vendor default | 3,100 / 4,000 | 77.5% |
| Answer delivered | 1,700 / 4,000 | 42.5% |
| Resolution verified | 1,450 / 4,000 | 36.3% |
| Defensible containment | 1,450 / 3,400 | 42.6% |
Nothing exotic happened in that month, and the headline still moved 34.9 points depending on who was asked. Notice the last row rising above the row above it: the same cleanup that removes 600 sessions nobody ever used from the denominator is worth about six points, which is why we treat denominator hygiene as an adjustment in its own right rather than folding it into the numerator argument.
Why the gap is usually large
Three mechanisms stack, and they all push the same way. First, abandonment is invisible to handoff-based counting, so every customer who gives up is scored as a success. Second, fallback dead-ends are also invisible, and they concentrate in exactly the intents you have not built yet. Third, repeat contact is measured in a different system, usually a helpdesk, so nobody joins the two datasets and the follow-up ticket is attributed to «email volume» rather than to a bot session that failed twelve hours earlier.
None of this requires anyone to be acting in bad faith. It requires only that the easiest number to compute is also the flattering one. That is the normal condition of operational metrics, and the reason this calculator prints all four rates side by side rather than picking one for you.
We built it after running into the same problem repeatedly in our platform reviews. Support-desk products gate the number behind a confirmed resolution, flow builders leave you to assemble it from end nodes and handoff tags, and developer-grade tools let you mark resolution events yourself. Three architectures, three definitions, one word. Comparing the resulting percentages without restating them is the mistake this page exists to prevent, and our containment rate entry documents how each platform class exposes the metric.
How to collect the inputs
The counts are easier to assemble than the definitions suggest. Total sessions and escalations come from the platform. Abandoned sessions are sessions where the customer stopped replying before an answer was delivered, which most tools expose as a timeout or an inactivity close. Fallback dead-ends are sessions whose last bot message matched your fallback templates, a query you can run against transcripts once and reuse. Zero-input sessions are those with no inbound user message.
Repeat contacts are the hard one, and worth the effort. Join your bot sessions to helpdesk tickets and inbound calls on customer identifier, then count the sessions your bot appeared to resolve that were followed by a contact from the same customer inside 24 to 72 hours. If you cannot run that join yet, enter zero and read the defensible rate as a ceiling rather than a measurement. The calculator flags this for you so the caveat travels with the number.
What to do with a large gap
Fix the measurement first, then the bot. A team that reports the defensible number and a team that reports the vendor default will make different decisions about the same bot, and only one of them will be surprised by next quarter's agent workload. Once the definition is settled, the outcome mix tells you where to work: fallback dead-ends are a coverage problem you can fix from transcripts, abandonment is usually a flow problem, and escalations that arrive after six turns of failure are a handoff timing problem. Our guide to improving resolution rate covers the intervention order in detail.
Resist the temptation to raise containment by making the handoff harder to reach. It works, it shows up immediately in the vendor default number, and it will show up three weeks later in CSAT and repeat contacts. The CSAT calculator is the counterweight to read alongside this one.
Containment for voice and IVR
The same arithmetic applies to IVR and voice bots, with two differences. Abandonment is more visible in voice, because a hangup is a discrete event rather than an inferred timeout, so the abandoned count tends to be more trustworthy. Zero-input sessions are rarer, since almost nobody dials by accident. Voice containment measured on the vendor default is therefore usually closer to the defensible figure than chat containment is, though repeat calls remain uncounted for exactly the same reason as repeat tickets.
What this calculator deliberately is not
It does not print an industry benchmark next to your result. Published containment figures are collected under whichever definition the publisher used, typically the loosest, so dropping one beside a defensible rate would mislead in the direction that makes you look bad. Our editorial bands by bot architecture live in the containment rate glossary entry with the definition they assume spelled out. Use them as orientation. Use your own prior periods, measured the same way, as the target.
It also does not price your bot. The value readout here is gross avoided human handling, not net savings: it says nothing about the platform fee, per-conversation AI cost, or the extra agent minutes an escalated conversation consumes. For the full unit economics, take the defensible rate from this page and put it into the bot vs human cost calculator, which charges escalations to both sides of the ledger and solves for the containment rate where the setup breaks even. For the multi-year investment case, use the ROI calculator.
Related Chatbotscape tools and resources
- Bot vs human cost calculator — what your containment rate is worth once the bot's own cost is charged
- Chatbot CSAT calculator — the quality check that catches containment bought with frustration
- Chatbot metrics guide — containment, escalation, and satisfaction as one dashboard
- The chatbot KPIs a board actually cares about — how to present this number upwards
- How to improve chatbot resolution rate — the intervention order once you know where sessions die
- Escalation rate — containment's mirror image
- Resolution rate — the outcome metric containment approximates
- Intercom review — a platform that prices by resolution, so its containment definition is worth reading closely
- SendPulse review — multi-channel reporting on a budget tier
FAQ
How do you calculate containment rate?
The general formula is contained sessions divided by total sessions. Everything hangs on what counts as contained. The loose version is sessions that ended without a handoff, which this calculator labels vendor default. The strict version is sessions where the bot delivered an answer, no human was involved, and the customer did not come back inside the follow-up window, divided by sessions where the customer actually asked something. Both are legitimate; only one of them should drive decisions.
What is a good containment rate?
It depends on the architecture, and more than that, on the definition behind the number you are comparing against. Vendor case studies rarely state which one they used, and it is typically the loosest, so a like-for-like comparison is usually not available. Our containment rate entry publishes editorial working bands by bot architecture, from 12-18% for a rule-based FAQ bot up to 45-58% for a resolution-gated premium agent, and those bands assume the honest definition with abandonment excluded. Read them next to the defensible rate this page produces, not next to your dashboard figure. The most useful target of all is your own defensible rate from last quarter, measured the same way.
Should abandoned sessions count as contained?
No. A customer who stops replying mid-flow was not served, they left. Counting abandonment as containment is the single largest source of inflation in the vendor default number, and it grows precisely when the bot gets worse, because a frustrating bot produces more abandonment and therefore a higher apparent containment rate. Any metric that improves as the product degrades needs correcting.
Why does the strictest definition sometimes show the highest rate?
Because it is the only one that also cleans the denominator. Removing sessions where nobody sent a message stops the bot being charged for traffic it never had a chance to serve. When your zero-input share is large, that correction outweighs the stricter numerator. The calculator shows both effects separately so you can see which one is moving the number.
What follow-up window should I use for repeat contacts?
Between 24 and 72 hours covers most genuine re-contacts without sweeping in unrelated new issues. Shorter windows undercount, longer ones get harder to attribute honestly. Whichever you pick, keep it fixed across periods, and state it whenever you quote the rate. The calculator prints the window inside the definition label for exactly that reason.
Does the calculator send my data anywhere?
No. All math runs in your browser. Nothing you type is uploaded, stored, or logged, and refreshing the page clears it.
Can I embed this calculator on my site?
Yes, free. Copy the iframe snippet from the embed section above. The embed strips Chatbotscape navigation and keeps the calculator plus attribution.