What Is a Bot Handoff Threshold? Chatbot Design Explained

Setting a threshold means weighing the cost of a wrong automated answer against the cost of an unnecessary escalation, and those costs differ by topic.

The cost of being wrong

A wrong answer about opening hours wastes a customer a few minutes, while a wrong answer about eligibility or safety can produce real harm and real liability.

Quantifying this roughly, even as a three-level scale, gives a defensible basis for setting different thresholds rather than choosing numbers by instinct.

The cost of escalating unnecessarily

Every avoidable escalation consumes agent capacity and adds queue depth for customers who genuinely need a person, which is a real cost even though it is invisible.

It also undermines the case for automation internally, since a deployment escalating most conversations looks like it is not working.

Asymmetry as the guiding principle

Where the two costs are asymmetric, the threshold should reflect that asymmetry rather than sitting in the middle as a compromise.

For most sensitive topics the asymmetry is extreme, which argues for escalating readily rather than tuning for marginal deflection gains.

Some situations should escalate regardless of confidence, and these should be configured as absolute rules rather than threshold adjustments.

Explicit requests for a person

A customer asking for a human should reach one without the assistant first attempting to resolve the issue, since attempting to is the behaviour most consistently complained about.

The small number of avoidable escalations this creates is considerably cheaper than the frustration of being refused.

Safety and welfare signals

Any indication of a safety concern, medical situation, distress or vulnerability must reach a person immediately with no automated attempt at handling.

These rules should be written conservatively and tested, since a false positive costs an agent a minute and a false negative can be serious.

Legal, complaint and regulated topics

Formal complaints, legal threats and regulated subject matter should escalate by default because the risk of an automated response is disproportionate to the effort saved.

This is also the boundary compliance reviewers will ask about, and having it configured explicitly makes that conversation straightforward.

A single global threshold is always wrong somewhere, since it will be too cautious for routine topics and too permissive for sensitive ones.

Grouping topics by consequence

Sorting intents into a small number of consequence bands, rather than setting a threshold per intent, keeps the configuration maintainable while capturing the important differences.

Three bands covering routine, moderate and high consequence is usually sufficient and considerably easier to review than dozens of individual settings.

Starting cautious and relaxing

Beginning with conservative thresholds and lowering them as evidence accumulates is safer than the reverse, since early errors damage trust in the deployment.

Each relaxation should be accompanied by a review of accuracy on that topic rather than assumed to be safe because escalation volume was high.

Reviewing when the intent set changes

Adding new intents affects confidence distribution across existing ones, which can quietly move behaviour on topics nobody touched.

Reviewing thresholds after significant intent changes catches this before it appears as a change in escalation rate nobody can explain.

Documenting the reasoning

Recording why each band was set where it was prevents someone later adjusting it without understanding the consequence assessment behind the original decision.

This documentation is also what makes the policy reviewable by people who were not involved in configuring it.

Escalating into an empty or overloaded queue is worse than a slightly uncertain automated answer, which argues for thresholds that account for availability.

Outside coverage hours

When no agent is available, escalating produces an indefinite wait, so the assistant should either attempt more or capture the request with an honest response time.

The unconditional triggers should still fire, but with a different action, offering the emergency route rather than a queue nobody is watching.

During heavy load

When queues are long, marginally uncertain conversations may be better served by an attempt plus an offer to escalate than by an immediate transfer into a long wait.

This should be a deliberate configured behaviour rather than something that happens implicitly, and it should never apply to unconditional triggers.

Being honest about the wait

Where escalation happens into a queue, telling the customer the expected wait and offering an asynchronous alternative is what keeps the handoff acceptable.

Silence after a handoff is the most common cause of abandonment at exactly the point the conversation was being taken seriously.

Escalation rate alone tells you nothing useful, and the quality of escalations is what indicates whether the threshold is set correctly.

Reviewing escalations for necessity

Sampling escalated conversations and judging whether the assistant could reasonably have handled them shows whether the threshold is too cautious.

A high proportion of avoidable escalations on routine topics is the clearest signal that the setting can safely be relaxed.

Reviewing non-escalations for errors

The more important review is sampling conversations the assistant handled confidently, since confident errors never appear in escalation data at all.

Finding wrong answers here means the threshold is too permissive regardless of how good the escalation rate looks.

Watching post-escalation outcomes

If escalated conversations are resolved quickly by agents doing something simple, the threshold is likely too cautious on that topic.

If they consistently require genuine expertise, the threshold is working and the escalations are earning their cost.

Chatboq supports per-topic thresholds, separately configured unconditional triggers, capacity awareness and reporting on escalation quality.

Policy expressed in configuration

Consequence bands, per-topic thresholds and unconditional triggers are configured distinctly, which makes the escalation policy readable rather than implied by scattered settings.

That readability is what allows a compliance or support lead to review the policy without reading every flow.

Triggers that cannot be overridden

Explicit requests for a person, safety signals and regulated topics escalate regardless of confidence, capacity or any other threshold setting.

Configuring these as absolute rather than as very high thresholds prevents them being relaxed accidentally during routine tuning.

Reporting that supports tuning

Escalation rate is reported by topic alongside post-escalation resolution and samples of high-confidence conversations, which is what makes tuning evidence-based.

Reviewing both directions of error is the only way to tell whether a threshold change improved the system or simply moved the failure somewhere less visible.