Utilities Management Software: A Build Guide for Utilities and Co-ops

Why operations software makes or breaks a utility or co-op

Picture a Tuesday night ice storm at a 28,000 meter electric cooperative. The dispatcher has Milsoft OMS open in one window, predicting fourteen device outages from inbound calls. The Landis+Gyr head end sits in a second browser tab holding four hundred last-gasp meter pings that the OMS cannot see because the AMI integration module was never purchased. Two member service reps are typing outage notes into a shared spreadsheet because the IVR overflow queue filled twenty minutes ago. The crews are working from printed switching orders, and the on-call engineer is texting them photos of the ArcGIS map from his kitchen table.

None of these tools is bad. NISC iVUE, SEDC, Daffron and Tyler for municipal utilities are all competent at their center of gravity, which is billing and accounting. Milsoft is good at outage prediction. Survalent and other SCADA platforms are good at the control room. The failure is at the edges, where the vendors expect a human in a swivel chair to move data between islands, and each bridge across those islands is sold as a separate per-meter module on the vendor's timeline.

In the utility operations we have audited, that glue work quietly consumes one to two full-time positions of re-keying and reconciliation, and every major storm adds overtime spent on data entry the systems should have exchanged on their own. For an operator with a real budget, the question is not whether the leak exists. It is whether to keep paying it monthly or fix it once.

Problem one: outage calls, AMI pings and SCADA live in three different rooms

A member on Route 9 calls in lights out at 2 a.m. The dispatcher checks the OMS, which predicts a blown tap fuse from three calls. What the dispatcher cannot see is that a recloser locked out eight minutes earlier in Survalent, and that 412 meters already sent last-gasp pings to the head end. Three signals, three screens, one tired human doing the correlation by hand, and a crew dispatched to the wrong device.

Off-the-shelf cannot fix this because every vendor bridges only to its own island. Milsoft and NISC both sell AMI integration, but it polls on a schedule, carries per-meter fees, and works best inside their own suite. SCADA speaks DNP3 to the control room, not to member services.

A custom build puts one event pipeline in the middle: head-end events over MultiSpeak or the meter vendor's REST API, IVR call records, and read-only SCADA status points from a historian feed, all normalized into a single outage stream keyed to your connectivity model, the transformer-to-meter mapping exported from GIS. The engine rolls calls and pings up to the likely protective device, the dispatcher confirms with one click, and the confirmed outage flows back to the OMS and out to affected members by text. Intake is queue-based, so a 50x call spike during a storm gets absorbed instead of busy signals.

Problem two: work orders die between the field and the billing system

A staking technician designs a line extension in ArcGIS or Futura and prints the staking sheet. The crew builds it, marks changes in pen, and the paper rides in a truck for two weeks. Someone in the office then re-keys material usage into iVUE inventory, the as-built edits to GIS wait months in a pile, and billing for the new service starts late. Worst of all, the connectivity model your outage prediction depends on is now stale.

The CIS work order modules assume a desk and a network connection. The GIS vendors' field apps capture geometry but never write billing determinants or inventory transactions. Nobody owns the loop end to end.

A custom field application does: offline-first on the truck tablet, with assignment, barcode material capture, photos and GPS-stamped as-builts. When the truck gets signal, the sync engine posts material issues to CIS inventory over MultiSpeak, queues the GIS edit for engineering review, and flips the service to billable the same day the crew closes the order. One capture, three systems updated, zero re-keying.

Problem three: the billing engine cannot price the rates your board keeps approving

The board approves a time-of-use EV rate and a solar buyback tariff. The CIS vendor quotes the rate change as a development request measured in months, and meanwhile the interval data that could power those rates sits unused in the head end. A prepaid metering pilot stalls for the same reason. Legacy rating engines were built for monthly kWh blocks, and every new determinant means waiting in a queue behind a thousand other utilities.

The custom answer is a rating sidecar, not a CIS replacement. It pulls interval reads nightly from the head end, computes time-of-use, demand and net metering determinants, and writes them back into the CIS as billing line items, so bills still print from iVUE and the general ledger never notices. Rates are configured as data rather than code: the board approves in March, you bill on it in April.

Problem four: members learn about outages from Facebook before they hear from you

During any real event, the co-op's Facebook page fills with guesses and anger while member services drowns. SmartHub shows a map, but proactive texting, crew status and honest ETAs are extra modules tied to one vendor's stack, and the messages are generic because the app has no idea what the crews are actually doing.

A custom notification service subscribes to the same outage event stream described above. Members get a first text when the outage is confirmed, an update when a crew is assigned, and a restoration message triggered by power-restore pings from their own meters, so the message reflects AMI truth rather than dispatcher optimism. Every text that lands is a call that never rings, and you can measure the deflection week by week.

Problem five: reliability reporting is a two-week spreadsheet project

Every quarter an engineer exports OMS events to Excel, hand-scrubs duplicates and phantom restorations, and computes SAIDI, SAIFI and CAIDI for the state commission and RUS Form 7. The OMS reporting module only counts events the OMS saw, so anything handled by phone or paper is invisible, and the major event day exclusions under the IEEE 1366 beta method are done by hand where an auditor can and will question them.

With a unified outage stream feeding a small data warehouse, every event carries start time, restore time, cause code and affected customer count from the moment it happens. Indices compute continuously, major event days flag automatically, and the Form 7 and commission exports are one click with every number traceable to source events. The two-week project becomes a ten-minute review.

What custom utility operations software costs and how long it takes

Across 2,000+ delivered projects at Digital Heroes, the pattern in this category is consistent. A focused first release, typically the unified outage intake with member notifications, or the offline field work order app against your existing CIS, runs $60,000 to $130,000 and ships in 12 to 16 weeks. A full operations platform that adds the rating sidecar, GIS write-back and reliability warehouse lands between $150,000 and $400,000, phased over 6 to 12 months so each phase pays for itself before the next starts.

What pushes cost up in utilities specifically: every additional integration endpoint, since a second head end or a SCADA historian is real scope, not a checkbox; MultiSpeak version mismatches between your CIS and OMS; offline field requirements in territory with no coverage; storm-load engineering, because a system that works on a calm day and falls over at 50x event volume is worthless; and connectivity model cleanup, since outage prediction is only as good as your transformer-to-meter data.

Build vs buy: when off-the-shelf is genuinely right

Stay on the shelf if you are under roughly 10,000 meters, run standard residential rates, live entirely inside one vendor suite and have no one internally who wants to own software. At that scale the per-meter module fees are cheaper than any build, and the vendor's roadmap will eventually cover most of your gaps.

Build when the signals stack up: staff re-keying the same order into three systems, rate change orders quoted in quarters, module fees compounding every renewal, storm response that depends on one dispatcher's memory, and a board approving programs your CIS cannot price. Our position after building in this category: never rip out the CIS at this budget. iVUE, SEDC or Daffron should remain the system of record for money and members. Build the custom layers where the crews and the members actually feel the pain, and let the legacy core do the one thing it does well.

How to choose a developer for utility operations software

First, test domain data models. Ask the firm to whiteboard how a phone call rolls up through a transformer and a tap fuse to a recloser, and what happens to that prediction when the connectivity model is wrong. A team that cannot explain your feeder topology will model your outage data as a flat ticket queue, and you will find out during a storm.

Second, demand named integration experience. MultiSpeak versions, head-end APIs from Itron, Landis+Gyr or Sensus, and at least one project that exchanged live data with NISC, SEDC or Milsoft. References should be utilities, not lookalike industries.

Third, probe storm-mode engineering. Ask how the system behaves at 50x normal event volume, what the field app does after six hours offline, and what degrades gracefully when the head end itself is down. The honest answers are architectural, not reassuring.

Fourth, settle compliance and ownership before the kickoff. Full work-for-hire code ownership in the contract, a developer who knows to keep custom systems outside the NERC CIP electronic security perimeter with one-way read-only feeds, and enough RUS and FERC accounting literacy that work order costing lands in the right accounts. Any firm that shrugs at those three acronyms is learning your industry on your invoice.