A line crew sits idle across town while another truck drives to a fault that a third caller just reported for the fifth time. If that sounds familiar, you have probably already looked at custom utilities software. For co-ops, municipal districts and small private operators, the problem is rarely a shortage of effort. It is that faults, crews and customer calls live in different places and nobody sees all of them at once.
This article walks through the outage-to-restoration process step by step and shows where software removes delay. It also compares custom builds with buying a suite, so you can decide what fits your size.
Why custom utilities software keeps coming up for small and mid-size operators
Smaller utilities tend to outgrow spreadsheets before they can justify an enterprise platform. A water district with 8,000 connections or an electric co-op with a few thousand meters still has to handle storms, main breaks, regulator questions and board reports. The workload is real, but the budget and IT staff are not those of a large investor-owned carrier.
Off-the-shelf utility suites are usually priced and scoped for large operators. You often pay for modules you will never switch on, and implementation can take many months. Generic tools such as shared spreadsheets, ticketing apps and general field service products are cheap, but they do not understand assets, feeders, service territories or restoration reporting.
Custom utilities software sits between the two. You build or customise only the parts of the workflow that hurt, and you connect them to what you already run. Our utilities software page lists the ready-made modules we customise for this sector.
The costly problem: manual outage dispatch
Most delays in restoration do not come from the repair. They come from the minutes and hours before a crew is on the road with the right information. In a manual setup, the pattern is usually the same:
- Faults arrive through several channels. Phone calls, texts to a staff mobile, and walk-ins at the counter all get noted differently, on a whiteboard, a notepad or a spreadsheet tab.
- Crew assignment lives in someone's head. The dispatcher remembers who is where and who holds which certification. When that person is off sick or the storm is big, duplicate trips and idle crews follow.
- Customers have no status to check. With no estimated restoration time, people call again. Each call interrupts the dispatcher, which slows dispatch further.
- Records are rebuilt after the fact. Restoration times get reconstructed from memory and texts when a regulator or board asks for them.
The fix is not a bigger whiteboard. It is a single record per fault that moves through logging, dispatch, customer notice and closure without being retyped. That is what outage management software does, and it is the core of any utility outage management software project.
Step 1: Log every fault once, at the source
Start with intake. Every fault, whichever channel it came through, should become one structured record the moment someone hears about it.
What the fault form should capture
- Location, either an address, a map pin or a feeder/zone
- The affected asset ID, if known
- Estimated number of customers affected
- Hazard flags, such as downed line, gas smell, flooding or road blockage
- Source of the report and the time received
Keep the form short. A call-taker in the middle of a storm will skip fields that feel optional, so make only location and fault type mandatory and let the rest be added during dispatch.
Link faults to the asset register
When a fault references an asset ID, the dispatcher should immediately see that asset's history: age, last inspection, previous faults and parts used. This is where a network asset register pays off. A transformer with three failures in 18 months is a replacement candidate, not a fourth repair, and you only see that if faults and assets are connected.
De-duplicate calls automatically
During a real outage, twenty calls may describe one blown fuse. The system should match new reports to open faults by location or feeder and attach them to the existing record, incrementing the affected-customer count. The dispatcher sees one job with twenty reports instead of twenty jobs.
Step 2: Dispatch the right crew from one screen
Once the fault is logged, dispatch becomes a matching problem: which available crew can reach it soonest and has the skills and equipment to fix it? This is the core of utility field service software.
- Rank crews by proximity and skill. Use GPS positions from phones or vehicle trackers, and filter by certification, such as high-voltage work or confined-space entry.
- Send a complete work order. Include the asset details, hazard flags, customer count, access notes and any photo requirements for completion, such as before and after shots.
- Track acknowledgements. A job that nobody accepts within a set window, say 10 minutes for a priority fault, should escalate to the next crew or to a supervisor.
- Show everything on one screen. Open faults, crew locations, job status and hazards should be visible together, so the dispatcher is not switching between a map, a spreadsheet and a phone.
If you already use a generic field tool, you may not need to replace it. Our utilities field service integration connects dispatch to technicians' devices, and our post on when to build beyond ServiceTitan and Jobber explains where generic tools stop fitting utility work.
Step 3: Notify customers automatically
Most repeat calls are customers asking the same question: do you know, and when will it be fixed? Answer it before they ask.
- Confirmation message. Once a fault is logged and linked to affected accounts or areas, send an SMS or email saying the outage is known and a crew is being assigned.
- Estimated restoration time. Let the dispatcher or crew update the estimate, and push changes out. An honest "estimate revised to 6 p.m." beats silence.
- Self-service status. A portal or status page lets customers check progress without phoning. This ties in with a customer self-service module if you already offer account access.
- Restoration confirmation. When the crew closes the job, send a follow-up and invite customers to report if their power or water is still off. That catches nested outages that a single repair did not clear.
Be careful with promises. If your estimates are routinely wrong, customers will stop trusting the messages. Start with broad windows and tighten them as your data improves.
Step 4: Track restoration and feed compliance reporting
If every status change is timestamped as it happens, the audit trail builds itself. You will have the time reported, time dispatched, time crew arrived and time restored for each fault, without anyone reconstructing it later.
What to record per fault
- Reported, assigned, accepted, on site and restored timestamps
- Cause code and asset affected
- Customers affected and duration
- Photos and technician notes
From those records you can export reliability measures such as average outage duration and frequency without rebuilding them in Excel each quarter. Exactly which metrics your state commission or board expects varies, so confirm the definitions with your regulator before you configure the reports. A dedicated compliance reporting module formats the data into the layouts you submit, which is the heart of utility compliance reporting software.
The side benefit is internal. Boards and councils respond well to a clear picture of where outages come from, and the same data tells you which feeders or assets to fix first.
What a custom build looks like versus buying a suite
There is no single right answer. The table below shows how the main options typically compare for a small or mid-size operator.
| Factor | Spreadsheets and generic tools | Enterprise utility suite | Custom or customised modules |
|---|---|---|---|
| Upfront cost | Low | Often high, with licence and implementation fees | Moderate, scaled to the modules you choose |
| Fit to your workflow | Poor for assets and reporting | Broad, but you adapt to it | Built around your crews and fault types |
| Time to first use | Immediate | Often many months | Weeks to a few months for a first module |
| Scaling to new modules | Manual and fragile | Available, but priced as bundles | Add billing or field service when ready |
| Source code ownership | Not applicable | Vendor owns it | Yours under the Own model |
Timelines and costs vary a lot by scope, integrations and data migration, so treat these as typical patterns, not quotes.
Three ways to engage
- Own: a one-time fee, and you receive the full source code.
- Host: a monthly subscription where we run and maintain the system.
- Revenue Share: no upfront cost, with a monthly base operational cost plus a share of the revenue the software generates. This tends to suit software that bills customers or earns fees, so it may not fit a purely operational outage tool.
Our guide to what custom software costs to maintain after launch is worth reading before you choose, because ongoing support is part of the real price under any model.
Start narrow, then add
You do not need to buy everything at once. Begin with outage management and the network asset register, because they produce the data other modules need. Add meter reading and billing, field service or compliance later, once the first module is in daily use. That also covers the billing question: utility billing software custom to your tariffs can be added when you are ready, and outage records can link to customer accounts through APIs or scheduled exports without replacing your current billing system.
How to get started
- Map your current process on one page. Write down every step from the first report of a fault to the restoration message, including who does what and where it is recorded. Mark the points where information is retyped or lost.
- Count your volumes. Note how many faults you handle in a normal month and in your worst storm, how many crews you dispatch, and what reports you owe and to whom.
- Get a rough range first. The quote calculator gives an instant estimate for the modules you choose, which helps you set a budget before any conversation.
- Pick an engagement model. If you are unsure whether to own the code or have us host it, the model selector narrows it down.
- Run discovery and read the proposal. We start with a free AI-assisted discovery session and follow it with a written proposal.
- Test before you commit. You get a working sandbox. Have your dispatchers log a few real past faults in it, assign crews and send test notices. Their feedback decides whether it goes to production launch.
If your dispatch process is the bottleneck, one well-scoped module can remove most of the delay. Map the process this week, run the numbers through the calculator, and bring the one-page map to the discovery session.
Frequently asked questions
What is custom utilities software?
Custom utilities software is a system built around a utility's specific workflows, such as outage management, meter billing, asset registers and regulatory reporting. It differs from generic tools because it matches how your crews, assets and customers actually operate.
How much does custom utilities software cost for a small utility?
Cost depends on scope, with a single module such as outage management usually much cheaper than a full suite. Use our quote calculator at /quote-calculator for an instant estimate, then confirm it in a written proposal.
Can custom outage management software integrate with existing billing systems?
Yes. Outage records can be linked to customer accounts and asset data through APIs or scheduled exports, so you do not need to replace your billing system to improve dispatch.
Should a small utility build or buy outage management software?
Buy if a ready-made product covers about 80% of your process. Build or customise if your fault types, crew structure or regulatory reporting are unusual, and you can own the source code under the Own model.
