Triage classifies a call. Routing decides what happens next. These are two separate problems, and conflating them is one of the more common design mistakes in voice automation for alarm response. A system can be quite good at determining whether an alert warrants escalation and still deliver that escalation to the wrong person, through the wrong channel, with incomplete information. The classification is only as useful as what you do with it.
This post walks through how our routing logic is structured, the decisions that went into it, and where we made tradeoffs. It is aimed at operations managers and technical leads at monitoring centers who are evaluating how routing fits into their existing dispatch workflows.
The Starting Point: Classification Output
When a triage conversation completes, the system produces a structured output. This is not a sentiment score or a confidence percentage. It is a classification with a specific value from a defined set: escalate immediately, escalate with note, log and close, or unable to determine. Each classification value triggers a different branch of the routing logic. The classification also carries a structured summary of what was asked, what was confirmed, and what the caller said word-for-word on the key determining questions.
The routing layer reads the classification and the summary. It does not re-interpret the conversation. By the time routing fires, the classification decision has already been made by the triage layer. Routing's job is to execute that decision correctly.
Routing for Escalate Immediately
This is the highest-priority path. A call classified as escalate-immediately bypasses any queue and goes directly to the on-call dispatcher. The routing decision here has two sub-components: which dispatcher and through which channel.
Which dispatcher is determined by a configurable priority list per account or per zone. A monitoring center can specify a primary on-call contact, a secondary backup, and a tertiary supervisor. The routing layer attempts the primary first. If there is no answer within a configurable timeout (typically 20 to 30 seconds), it moves to the secondary. It does not wait indefinitely and it does not loop back to the queue. An unanswered escalation is an escalation failure, and the system treats it as one, logging the attempt and alerting the supervisor contact regardless.
Which channel is also configurable. Our current implementation supports outbound call and SMS with call summary. The SMS path is used when a dispatcher confirms they are in a context where they cannot take a voice call (in a vehicle, on another active incident) and prefers to receive the structured summary via text to decide on a callback or direct emergency services contact. The channel is set at the account level and can be updated by the operator.
Routing for Escalate With Note
This classification applies to calls where triage established some concern but not an immediate confirmed incident. The caller reported uncertainty, could not confirm access, or the triage questions produced ambiguous answers. The routing for this path places the call summary in a priority queue for the dispatcher rather than initiating an outbound escalation.
The practical difference matters for shift management. A confirmed incident at 3am warrants waking a dispatcher. A call where the caller said the premises looked fine from outside but could not access the building warrants a dispatcher reviewing it promptly, not necessarily being woken from a break for it. This distinction is an operational judgment, not a technical one, and we designed the routing to respect it rather than flatten everything into binary escalate-or-close.
The Failure Mode We Prioritise Against
The failure mode we care most about preventing is a missed escalation: a call classified correctly as escalate-immediately that failed to reach a dispatcher due to a routing fault. We prioritise reliability of delivery over efficiency of delivery. This means the routing layer is conservative about marking a delivery as complete.
An SMS is not confirmed delivered until the carrier acknowledgment is received. An outbound call is not confirmed answered until the recipient says a word (not just picks up, because automated phone spam has made people pick up and wait). If delivery confirmation does not arrive within the timeout window, the system escalates the delivery failure to the supervisory contact. It does not silently fail.
This produces some false-alarm delivery failures, cases where the dispatcher answered but the confirmation was delayed. Those are nuisances. A routing system that silently fails on a real escalation is a different category of problem. We have made the conservative choice deliberately and we tell operators clearly which tradeoff we have made.
Time-of-Day and Day-of-Week Rules
Most monitoring centers have different coverage arrangements for weekday nights versus weekend nights. The on-call list for a Tuesday at 3am is different from Saturday at 3am. The routing layer reads the configured schedule and applies the correct contact list for the time of the call, not the time the account was set up or the time the last call happened.
This sounds obvious. It is surprisingly often wrong in systems that were built for a different primary use case and adapted for monitoring. We built the scheduling layer first because it is a first-class requirement for any overnight response product, not a feature you add later.
What the Handoff Looks Like From the Dispatcher Side
When a dispatcher receives an escalation from Vox Talk, whether by call or SMS, they receive a structured summary that includes: the account name and zone, the triage classification, the key questions asked and what the caller said, the call timestamp, and a callback number for the original caller if one was captured. They do not receive a full transcript of the conversation. They receive the information they need to make a dispatch decision immediately.
We designed the handoff around a specific constraint: a dispatcher who has just been woken at 3am should be able to make a sound dispatch decision from the summary within 30 seconds, without having to listen to a recording or call the account back for information the triage conversation already gathered. The summary format was iterated based on feedback from the operators in our pilot program. The current format reflects what experienced dispatchers said they actually needed in that moment.
The Configuration Layer
All of the routing logic described here is configurable at the account level. Different accounts can have different escalation contact lists, different channel preferences, different timeout windows, and different schedule definitions. The configuration interface allows operators to set and update these without technical support from us. This matters because contact lists change, schedules change, and personnel change. A routing layer that requires a support ticket to update an on-call contact is not fit for operational use in a monitoring center where that kind of change happens regularly.
The tradeoff in configurability is complexity: more configuration options mean more ways to configure things incorrectly. We have built validation logic that checks for common configuration errors (empty contact lists, overlapping schedule windows, channels specified for contacts that have not confirmed them) and flags them before they can cause a routing failure on a live escalation. Detecting misconfigurations at setup time rather than at 3am under a real incident is a basic reliability principle that saved our pilot operators from several problems they would otherwise have found the hard way.