Deployment blueprint

A dispatch desk that stays reachable when the phones are the busiest.

A regional utility with a dispatch desk, field crews on the road, a public number that floods during a storm and a duty to tell residents what is happening. This blueprint shows how 3CTel designs priority queues, overflow intake, mass notification and continuity for a critical-services dispatch operation.

  • Priority queues for hazard reports over routine calls
  • Outbound mass-notification calls and SMS
  • AI overflow intake capturing address and hazard

For a utility or community critical-services dispatch desk, 3CTel configures priority queues that put hazard reports ahead of billing and routine calls, an outbound mass-notification path for calls and SMS to affected residents, an AI intake agent that captures address and hazard when every dispatcher is busy, automatic failover forwarding to an alternate site or mobile devices, and recording on dispatch lines for incident review. Service is bilingual throughout.

Deployment blueprint: a representative, anonymized scenario compiled from how 3CTel implements this kind of organization. No client is named and no result figures are stated; every parameter is a configuration choice we design with you.

Sector
Utility and community critical services
Users
38 (dispatch, field crews, customer service, duty managers)
Sites
1 dispatch centre, 1 alternate site, crews on the road
Hours
24x7 dispatch; business-hours customer service
Languages
English and French
Modules
Contact Centre, business phone, SMS, call analytics
AI agents
Overflow intake with address and hazard capture, outage-status line
Integrations
Outage-management and work-order systems via API and webhooks

Situation

A regional utility runs a dispatch desk around the clock. On a normal day the public number carries billing questions, service requests and the occasional report of a downed line or a gas smell. During a storm the same number receives more calls in an hour than it normally does in a week, and most of them say the same thing. Dispatchers must still be able to hear the one caller reporting a live hazard.

Field crews are reached by radio and phone. Residents expect to be told when service will be restored, in the language they speak. Regulators and the utility's own governance expect calls on the dispatch line to be recorded and reviewable after an incident. The dispatch centre itself may be affected by the same event it is responding to.

Requirements

  • A dispatch queue that takes priority over customer-service and billing queues, with hazard reports moved to the front.
  • Overflow to an AI intake agent that captures location, hazard type and callback details when dispatchers are saturated.
  • An outbound mass-notification path for calls and SMS to residents in an affected area, with an inbound status line they can call back.
  • Failover forwarding to an alternate site or to mobile devices, tested on a schedule.
  • Recording on the dispatch line with an announcement, retained for incident review.
  • Bilingual greetings, queues and AI intake.
  • Integration with the outage-management and work-order systems so intake creates records without re-keying.

Call-flow design

The public number opens with a short menu that separates 'report a hazard or outage' from everything else. Hazard callers go to the dispatch queue with priority; billing and service callers go to customer service and, when closed, to the AI agent or voicemail. When the dispatch queue exceeds a wait threshold, callers are offered the AI intake so that every report is captured even if a dispatcher cannot take it live.

Conceptual illustration of the 3CTel interface — not a screenshot

WhenThen
A caller chooses 'report a hazard or outage'The call enters the dispatch queue at priority; the recording notice is announced
A caller mentions gas, fire, a downed wire or injury to the AI or a customer-service agentThe call is moved to the front of the dispatch queue immediately, and the caller is told to hang up and call 9-1-1 if there is immediate danger to life
The dispatch queue wait exceeds the threshold set with youThe caller is offered AI intake, which captures address, hazard and callback number and creates a record
A large outage is declaredThe outage-status line answers with the latest recorded update in both languages; the mass-notification campaign begins to the affected list
A resident replies to a notification SMSThe reply lands in the dispatch SMS inbox tagged with the campaign, for a dispatcher to review
The dispatch centre loses connectivity or powerInbound numbers forward to the alternate site; if that is unreachable, to duty-manager mobile devices on cellular

AI agents

The AI intake agent exists so that no hazard report is lost when dispatchers are saturated. It is scripted to gather a small set of facts in a fixed order and to get out of the way. It does not assess the hazard, promise a response time or tell residents what to do about a hazard beyond directing them to 9-1-1 for immediate danger.

  • The AI transfers to a dispatcher whenever a caller asks, whenever a life-safety word is heard, and whenever it cannot confirm a location after two attempts.
  • Every AI intake creates a record via API and is logged with the transcript for incident review.
  • The AI never speculates about cause, restoration time or safety beyond the scripted 9-1-1 instruction.

Address capture

Confirms civic address or nearest intersection and reads it back, then captures a landmark if the caller is unsure. The record is created with the location exactly as confirmed.

Hazard capture

Asks what the caller sees in plain words, categorizes from the utility's own list, and flags anything involving gas, fire, downed wires or injury for live transfer to dispatch.

Callback and follow-up

Captures a callback number and whether the caller wants an SMS when service is restored, then adds them to the notification list for that event.

Outage-status line

Reads the latest update recorded by the duty manager, in English or French, and offers a transfer to dispatch for anyone with new information.

Mass notification and outbound

When the duty manager declares an event, an outbound campaign is started from the dispatch console: a recorded voice message and an SMS to the list of numbers for the affected area, drawn from the outage-management system via API. Residents who do not answer get the SMS; residents who call back reach the outage-status line rather than the dispatch queue. Follow-up messages go to the same list as the situation changes, and a final message confirms restoration.

  • Messages are recorded in both languages by the duty manager and reviewed before sending.
  • Outbound calls show the utility's published number so residents recognize it.
  • Delivery and answer status for each number is logged and exported to the incident record.
  • Residents can opt out of SMS by reply; opt-outs are honoured across campaigns.

Integrations

Intake records from dispatchers and the AI agent are created in the outage-management system via API; work orders for field crews follow through the work-order system via webhooks. The affected-address list for notifications is read from the outage-management system rather than maintained by hand. Each connection is scoped during planning and confirmed before activation, and the dispatch console shows the record number back to the dispatcher on the call.

Security, privacy and continuity

  • Canadian law generally requires that callers be informed that a call is recorded; the announcement on the dispatch line is configured with you and the recording is retained for the period your incident-review practice requires.
  • Access to dispatch recordings and transcripts is limited to duty managers and the incident-review role; customer-service staff cannot open them.
  • Failover is layered: dispatch centre, then alternate site, then duty-manager mobile devices on cellular. Each layer is tested on a schedule set with you, and the test result is logged.
  • The alternate site keeps a small number of registered desk phones and the desktop app so dispatch can resume there without configuration changes.
  • Emergency calling from the utility's own phones uses the registered service address for each site and each crew vehicle's assigned device, confirmed at setup.
  • Callers reporting immediate danger to life are always directed to 9-1-1; the dispatch line does not replace emergency services, and greetings say so.

Rollout

  1. Map the event playbook

    Which calls go where on a normal day, on a bad day and when the centre itself is affected. Thresholds, ring times and the failover chain are agreed in writing.

  2. Build and drill on temporary numbers

    Dispatch queue, AI intake, outage-status line and a test notification campaign to internal numbers are run through before any resident hears them.

  3. Connect the systems

    Outage-management and work-order connections are tested with intake records and a mock affected-address list.

  4. Port and switch

    The public and dispatch numbers are ported on a date confirmed with you, outside the storm season if the utility prefers.

  5. Schedule the failover drill

    The first drill is run with the alternate site within the first month, and the cadence for future drills is set.

What we measure

Dispatch queue offered, answered and abandoned by hour; hazard calls moved to priority and time to a dispatcher; AI intakes created and those transferred live; notification campaigns sent, delivered and answered; status-line calls per event; failover drills completed and time to resume at the alternate site; recordings attached to incident reviews.

How does a dispatch desk keep hazard calls ahead of billing calls during a storm?

The public number separates 'report a hazard or outage' from everything else at the first menu, and hazard calls enter a dispatch queue that takes priority over customer service. Any caller who mentions gas, fire, downed wires or injury is moved to the front from wherever they are. 3CTel sets the thresholds and ring times with the utility.

What does AI overflow intake capture for a utility?

Civic address or nearest intersection read back to the caller, the hazard described in plain words and categorized from the utility's own list, a callback number and whether the caller wants an SMS on restoration. The record is created in the outage-management system via API. Life-safety words trigger a live transfer, and the AI directs immediate danger to 9-1-1.

How does mass notification work with the phone system?

The duty manager records a message in both languages, the affected-address list is read from the outage-management system, and the campaign sends a voice call and an SMS from the utility's published number. Delivery status is logged per number, replies land in the dispatch SMS inbox, and residents who call back reach a status line instead of the dispatch queue.

Frequently asked questions.

No. The greeting and the AI intake both direct anyone in immediate danger to call 9-1-1. The dispatch line is for reporting hazards and outages to the utility, and it is designed so those reports are captured and prioritized.

Walk us through your worst day.

Your call volumes on a normal day and a storm day, your alternate site and the systems dispatch uses are enough to design the queues, the notification path and the failover chain.

Call 3CTelBuild My System