The problem
The client runs a regional electric utility's outage desk. During a storm the line is the product. Callers want to know if their address is on the map and when the utility expects to restore it. Agents were reading the same outage tool the public site uses, then paraphrasing. Under volume, paraphrase became a guessed clock time, and those callers rang back when the lights stayed off.
A scripted IVR already offered the public estimated time. It was stale within minutes of a new outage, and it could not say 'we do not have your address on a known outage' without dumping the caller into a queue that was itself the bottleneck.
Why the map is the only source
A restore time is an operational statement. If it is not on the outage map, the desk does not know it, and the model must not smooth that gap into a helpful hour. The useful call is the one that quotes the map, or says the address is not on it and offers the next real step, which is a person.
Architecture
The outage tool is the system of record
Each call resolves the address against the same outage service the public map uses, at the moment of the call. The assistant may speak the outage id, the status, and the estimated restore time only if that service returned them. A cached answer from an hour ago is not used on a status call.
No time the map did not return
The spoken script is assembled from fields, not from a free-form completion. If the estimated-restore field is empty, the script says the utility has not published a time. There is no language-model step that is allowed to fill one in.
Repeat-call detection from the address
If the same address called inside the window the client already used for repeat-call reporting, the assistant says what changed on the map since the last call, or that nothing has changed. That is the difference between a useful update and a second reading of the same sentence.
A person for everything off the map
Addresses the service cannot match, reports of a downed line, and any safety wording transfer to an agent with the address and the lookup result on the screen. The assistant does not troubleshoot a line.
Challenges and tradeoffs
- Address matching failed on multi-unit buildings. The map often had the building, not the unit. Callers with a unit number were told there was no outage. We match the building, say the unit is not in the record, and transfer if the caller is reporting a unit-level outage the map does not show.
- Estimated times were being rounded into promises. The map stores a window. Early copy said 'back by 4.' We now speak the window the field contains, including when the window is wide.
- Safety calls must not wait on a lookup. A caller who says a line is down is transferred immediately, before the outage lookup finishes. We had that backwards in the first call flow, and a review of tagged safety phrases caught it before the pilot.
Results
Over the pilot storms, repeat calls, measured the way the desk already measured them, were 28% lower than the comparable storms the client picked as the baseline. Every restore time in the call log was a value the outage service had returned. Review of the transcripts found no model-authored clock time.
Agents still handle the calls the map cannot answer. The line is shorter because the calls the map can answer no longer invent a third version of the status.
What we'd do differently
We would have listened to safety-phrase calls in the first week of transcription review. The transfer-before-lookup fix was cheap. Finding it late would not have been.