By Sagar Shankaran, Founder of CallSphere
The monthly IEEE 1366 reliability close takes 64 hours across three people. What goal-driven agents change, the arithmetic, and what stays with the engineer.
Key takeaways
It is 6:40 on the third business day of the month and the reliability engineer is already at his desk with the blinds still down. On one screen is an outage export from the outage management system covering 3,912 interruption records. On the other is last month's workbook, the one with fourteen tabs, three of which nobody has been able to explain since the analyst who built them moved to transmission planning. He will spend most of the next four days turning the first screen into the second, and on day six it goes to the compliance analyst, who sends it to the commission.
Every distribution utility in the country has some version of this person and this week. The job has a name that sounds small — monthly reliability reporting — and it eats a senior engineer's first quarter of every month, every month, forever.
Start with the outage records. Every interruption needs a start time, a restoration time, a device, a cause code and a customer count. The customer count does not live in the outage management system in a form anyone trusts; it comes from the customer information system, and it has to be tied to the feeder and device topology in the geographic information system, which changed twice last month because two circuits were reconfigured after a line rebuild.
Then the cause codes. A quarter of them are wrong or blank on the first pass. "Equipment failure" gets used for a squirrel because the crew was tired at 2 a.m. and the drop-down was right there. A dig-in that should be coded to third party sits under "unknown." The reliability engineer chases the worst ones down through the work management system to the completed work order and the crew's notes.
Then the exclusion arithmetic. Under IEEE 1366 you compute a major event day threshold from five years of daily system average interruption duration, using the log-normal method with the 2.5 beta multiplier; days above it come out of the reported figures and are reported separately. Get the threshold wrong and every number below it is wrong. Then the workbook: average interruption duration and frequency, customer average duration, the momentary index if your state asks for it, worst-performing circuits, and a narrative on each major event day.
Nobody rebuilds this from scratch. They copy last month's workbook, clear the numbers, paste in the new export, and hope the formulas still point where they should. That is why the fourteenth tab exists and nobody can explain it. It is also why, roughly once a year, somebody catches a broken cell reference three months after the filings went out and the company has to send the commission a corrected report, which is a memorable letter to have to write.
Hear it before you finish reading
Talk to a live CallSphere AI voice agent in your browser — 60 seconds, no signup.
A goal-driven agent is one you hand an outcome to instead of a list of steps: you say "close last month's reliability numbers and give me the filing workbook," and it does the pulling, the matching, the arithmetic and the formatting on its own, then hands back a finished file. That is a genuinely different thing from the chat box you tried in 2024, which could explain the 2.5 beta method to you but could not open your outage export.
Anthropic shipped Claude Cowork on 12 January 2026 and expanded it to web and mobile in July. OpenAI shipped ChatGPT Work on 9 July 2026, running on GPT-5.6. Both do the same essential thing, and both were aimed at ordinary staff rather than programmers: you state a goal, it connects to your files and applications, breaks the job into steps itself, works for hours unattended, and returns finished work — a completed workbook, a document set, a deck.
For a reliability report, that is the whole difference. The 2025 version of this idea could draft the narrative paragraph about the ice storm. The 2026 version pulls the outage export, matches customer counts against the customer information system, checks the device against current geographic information system topology, recomputes the threshold from five years of history, flags the sixty-one records with suspect cause codes, and puts the workbook on the engineer's desk in the format the commission accepts.
flowchart TD
A["Goal: close last month's reliability numbers"] --> B["Pull interruption records from the outage management system"]
A --> C["Pull customer counts from the customer information system"]
A --> D["Pull feeder and device topology from GIS"]
B --> E["Match records to devices and customers"]
C --> E
D --> E
E --> F["Recompute major event day threshold, IEEE 1366 method"]
F --> G["Build filing workbook and flag suspect cause codes"]
G --> H["Reliability engineer reviews flags and signs"]
Here is the actual instruction, in the words a reliability engineer would use: "Close June. Use the outage export in the reliability folder, customer counts from the June billing extract, and the current circuit map. Exclude major event days using our five-year threshold and show me the threshold you calculated. Build the workbook in the same format as May. List every interruption where the cause code and the crew's work order notes disagree, and every interruption longer than eight hours with no restoration note. Do not fill in anything you had to guess — leave it blank and tell me."
That last sentence is the one that separates a useful result from a dangerous one. The instruction to leave gaps visible rather than plausibly filled is what makes the output reviewable. Four hours later there is a workbook, a short memo listing the threshold and how it was derived, and a list of sixty-one records with disagreements. The engineer works the list, which is the part of the job that actually needs his judgement, and the tabs nobody could explain get rebuilt once, in the open, instead of being copied forward forever.
This is the part that is management, not software. Today you assign tasks: "pull the export," "check the cause codes," "update the workbook." To get value out of a goal-driven agent you have to be able to state the outcome and the standard it must meet — and most utilities have never written that down. The reliability report exists as a set of habits in one engineer's head.
So the first month is not automation. It is one afternoon in a room with the reliability engineer, the compliance analyst and the outage management system report writer, writing down what "closed" actually means: which export, which extract, which exclusion method, which format, what gets flagged, who signs. That document is worth having even if you never buy anything. It is also the document that makes the whole job transferable when the engineer retires, which in a lot of utilities is a nearer-term risk than anything on this page.
Still reading? Stop comparing — try CallSphere live.
CallSphere ships complete AI voice agents per industry — 14 tools for healthcare, 10 agents for real estate, 4 specialists for salons. See how it actually handles a call before you book a demo.
| Assumption | Value |
| Reliability engineer hours per close | 46 |
| GIS analyst hours, topology | 12 |
| Billing analyst hours, customer counts | 6 |
| Total hours per month | 64 |
| Hours per year | 768 |
| Fully loaded cost per hour | $82 |
| Annual cost of the monthly close | $62,976 |
| Hours per month after, review only | 16 |
| Hours saved per year | 576 |
| Value of hours saved | $47,232 |
| Seats, 3 people at $220 per month | $7,920 per year |
| One-time setup, 60 report-writer hours | $4,920 in year one |
Net in year one, on these assumptions: roughly $34,000, and a close that lands on day three instead of day six. But the hours are not the real prize. The real prize is that the disputed cause codes get worked every month instead of once a quarter, and cause coding is what drives your worst-performing circuit list, which is what drives where the capital goes.
The agent does not decide what counts as a major event day in a contested case. If a storm sits right at the threshold and the exclusion is going to be questioned by commission staff, that call belongs to the reliability engineer and, in some states, to counsel. The method is arithmetic; the defence of the method is testimony.
It also does not write the narrative for a bad month. When your duration index doubles because a transmission source outage dropped four substations at 4 p.m. on a Tuesday in August, the paragraph explaining that goes to the commission with the company's name on it. Draft it if you like, but the person who signs the filing rewrites it, because that paragraph is the one the staff attorney reads twice.
And it never touches the operational systems. Read the exports; do not let anything write back into the outage management system or the geographic information system. Reliability data is evidence. Evidence should only be edited by people who can be deposed about it.
Start with the export you already produce. Most utilities have a scheduled monthly extract and it is more than enough to prove the value. Direct connections into operational systems raise access questions your security group will rightly want to work through first, and you do not need to win that argument to get the first four months of benefit.
Then this helps more, not less, but it will be uncomfortable for a quarter. The first run will surface hundreds of disagreements between the code on the outage record and the note on the work order. That is not the agent being wrong. That is the backlog you have been rolling forward, showing itself all at once.
Regulators care about the method, the source data and who signs. Document the method, keep the exports, keep a record of what was flagged and how it was resolved, and have the same engineer sign it who signed it before. If anything, the audit trail gets better, because the assembly steps are now written down instead of living in one person's habits.
A closing note from the other end of the outage: interruption reports do not just generate workbooks, they generate calls — estimated restoration times, medical hardship customers, damage reports from people who saw a wire down. CallSphere builds AI voice and chat agents that answer phone lines and web chat, capture the caller's details and book follow-ups around the clock, which is a useful pressure valve on the night your duration index is being made.
Written by
Sagar Shankaran· Founder, CallSphere
LinkedInSagar Shankaran is the founder of CallSphere, where he builds production AI voice and chat agents deployed across healthcare, hospitality, real estate, and home services. He writes about agentic AI, LLM engineering, and shipping voice agents that handle real calls in production.
See how AI voice agents work for your industry. Live demo available -- no signup required.
How pest control service managers hand the monthly food-account trend packet to a 2026 work agent as a goal - and what has to change about assigning work.
The phased plan, insurance estimate, predetermination narrative and financing page, finished before the patient leaves. What the owner has to change to get it.
Why co-pack quotes take six days, and how 2026 agents that return finished work rebuild the packet — costed formula, freight, spec sheet — in two hours.
A 1/1 commercial submission packet costs an account manager nine hours, eight of them gathering. In 2026 you hand over the goal and review the finished packet.
Why per-seat AI pricing misfits utility work, when self-hosting an open model beats it for rate case data requests, and the staffing cost nobody budgets.
The Thursday production packet - prep list, vendor POs, staffing, rentals - built as one goal. Worked food-waste math and the habits an owner must change.
© 2026 CallSphere Inc. All rights reserved.
Made within San Francisco
Watch how CallSphere handles real customer calls, schedules appointments, and processes payments — live.
Try Live DemoBook a DemoCalculate Your ROI