It isn't one company. It's several, and no system sees them together.
Field operations, market purchasing, billing against windows you can't miss, regulated customer service, emergency response. Every front has its own tool and none of them share information with the next. Understanding what's happening with a single customer means cross-checking data by hand.
Where it hurts in a utility
Six businesses operating under one legal entity
Managing crews, field work, inventory, tools and meters. Purchasing in a market with moving prices. Mass billing against regulatory windows. Customer service with mandatory response times. Emergency management. Continuous regulatory compliance.
Each one of those fronts would be a complete company in any other industry. Here they coexist, compete for the same resources, and share a single P&L.
The tools don't talk to each other and the customer ends up in pieces
A user has consumption in one system, billing in another, complaints in a third, service orders in a fourth. To answer a simple question about that user, someone has to cross-check four sources.
The cost isn't just the time. It's that decisions depending on that complete view get made without it, and that data quality degrades with every manual cross-check. Any model built on top inherits that degradation.
Buying badly compromises the business, not the quarter
Buying at the wrong price, in the wrong quantity, or not selling enough. With prices moving on the exchange, regulated tariffs by segment and a commercial margin that's already tight, a purchasing error doesn't get corrected the following month.
And the quality of that decision depends on how well demand gets anticipated. A forecast off by several percentage points isn't a technical accuracy problem, it's direct financial exposure.
Regulatory non-compliance is an existential risk
Response times, service restoration, answers to formal customer petitions, reports to the regulator. All with deadlines that don't accept explanations.
And oversight has reached a point where sustaining reporting manually is no longer viable. Not for lack of people, but because the frequency and detail required exceed what a manual process can sustain without error.
Customer service is a permanent front
Complaints, claims, formal petitions. A good part over billing, and a good part of those over market variations the end user has no reason to understand.
It's a volume that doesn't drop, with regulated response times, and where most cases get resolved with information that's already in some system. It just has to be found.
OPEX is structural, not a discipline problem
Equipment, tools, materials, field crews, installation, metering, maintenance. The cost of operating doesn't come down by tightening, because it doesn't come from inefficiency but from the nature of the business.
What can come down is spending where it adds nothing: repeated field visits, avoidable trips, rework from incomplete information. That doesn't show up in any report because seeing it requires cross-checking systems that don't cross-check.
What we've done in utilities
Our experience in the sector doesn't come from having been a vendor to a utility. It comes from having operated inside one.
Pipe Beltrán, cofounder of Findders, was VP of Product and VP of AI & Data at an energy retailer. The projects he ran there used the same methods we apply with clients today: an energy forecasting model that went from 8.5% to 1.79% MAPE, a commercial funnel that dropped from 11 days to under 24 hours, and AI adoption across more than 60% of non-technical roles, freeing over 1,400 hours a month.
That means two things. That the problems above didn't come out of an industry report, but out of having lived them with responsibility for the outcome. And that we know the difference between what looks good in a presentation and what survives the regulatory committee, the audit and the field team.
The cases that follow are from other sectors. They're here because the mechanism repeats, even when the context changes.
Related cases
This selection doesn't include a metric from this sector
We publish only the projects with the most representative results, not everything we've worked on. We've also implemented these use cases in your industry:
Same use case, also applied in this sector
95% of leads received no contact on day one. High-value prospects were walking to competitors.
From 15 days to less than 24 hours
View full case →No visibility into AI maturity by area. Traditional diagnostics took weeks and ended as a PDF no one acted on.
+3,000 people assessed in less than 2 weeks
View full case →They knew automation was possible, but not which processes or in what order. Internal diagnostics were biased by office politics.
+2,000 automation initiatives identified and prioritized
View full case →34% of penalty alerts were false positives. Settlement errors were caught too late.
False positives reduced from 34% to 0.5%
View full case →Executives made decisions with 1–2 weeks of lag. Consolidating a single report took 7 to 14 days.
From 1-2 weeks to 1 hour for report generation
View full case →Where to start
Almost always, with The Brain.
In utilities the diagnostic isn't a formality. It's where you decide which of six competing fronts to attack first, and with what return. It comes with the prioritized map and a business case per initiative.
There's an additional reason in this sector: when the investment has to hold up in front of a committee, the board or eventually the regulator, a documented business case isn't an extra. It's what makes the conversation possible.
If the front is already prioritized, The Muscle.
Demand forecasting, anomaly detection in metering, consolidation of information across systems that don't talk to each other, automating customer service over information that already exists. On the systems you have, without requiring you to replace them first.
If the challenge is getting the organization to adopt, The Program.
It's where utilities lose the most value: the tool arrives, and the field keeps using its paper form. Enablement by role and by area, not generic training.
And don't automate this
These are the things we consistently do NOT recommend automating in utilities, and in some cases refuse to build:
Executing purchasing decisions.
The system can forecast, simulate scenarios, quantify exposure and recommend. Buying is decided and approved by a person. A purchasing error in this sector doesn't get corrected the following month, and no model should have that authority.
Interpreting regulatory changes.
A system can monitor that a new ruling came out, extract what changed and alert whoever it applies to. Interpreting what it means for your operation, and anticipating how the regulator will read it, is human judgment. Regulation is rarely unambiguous, and that's where the risk is.
Financial decisions.
Consolidating, projecting and modeling scenarios, yes. Deciding on hedging, exposure or cost structure, no.
Strategic decisions.
A system that decides without context on the market, the relationship with the regulator and real operational capacity produces decisions that look good on a dashboard.
If what's hurting you is on this list, we'll tell you before charging you a cent.
What people ask us
This industry is very complex. It's hard for an outsider to understand how it actually works
True, and it's the reason many technology projects in utilities fail: they get designed around how someone thinks the business works.
Our advantage here isn't having read about the sector. It's having operated inside an energy retailer with responsibility for results, and knowing first-hand why billing has the windows it has, why a field job gets repeated, and what happens when a report to the regulator goes out late.
Even so, every company operates differently. The diagnostic exists to understand yours, not to assume it's the same as the last one.
A serious mistake with AI could cost us the business
Agreed, and that's where the design starts.
No system we build executes purchasing decisions, closes billing or responds to the regulator on its own. It prepares, calculates, alerts and leaves things ready. The decision stays where it belongs.
The technical pattern is conservative too: run in parallel to the current process before replacing it, compare results against the human process for as long as your team needs to trust it, and read without writing while it's being validated. By the time the system starts operating, there's already evidence of how it behaves in your real operation.
And where the risk is existential, the recommendation is usually not to automate. It's on the list above.
We have our own engineering team. We'd rather do it internally
That's a reasonable position and sometimes it's the right one. It's worth looking at with the sector data in hand.
Utilities have a structural difficulty sustaining data and AI teams: they compete for that talent against technology companies, inside a regulated cost structure. It isn't a problem of intent or capability, it's the labor market. That's why industry analysis recommends hybrid models rather than building everything in-house.
What works in practice: your team knows the systems, the regulation and the operation. We bring the implementation of this specific kind of system, and what stays behind is documented so they can maintain it. We don't work in parallel to your team, we work with it.
And if your team has the capacity and the time window, build it yourselves. We'd tell you so.
Which of these is your case?
Fifteen minutes to review which of the six fronts is costing the most and tell you whether there's something worth tackling first. If the answer is no, we'll tell you that too.
Let's talk for 15 minutes