Chatbot Containment Rate Benchmarks by Use Case (2026)

Requests scoring well on all five properties are where containment approaches its practical maximum.

Status and information lookups

Order status, delivery estimates, account balances and appointment details are factual, accessible and carry no judgement.

These are the highest-volume category in most operations and the most reliably contained.

Documented policy questions

Returns windows, opening hours, eligibility rules and process explanations have definite documented answers.

Containment here depends entirely on content currency rather than on anything else.

Structured transactions

Booking, rescheduling, cancelling within policy and updating details are rule-based actions with clear success criteria.

These contain well where integration exists and not at all where it does not, which is the sharpest single dividing line.

Self-service actions

Password resets, preference changes and subscription pauses are reversible, rule-based and carry little emotional weight.

These are frequently the best first automation targets for exactly these reasons.

Some use cases contain the majority of instances and reliably produce a residue that needs a person.

Returns and refunds within policy

Clear cases contain well and edge cases, condition disputes and requests outside the window do not.

The split is frequently around three quarters clear and a quarter requiring judgement, which varies by policy strictness.

Technical troubleshooting

Common documented issues contain and novel or compound problems do not, which makes containment depend on documentation depth.

This category responds well to sustained content investment, unlike the genuinely non-containable ones.

Billing questions

Explaining a charge contains well and disputing one does not, which is the same topic split by whether judgement is required.

Treating billing as one use case produces a misleading containment figure for both halves.

Product recommendations

Narrowing by stated criteria contains and genuine advice does not, and customers move between the two within a conversation.

This makes the handover point the design question rather than whether to automate at all.

Non-Containable Use Cases

Some categories should not be contained regardless of capability, and attempting to raises risk rather than performance.

Complaints

A complaint requires acknowledgement, judgement about remedy and frequently discretion, all of which automation handles poorly.

Containing complaints is achievable and is the wrong objective.

Regulated advice

Financial, medical and legal advice carry obligations that make automated handling inappropriate regardless of accuracy.

These should be recognised and routed rather than attempted.

Safety and vulnerability

Anything involving harm, distress or a vulnerable customer needs a person, and the cost of getting this wrong is disproportionate.

Recognition rules should be broad here rather than precise.

Genuine exceptions

Requests requiring someone to decide whether to depart from policy are definitionally judgement and should reach a person with discretion.

Automating a decline here converts a recoverable situation into a complaint.

Your realistic containment ceiling follows from your contact mix, which you can calculate rather than estimate.

Inventory the contact reasons

Listing the top contact reasons with their volumes takes an afternoon and is the input the calculation needs.

Volume concentrates heavily, so twenty reasons usually cover the large majority of contacts.

Score each on the five properties

Assigning each reason to the highly, partially or non-containable tier produces a weighted expectation for the whole operation.

This is a better forecast than any published figure and it is specific to you.

Note the integration dependency

Marking which use cases require system access identifies where the containment is available only after integration work.

This turns the automation roadmap into a sequencing decision rather than an aspiration.

Revisiting after changes

Adding a product, changing a policy or connecting a system moves several use cases between tiers at once.

Re-scoring after any significant change keeps the expectation accurate rather than anchored to the original assessment.

Every operation has a containment ceiling set by its mix, and knowing it prevents pursuing an unachievable target.

The non-containable share

Complaints, exceptions and judgement cases set a floor on escalation that no capability improvement removes.

This share differs enormously between businesses and is the main reason cross-organisation comparison fails.

Approaching it asymptotically

Each increment of containment costs more than the last, since the easy use cases are automated first.

Recognising diminishing returns prevents continued investment past the point where it pays.

Raising the ceiling

The ceiling moves through integration and documentation rather than through better language capability, which is where effort should go.

Moving a use case from partially to highly containable is more valuable than marginal improvement on ones already contained.

Chatboq reports containment by use case with escalation reasons, which shows where the ceiling is and why.

By use case rather than overall

An overall containment figure conceals which use cases are performing and which are not, which is where the work actually is.

Per use case reporting turns the metric into a roadmap rather than a score.

Escalation reasons attached

Whether a use case escalates through missing content, missing access, low confidence or policy identifies what would raise its containment.

Policy escalations are reported separately, since these represent the intended ceiling rather than a shortfall.

Adjusted for abandonment

Conversations the customer left are excluded rather than counted as contained, which produces a figure that reflects what customers experienced.

Resolution is reported alongside, since containment without resolution is a measure of escalation rather than of success.