New

Chatboq Ticketing System launching soon — Join the waitlist for early access

Chatboq

How to Configure Chat Routing Rules by Department

A diagram showing chat conversations routed to sales, support and billing queues

How-To / Feature Guides

Kevin Tan

September 18, 2026

Reading Time

7 minutes

Create departments you can staff during all covered hours, not departments that mirror your organisational chart.

The staffing test

Every department needs at least two people available during covered hours, or conversations routed there will wait whenever that one person is busy or absent.

Applying this test usually reduces a proposed list of six or seven departments to three, which produces shorter waits rather than worse specialisation.

Sales and support as the primary split

For most businesses the meaningful division is between people considering a purchase and people who have already bought, since these need different skills and different urgency.

Starting with this split and adding further departments only where volume and staffing justify it is the pattern that works reliably.

Billing as a common third

Billing questions frequently need account system access that general support does not have, which makes it the department most commonly justified after the primary split.

It is also high volume and highly automatable, which means much of it may not need a department at all once automation handles the routine cases.

Merging rather than adding

Where an existing department is consistently understaffed, merging it into a broader one produces better service than leaving it as a queue people wait in.

Reviewing this annually catches departments created for a product or team that no longer exists.

Summarize this article with AI

ChatGPT

Perplexity

Claude

Table of content

Choose the Routing Inputs

Route on page context, detected intent and the customer record, using a department picker only as a fallback rather than the primary mechanism.

Page context is the easiest signal

A visitor on a pricing page is almost certainly a prospect and one on a support article almost certainly a customer, which routes correctly without asking anything.

Page-based routing is simple to configure and delivers most of the benefit of more sophisticated approaches, which makes it the right place to start.

Intent for the ambiguous cases

Where page context is unclear, such as a homepage or a blog post, routing on what the visitor actually says is considerably more accurate than guessing.

This requires reliable intent detection, and the confidence threshold should govern whether the intent route is trusted or a general queue is used.

The customer record

An authenticated customer with an account manager, a service tier or an open case should route accordingly rather than entering a general queue.

This is the routing input that produces the most noticeable experience improvement and requires CRM integration to work.

The department picker as a fallback

Asking visitors to choose a department requires them to understand your structure, and they frequently choose wrongly, which produces the transfers routing was meant to prevent.

Where a picker is used, label options by what the visitor wants rather than by team name, and keep the list to three or four.

Combining signals in priority order

A defined precedence, usually customer record first, then intent, then page, then picker, prevents rules competing and producing unpredictable outcomes.

Documenting that order is what allows someone to explain why a particular conversation was routed where it was.

Handle Coverage Differences

Departments frequently have different hours, and routing must account for that rather than sending conversations into an unstaffed queue.

Coverage per department

Sales may work standard hours while support covers extended ones, which means the same routing rule produces very different outcomes at different times of day.

Configuring coverage per department, and checking it before routing, prevents the conversation that waits overnight for a team that finished at five.

What happens outside hours

Outside a department's coverage, conversations should route to automation, to a covering department, or to message capture with an honest response time.

Leaving this undefined is the most common cause of conversations sitting unanswered without anyone realising.

Overflow between departments

Every department needs a defined overflow destination and a wait threshold, since a queue with nobody logged in will otherwise hold conversations indefinitely.

Recording the original routing when a conversation overflows lets the intended department reclaim it later without losing the classification.

Prevent Transfers and Loops

Transfers are direct evidence of misrouting, and transfer loops are the failure customers remember.

Making transfer easy but visible

Agents need to transfer misrouted conversations, and the process should carry the full context so the customer does not repeat themselves.

Every transfer should be logged with a reason, since the pattern of reasons is what identifies the routing rules responsible.

Preventing loops

A conversation transferred back to a department it came from should trigger an alert rather than continuing to move, since nobody is taking ownership.

A hard limit on transfers per conversation, with escalation to a lead beyond it, prevents the experience customers describe as being passed around.

Reviewing transfer reasons

Grouping transfers by origin and destination usually reveals a small number of rules responsible for most misrouting, which makes the fix targeted.

This review is worth running monthly, since routing accuracy degrades as products and teams change.

Test Before Enabling

Routing changes affect every conversation, so they should be validated against real examples rather than enabled and observed.

Testing against historical conversations

Running a proposed configuration against recent conversations shows where each would have been routed and reveals the rules that behave unexpectedly.

This catches the overlapping rules whose interaction nobody predicted, which is the most common configuration error.

Checking the edge cases

Test what happens outside coverage hours, when a department is empty, when intent confidence is low and when a conversation matches no rule at all.

The last of these is the most important, since an unrouted conversation is invisible until a customer complains.

Enabling gradually

Applying new routing to a proportion of traffic before enabling it fully limits the consequence of a rule behaving differently from expectations.

Monitoring transfer rate during that period is the clearest early indicator of whether the configuration is working.

Measure Routing Accuracy

Transfer rate, unrouted conversations and resolution by department together show whether the configuration is doing its job.

Transfer rate as the primary measure

Each transfer is direct evidence a routing decision was wrong, which makes this the clearest available measure of configuration accuracy.

Tracking it by origin department identifies which rules are responsible rather than showing only that a problem exists.

Unrouted and stalled conversations

Conversations sitting unassigned beyond a threshold should be counted and alerted on, since these are complete failures rather than inaccuracies.

A well-configured system reports zero of these, and any persistent count indicates a rule gap or an unstaffed department.

Outcomes by department

Comparing resolution and satisfaction across departments shows whether specialisation is producing better outcomes than a general queue would.

Where it is not, simplifying the routing usually improves service more than adding further conditions.

Configuring Department Routing in Chatboq

Chatboq routes on page, intent and customer record with per-department coverage, mandatory overflow and a required catch-all.

Starting with page mapping

Map page groups to departments first, since this delivers most of the routing benefit immediately and requires no intent configuration or integration.

Intent-based rules and customer record routing then layer on for the pages where context alone is ambiguous.

Coverage and overflow enforced

Each department declares its coverage hours and an overflow destination, so conversations never route into a queue nobody is watching.

A catch-all destination is required rather than optional, which removes the unrouted conversation failure entirely.

Reporting that supports review

Transfer rate by origin and destination, unassigned conversation alerts and resolution by department are reported together for monthly review.

That combination is what keeps a routing configuration accurate as products, teams and volumes change over time.

Reviewing quarterly

Departments, coverage and page mappings all drift as products, teams and site structure change, and a routing configuration nobody reviews degrades quietly.

A quarterly check against transfer rate and rule usage catches this before it shows up as customer complaints about being passed around.

Frequently AskedQuestions

Page, intent and customer record routing with per-department coverage hours, mandatory overflow destinations, a required catch-all, and transfer rate reporting by route.

Log a reason on every transfer, alert when a conversation returns to a department it came from, and enforce a transfer limit with escalation to a lead beyond it.

Conversations should route to automation, a covering department, or message capture with an honest response time, never into an unstaffed queue.

Page context. A visitor on a pricing page is almost certainly a prospect and one on a support article a customer, which routes correctly without asking anything.

Only as a fallback. A picker requires visitors to understand your structure, and they choose wrongly often enough to generate the transfers routing should prevent.

As many as you can staff with at least two available people during all covered hours. Most teams find this reduces a proposed list of six to about three.