Chatbot Containment Rate

A support bot may answer common questions before offering a human agent, and if a customer leaves without an agent transfer the conversation may count as contained under the chosen rule, which still needs quality review. Zendesk distinguishes containment from true resolution, because a conversation can end when the customer abandons it, not because the issue was fixed, so a responsible dashboard tracks both automation coverage and customer outcomes.

A fictional company records 5,000 bot-started conversations and 3,500 without a human handoff, giving a simple containment rate of 70%, which alone cannot tell how many customers got the right answer. Define what begins a bot conversation, since a greeting with no customer question may be excluded while a substantive support request is included, and different vendor definitions can produce different rates.

Define what counts as handoff too, as a bot-created ticket, callback request or later live chat may count as escalation even if no agent joined immediately, so include a reasonable follow-up window. Calculate the metric over a defined period and channel, because email bots, website chat and messaging apps may have different user needs and a blended rate can hide one failing route.

A user who closes the page after an unhelpful response should not be assumed satisfied, so audit abandoned sessions and repeated contacts, otherwise a bot can raise its apparent containment simply by making transfer difficult. The bot should clearly show a way to request a person when appropriate, since hiding the option can inflate containment but raise customer effort, and escalation is a good outcome when the bot cannot safely help.

A fictional retailer that sees containment rise after removing the 'talk to agent' button also sees complaints and repeat contacts rise, so the apparent gain reflects friction, not improvement. A high containment rate can be good for clear tasks such as checking opening hours but harmful when complex billing or safety issues need a person, so set different expectations by intent.

A fictional utility bot answers an outage status question accurately and offers a source update, while a different customer who reports a hazardous wire should use an urgent human or emergency route, and forcing both into automation is unsafe. Some bots complete actions such as changing a booking while others only supply information, so containment without completed action may be a weak measure for the first type and task completion should be tracked separately.

Accuracy matters, because a confident but wrong answer can be more damaging than an early handoff, so sample transcripts, verify facts and follow changes to product policies. An automated flow can ask clarifying questions, but too many loops may create abandonment, so measure repeat prompts and where customers leave, not just whether an agent was reached.

Exclude internal tests and bot spam from a customer metric, and if one user opens three sessions for the same issue, report whether the unit is conversations or unique issues. Human support cost may fall as useful automation improves, but customers can come back through another channel, moving cost rather than removing it, so watch total contact volume and cost per resolved issue.

An A/B test can compare a revised flow with the old one using both containment and verified resolution while protecting sensitive cases, and vendors may calculate automated resolution differently, so ask for raw counts, definitions and sample logic. Containment is a routing measure to use alongside satisfaction, verified resolution, repeat-contact and error rates, and a manager should review edge cases after a product or policy update because a once-correct answer can become stale while containment still looks strong, so version the knowledge source and test the bot after material changes.