Skip to content
TestimonialsGet a Free Blueprint

Case study · Government & utilities

Two hundred calls, one incident, one answer

When gas goes down on a street, the utility does not get one report — it gets two hundred. We built an outage system on Dynamics 365 CRM that clusters those reports into a single incident, dispatches against it once, and gives every caller the same restoration estimate.

Start a project like thisSee more of our work

Engagement · Implementation & rollout

Public utility outage handling, where a delay is a safety issue.

Industry
Government & utilities
Solution
Outage management system
Platform
Dynamics 365 CRM
Engagement model
Dedicated product team
Scope
Implementation, dispatch, public status
Users
Call handlers, dispatchers, field crews
Constraint
Safety-critical response and reporting
Peak load
Hundreds of reports per incident

Outcomes

What an outage system is judged on

Time to dispatch, and whether residents were told the truth about when service returns.

  • 4 min From first report to crew dispatched

    Clustering happens as reports arrive, so a dispatcher sees one incident with a location and a severity rather than a growing pile of individual calls to triage.

    Measured from first report timestamp to dispatch, across incidents after rollout

  • 96% Of reports clustered automatically

    Reports are matched to an existing incident by location and symptom as they arrive, so call handlers confirm rather than create.

    Measured across reports over the first operating season

  • 1 Restoration estimate per incident

    Every caller, every channel and the public status page draw the same estimate from the incident record, so the utility does not contradict itself.

    By design: single source for restoration time

Context

What made outage handling hard

The problem is not the engineering response. It is everything around it.

The organisation

A public gas utility responsible for distribution across a regional network, with a 24-hour call centre and field crews on rota.

The starting point

Reports were logged individually. Dispatchers worked out which ones were the same incident by reading them, which took time the response did not have.

The trigger

A gas outage is a safety event. Time spent working out that forty calls describe one street is time a crew is not moving, and residents receive different answers from different handlers in the meantime.

What they wanted

Reports clustered into incidents automatically, dispatch driven by severity, and one restoration estimate that every channel reads from.

Constraints

Load arrives in bursts, not evenly · a mis-clustered report can hide a second, separate incident · field crews work with intermittent connectivity · public communication is scrutinised after every event.

System

What it runs at today

The system as it runs during an event.

  • 100s Reports per incident

    Clustered as they arrive

  • 4 min To dispatch

    From the first report

  • 1 Restoration estimate

    Shared by every channel

  • 24/7 Operation

    With crews on rota

The engineering problem

Four problems in outage response

Each one costs minutes, and in a gas outage minutes are the whole product.

  1. Two hundred reports of one problem

    A street-level outage generates reports from every household. Handled individually, they consume the call centre and bury the dispatcher.

    What we did

    Automatic clustering by location and symptom as reports arrive. The dispatcher sees one incident with a growing report count, not two hundred records.

  2. Clustering can hide a second incident

    Aggressive clustering is worse than none: a genuinely separate outage swallowed into a neighbouring incident goes unattended.

    What we did

    Clustering tuned conservatively with an explicit split action, and an alert when reports inside an incident diverge in location or symptom.

  3. Different callers, different answers

    When the restoration estimate lives in each handler's head, residents ring back, compare answers and lose trust in the utility.

    What we did

    One estimate held on the incident, published to handlers, the status page and outbound messages simultaneously.

  4. Crews work where connectivity does not

    Underground and rural work happens without a usable connection, but the job data has to be there and the update has to arrive eventually.

    What we did

    Offline-capable crew view with queued updates that sync when connectivity returns, and dispatch that accounts for the last known position.

Architecture

How it fits together

Simplified — the shape of the system rather than every service in it.

  1. Report intake

    • Phone
    • Web form
    • Field reports

    Every channel writes the same structured report: location, symptom, reporter, time.

  2. Clustering

    • Location matching
    • Symptom matching
    • Split & merge

    Reports matched to open incidents as they arrive, with human override in both directions.

  3. Incident & dispatch

    • Severity
    • Crew assignment
    • Restoration estimate

    One record per incident, carrying the estimate every channel reads.

  4. Communication

    • Handler view
    • Public status
    • Outbound messages

    All drawing from the incident, so the utility says one thing.

Clustering is deliberately conservative. We would rather a dispatcher merge two incidents than discover a hidden one after an event.

Solutions

What we implemented

An outage system built for the burst, not the average.

  • Report intake

    Structured reports from phone, web and field, written the same way.

  • Clustering engine

    Location and symptom matching on arrival, with split and merge.

  • Severity model

    Derived from report volume, geographic spread and symptom type.

  • Dispatch

    Crew assignment against incidents, informed by position and severity.

  • Crew view

    Offline-capable job detail with queued updates.

  • Public status

    Incident state and estimate published automatically.

Key capabilities

What it does day to day

Six capabilities across the outage lifecycle.

CapabilityRunsRefreshWhat it does
Report intake All channels Continuous Structured reports from phone, web and field staff
Clustering Automatic On arrival Reports matched to open incidents by location and symptom
Severity Automatic Continuous Derived from report volume, spread and symptom type
Dispatch Dispatcher Per incident Crew assignment against the incident, informed by position and severity
Crew view Field Offline capable Job detail available without connectivity, updates queued
Public status Automatic Continuous Incident state and restoration estimate published as they change

Integrations

How the moving parts plug in

From two hundred calls to one dispatch.

Reports arrive

  • PhoneCall centre
  • Web formPublic
  • Field reportsCrews and staff

Clustering & severity

  • Location match
  • Symptom match
  • Severity derivedFrom volume and spread

Incident

  • Crew dispatched
  • Restoration estimateOne, shared
  • Public statusPublished automatically

The dispatcher's first view of a street outage is a single incident with a report count and a severity, which is the difference between a four-minute dispatch and a twenty-minute one.

Security & data

What protects the response

A safety-critical system has to fail visibly, not quietly.

  • Conservative clustering

    The system prefers two incidents over one hidden outage, with divergence alerts inside an incident.

  • Full event record

    Every report, cluster decision, dispatch and estimate change recorded for the post-event review that always follows.

  • Role separation

    Handlers, dispatchers and crews have distinct rights, with merges and splits restricted to dispatch.

  • Degraded operation

    If clustering is unavailable, reports still arrive and are workable manually rather than being lost.

The brief

The response was never the bottleneck

The utility's crews were fast. What slowed restoration was the time between the first report and somebody understanding that forty calls described one street.

We attacked that gap specifically: cluster on arrival, derive severity from the cluster, and put one estimate where everyone can read it.

  • Reports clustered into incidents as they arrive
  • Severity derived from volume, spread and symptom
  • One restoration estimate across every channel
  • Crew view that works without connectivity

What the system had to survive

  • 01Hundreds of reports arriving in minutes
  • 02A second incident that must not be swallowed by the first
  • 03Field work without reliable connectivity
  • 04Public scrutiny of every communication after the event

Process

We tuned clustering against real event data

Clustering rules that look sensible in a workshop behave differently against a real winter.

  1. Stage 1

    Event replay

    Historical outage reports replayed through candidate clustering rules to see what they would have produced.

  2. Stage 2

    Tuning for safety

    Rules deliberately biased towards splitting, because a merge is a dispatcher action and a hidden incident is an investigation.

  3. Stage 3

    Dispatch design

    Built with dispatchers at the desk, so the incident view carries what they actually decide from.

  4. Stage 4

    Crew view offline

    Tested in the conditions crews work in, not on office wifi.

  5. Stage 5

    Public communication

    Status publishing reviewed with the communications team before go-live.

Technology

Dynamics 365 CRM as the incident backbone

Case management with an outage model on top of it.

CRM

  • Dynamics 365 CRM
  • Custom incident entities
  • Case management

Clustering

  • Location matching
  • Symptom matching
  • Severity derivation

Field

  • Offline crew view
  • Queued updates
  • Position awareness

Communication

  • Public status
  • Outbound messaging
  • Handler view

Business impact

What changed during an event

Three things the utility noticed in its first operating season.

  • Dispatch in minutes, not tens of minutes

    Clustering removed the triage step that stood between a report and a crew.

  • The call centre stopped drowning

    Handlers confirm a known incident instead of creating a record per caller.

  • One public answer

    Residents, the status page and outbound messages carry the same estimate.

The result

One incident, one crew, one answer

Reports cluster as they arrive, severity comes from the cluster rather than a handler's judgement, and crews are moving within minutes of the first report.

Residents get the same restoration estimate whoever they ask, which is most of what public trust in a utility is made of.

  • Four minutes from first report to dispatch
  • 96% of reports clustered automatically
  • One restoration estimate across all channels
  • Crew view that works underground
Talk about a project like this

What we hold to in emergency systems

  • 01Design for the burst, because the burst is the whole job
  • 02Bias clustering towards splitting — a hidden incident is the worst outcome
  • 03Test the field experience in the field
  • 04One estimate, one source, every channel

Verified reviews

What clients say about our Dynamics work

Verified reviews from clients of ours on similar work, published on Clutch. They are not from this project.

5.0 27 verified reviews
See All Testimonials Read All Reviews on Clutch

Related

Services we used on this project

Free discovery call

Have an idea? Let's turn it into AI-powered software.

Book a free discovery call with our experts. Share your idea and we will help you shape the scope, timeline and budget, under NDA.

  • Free consultation
  • NDA before we talk
  • Transparent estimate
Book a Discovery Call info@silverscintilla.com