Storms aren't won in hour three. They're won in hour thirty, when every crew is a human with a 16-hour clock, mutual assistance is arriving hungry and unfamiliar, and the dispatcher is making the same brutal call four hundred times: one more trouble call, or send them home? This is crew management from the control-center dispatcher's seat: 36 crews (native line, one-man service, tree, and two waves of mutual assistance) against 380 trouble orders, with hours-of-service, meals, fuel, materials, skill restrictions, and the relief wave that decides whether tomorrow exists. Watch the same storm hit the hour-16 wall without the math.
| Without | With GridCORTEX | Δ |
|---|
| Without | With GridCORTEX | Δ |
|---|
The storm has just passed. It is 06:00 at the dispatch desk of a fictional utility, and the board shows 380 trouble orders, meaning individual repair jobs, with 96,400 customers without power. The workforce is 36 crews: 14 local two-person line crews, 6 one-person service crews restricted by rule to small jobs such as reconnecting individual homes, 4 tree-clearing crews, and 12 borrowed crews from other utilities, called mutual assistance, arriving in two waves at noon and at midnight. The simulation runs 36 hours, into the second night. One hard constraint shapes everything: safety rules cap each crew at 16 working hours, and a crew that hits the limit must stop, wherever it is. Storms are lost when every crew hits that wall at the same time.
Five decisions come to the dispatcher for approval. At 06:18 the first is counterintuitive: do not send all 24 local crews out at once. Hold five crews back as a fresh relief wave starting at 18:00, enforce a hard stop at 16 hours with a 30-minute buffer to get home, and schedule meals at hour 6 and refueling at hour 9. Otherwise the entire fleet times out in the same 90-minute window tonight, and restoration stops. At 07:12 the second decision places three staging sites, NORTHGATE YARD, RIVERSIDE FAIRGROUNDS, and BAYSHORE LOT, stocked with meals, fuel, and materials such as 12 spare transformers, wire, and poles, positioned where the damage actually is. That cuts wasted driving, called dead mileage, by a modeled 62 percent. Late morning, the third decision briefs the incoming borrowed crews while they are still on the road: local construction standards, sector maps, radio channels, a local buddy crew, and a first job already assigned. The first visiting crew is working on a pole 45 minutes after arriving, instead of losing half a day in a parking lot.
The centerpiece arrives at 19:36. Crew L-07 has worked 14.2 hours and just finished a job. The queue wants to hand them a 3-hour transformer replacement 35 minutes away, which would end at 18.1 hours on their clock, a safety violation. The software's answer: give them a 25-minute reconnection job 6 minutes off their route home, releasing them at 15.3 hours, and give the transformer job to crew M-04, which has 4.9 hours left and is 15 minutes closer. The dispatcher makes roughly 400 calls like this every storm, normally on gut feel alone. At 22:30 the fifth decision plans the second night: release the held relief crews, send the midnight wave of borrowed crews straight to staged work areas, and cycle the day-one crews back after full 10-hour rests, staggered so field coverage never drops below 60 percent.
On the approved path, the second night works instead of stalling. By hour 20, field coverage holds at 64 percent and the overnight backlog burns down from 190 open jobs to 120. Rested crews return from 04:00. The promised restoration time is met at 12:00 on day two as the last circuits come back. The borrowed crews go home a full day early. The event ends with zero work-hour violations, zero safety incidents, every meal on time, and the storm review file already assembled from the system's decision log. Total customer time without power comes in about 41 percent below the old way, roughly 1.2 million customer-hours instead of 2.1 million; a customer-hour is one customer dark for one hour.
The conventional storm sends everyone out at 06:00, so every crew's 16-hour clock expires between 22:00 and 23:30: the hour-16 wall, eleven crews timing out within 90 minutes, and restoration flatlining overnight near 200 open jobs. Meals are a 40-minute drive each way, so half the fleet skips them; every transformer job includes a 50-minute round trip to the yard for parts. The borrowed crews sit 4.6 hours in a parking lot waiting for orientation, and two are turned back because their equipment does not match local standards. At 14.9 hours on the clock, a fatigued crew backs a bucket truck into a pole stub: a near miss, a damaged truck, and a 40-minute fleet-wide stand-down. On day two, everyone returns at 08:00 into one fuel line and a scramble for materials. The result: 3 work-hour violations plus union grievances, the promised restoration time slips 14 hours to 20:00 on day two, and the state utility commission opens an inquiry into the storm response. The core failure: no system tracks human limits, so the dispatcher improvises 400 judgment calls alone.
The change is treating crews as humans with limits, and logistics as math. The fatigue model staggers the crews' clocks at the start of the storm, so the hour-16 wall never forms (use case 3.4). The dispatch engine matches all 380 jobs to crew skills, truck equipment, travel time, and labor rules, including the route-home assignment that answers the one-more-call question with which job, not yes or no (use case 3.6). The mutual-assistance coordinator gets visiting crews from the parking lot to a pole in 45 minutes (use case 3.8). All five recommendations are approvals, not automation: the dispatcher approves each plan and crews confirm on the radio. The winning numbers: restoration promise met at 12:00 on day two, 14 hours faster; zero violations; zero incidents; customer time without power down 41 percent; wasted driving down 62 percent; and the borrowed crews released a day early, saving about $380,000.
| Measure | Without GridCORTEX | With GridCORTEX | Delta |
|---|---|---|---|
| Hour-16 wallwhat happens when many crews hit the 16-hour work limit at the same time and restoration stops | 11 crews out in 90 min | designed out | staggered clocks |
| HOS violationshours-of-service violations: times a crew was worked past the legal 16-hour safety limit | 3 + grievances | 0 | hard stops held |
| Fatigue near-missan exhausted crew's accident that almost hurt someone | 1: truck damaged | none | the reason the math exists |
| MA time to first jobhow long borrowed mutual-assistance crews waited between arriving and starting useful work | 4.6 hours | 45 min | onboarding done en route |
| One-man crew assignmentswhether one-person crews were sent only to jobs they are qualified and equipped to do | 2 sent to primary calls (turned back) | service/patrol only | skill rules enforced |
| Meals on timethe share of crews who actually got their scheduled meal breaks | ~55%: half skipped | 100% at staging | humans kept fueled |
| Dead mileagemiles driven that restore nothing, such as trips back to the yard for parts | baseline | −62% | supplies moved to the work |
| Restoration (ETR)the estimated time of restoration, the public promise of when the lights come back; D2 means day two | 20:00 D2: +14 hrs | 12:00 D2: met | 14 hours sooner |
| Customer-hourstotal outage suffering, counted as one customer dark for one hour | ~2.1M | ~1.2M | 41 percent less time dark |
| Overnight backlog burnwhether open repair jobs kept falling overnight, or froze when crews timed out | frozen ~200 orders | 190 → 120 | the second night worked |
| Crew utilizationthe share of paid crew hours spent actually repairing damage, rather than driving or waiting | 52% of paid hours on damage | 71% | same fleet, more grid fixed |
| MA releasewhen the borrowed mutual-assistance crews, paid by the day, were sent home | held an extra day | released a day early | about $380,000 saved |
| Storm review packetthe after-storm report; Relay is the system's decision log, which records every assignment as it happens | 3 weeks, from memory | Relay-traced, same week | regulator-ready |
| The dispatcher's nightthe roughly 400 assignment decisions one person makes per storm | 400 gut calls, alone | 400 computed calls, approved | the human stays in charge |
Fatigue in storm restoration is not an abstraction: it is a crew at hour fifteen working elevated on energized equipment and then driving home in the dark. The tool makes the time out visible hours before it arrives, so relief is scheduled rather than discovered, and nobody works past the limit because there was no one else to call.
Counted in units you already track:
Storm room hours come back to the EOC shift lead and the storm room staff who currently spend the event tracking people instead of directing restoration.
The numbers we need from you to run that formula:
| Cost driver | How it is calculated, from a rate you supply |
|---|---|
| Storm room labor | tracking hours avoided x your loaded EOC staff rate |
| Overtime premium | hours of avoidable overtime x your overtime premium rate, driven by relief that arrives on schedule instead of after a time out |
| Payroll and audit correction | post event audit and correction hours avoided x your loaded payroll and labor relations rate |
| Incident and claim exposure | your own average cost of a fatigue related vehicle or field incident x the reduction you assume, a number you set from your own incident history |
| Grievance and dispute cost | your own average cost to process a rest rule grievance x the number you believe scheduled relief prevents |
You pay for the GridCORTEX service, for integration with your OMS (outage management system) crew records and your timekeeping system, and for the work of encoding your actual rest rules, which are usually spread across multiple labor agreements and are rarely as simple as a single hour limit. That rules encoding is the real project cost, and it needs your labor relations people, not just IT.
Payback is usually driven by avoidable overtime and by storm room labor, since both come straight off your event cost reports. Incident and grievance avoidance are real but you should set those numbers yourself and keep them out of the base case.
The safety effect is mostly indirect and mostly about driving. Better sequencing removes crossing and backtracking miles during exactly the conditions where driving is most dangerous, at night, in weather, on roads with debris and downed conductors. There is a second effect that matters: a crew sent to a job its truck is equipped for is not improvising with the wrong equipment.
Counted in units you already track:
Windshield hours come back to the crews and planning hours come back to the dispatchers, and both are hours you are already paying for at storm rates.
The numbers we need from you to run that formula:
| Cost driver | How it is calculated, from a rate you supply |
|---|---|
| Crew productive time | windshield hours avoided x crew size x your loaded crew rate or the contracted mutual aid rate, whichever applies |
| Dispatcher labor | planning hours avoided x your loaded dispatcher rate |
| Fleet and fuel | miles avoided x your fleet cost per mile, applied across every truck in the event |
| Event duration | crew days removed from the event x your all in daily cost per crew, including lodging and per diem, which is where mutual aid gets expensive |
| Customer minutes | your own value per customer minute of interruption x the customer minutes restored earlier, a share you set from your own restoration curves |
You pay for the GridCORTEX optimization service, for integration into your OMS (outage management system) work queue and your automated vehicle location and crew qualification data, and for dispatcher training, because a dispatcher who does not trust the sequence will override it and you will get no benefit. Expect the crew qualification and truck equipment data to be the messiest input you own, and budget for cleaning it.
Payback is dominated by crew days removed from the event, especially contracted mutual aid crew days, because that is a rate you literally have an invoice for. Dispatcher labor is real but small next to it. Customer minutes are the largest number and the one to keep out of the base case.
A crew that has driven several hundred miles and then waits half a day is a fatigued crew starting late, and a crew released to work before it has absorbed your local rules is a crew operating on another utility's practices in your territory. Compressing orientation and getting assignments right at arrival is a safety control, not just a logistics improvement.
Counted in units you already track:
The largest block of hours returned is not yours, it is the arriving crews' idle time between arrival and first assignment, and you are paying for those hours at a contracted rate.
The numbers we need from you to run that formula:
| Cost driver | How it is calculated, from a rate you supply |
|---|---|
| Idle crew time | wait hours removed x personnel x the contracted rate you pay assisting crews, which you pay whether they are working or waiting |
| Coordinator labor | coordination hours avoided x your loaded coordinator rate, multiplied by the number of coordinators an activation consumes |
| Reconciliation and accounting | post event reconciliation hours avoided x your loaded accounting rate |
| Cost recovery exposure | your own history of disallowed or delayed storm cost recovery x the share you attribute to incomplete documentation, a number your regulatory accounting group already knows |
| Lodging and per diem | crew days removed from the event x your lodging and per diem cost per person per day |
You pay for the GridCORTEX coordination assistant, for integration into your OMS (outage management system) work queue, your cost and timekeeping systems, and your email, and for your coordinators to keep the orientation content current, since your safety rules, radio channels, and lodging arrangements change between events. The content upkeep is small but it is not zero, and stale packets are worse than none.
Payback is dominated by idle crew hours at the contracted assisting rate, because that is the largest and best documented number in an activation. Coordinator labor and reconciliation are real but secondary, and cost recovery exposure should be sized by your regulatory accounting group, not by us.
What is this, exactly? It is AI software: intelligent agents and models built and delivered by SoftServe, running on NVIDIA accelerated computing. It is not a hardware appliance and it does not replace the systems you run today. It deploys in your own cloud or on your premises, connects read-only to your existing systems, and recommends; your people approve every action, starting in shadow mode until it earns trust.
A decision support tool for the storm room: emergency operations center staff see a live board of each crew's accumulated hours, projected time-out, and the recommended relief crew and handoff time, with rest rules checked automatically. The demo above uses synthetic data; everything below describes what the real deployment needs from your organization.
| Your system | Typical products | How we connect |
|---|---|---|
| Field and crew systems | ARCOS crew scheduling, mobile workforce tools, vehicle location (AVL) | read-only API |
| Outage Management System (OMS) | GE PowerOn, Oracle NMS, ADMS outage module | read-only API |
| Time and labor system | UKG (Kronos), Workday, SAP time management | scheduled file export (CSV or CIM XML) |
| Weather and environment | National Weather Service feeds, commercial forecast services | read-only API |
| Geographic Information System (GIS) | Esri ArcGIS Utility Network, GE Smallworld | read-only API |
| Asset / work management (EAM/CMMS) | IBM Maximo, SAP PM, Oracle WAM | database replica refreshed nightly |
| Document and knowledge stores | SharePoint, safety briefing and orientation libraries | document upload |
Runs in your cloud account on GPU instances or an on-premises NVIDIA server, read-only through your existing data zone, with no link to dispatch or control systems. It starts in shadow mode replaying past storms; relief calls remain human decisions.
The Approve button you just clicked in the demo above is the real workflow. This is what it looks like on the screen of the emergency operations center shift lead in the GridCORTEX console:
Approving the relief flag does not block the crew in your OMS. GridCORTEX writes an advisory note to the crew record through the OMS API and alerts the dispatcher; your dispatch rules and the dispatcher decide the relief. Hard enforcement lives in your OMS, not in GridCORTEX.
The trigger is automatic from crew and time and labor feeds; no entry needed. If crew makeup changes in the field, the shift lead logs it in one click.
Runs on live OMS assignments and time and labor clock data, refreshed every few minutes; each card shows its as-of timestamp, and pilot replicas show their cadence too.
The GridCORTEX storm board beside the OMS; a crew within 4 hours of time-out pushes a mobile and Teams alert to the shift lead. The console runs in a browser beside your existing screens on day one; embedding into your own systems is a roadmap step once the read-only phase has earned trust. Approve, Modify, and Decline are all captured in an audit trail your compliance team can pull, and GridCORTEX never blocks or overrides anything in the systems you run today.
The fair question from any T&D ops leader: "We have an OMS, a workforce management system, AVL on every truck, and dispatchers who've run twenty storms, what's new here?" Here's the honest answer.
When someone asks "what did it actually calculate?", this is the list. In the simulation these factors drive the storyline; in a pilot they are computed from your OMS history, work rules, and mutual assistance agreements.
Presenter's one-liner: "Every crew is a 16-hour clock. The system staggered the clocks, put meals and transformers where the work was, got mutual assistance from the parking lot to a pole in 45 minutes, answered the one-more-call question four hundred times with math, and the second night was just a night shift. Same storm, fourteen hours faster, everyone home safe."