Selling Into Energy and Utilities: Regulatory Cycles, Asset Risk and Why Your Pilot Takes Eleven Months

A head of asset management at a distribution network is not really buying software. He is buying a defensible answer to a question he will be asked in three years by someone holding a spreadsheet and a regulatory determination.

That is the whole thing. If you understand that one sentence, most of the weird behaviour you see in these deals stops being weird. The stalled pilot, the business case that gets rewritten by a team you never met, the champion who loves you in April and goes silent in September — none of that is a buying signal problem. It is a calendar problem and a risk problem, and both of them belong to the buyer, not to you.

I have sold inside AWS and Dell, and I have built and exited four businesses. Energy and utilities is the sector where the gap between what a rep thinks is happening and what is actually happening is widest. Reps run their standard SaaS motion at a network operator and then complain the deal is slow. It is not slow. It is running at exactly the speed the regulatory regime allows, and you turned up at the wrong point in it.

The asset stays. You are a rounding error on its life.

Start here. The kit your buyer is responsible for — transformers, switchgear, overhead lines, cable, ring main units, primary and secondary substations — has a design life measured in decades. Some of what is energised right now was installed before your buyer was born. His job is to keep it safe and available for another twenty years or more, and to replace it in an order he can justify.

Everything follows from that.

He cannot rip and replace. He cannot "move fast and break things" because the thing that breaks is a hospital's supply or a lineman's hand. He cannot buy a tool that generates a recommendation he is not able to explain to a regulator, a coroner or a court. And he cannot spend money that has not been allowed.

That last one is the part most sellers never internalise. In a regulated network, the money is not the company's money in the way it is at a normal enterprise. Revenue is set by a regulator through a rate case in the US or a price control period in the UK, and the operator earns a return on the assets it has put in the ground — the regulatory asset base. Spending that sits outside the approved envelope has to be justified after the fact, and if it is judged imprudent, the operator eats it. So a head of asset management does not think "do I want this?" He thinks "is this inside the plan, and if it is not, what does it displace?"

You are not competing with another vendor. You are competing with a pole replacement programme.

Who actually holds budget

The org chart is a poor guide here. Four groups matter, and only one of them is likely to be on your first call.

Asset management. This is your economic buyer in most cases. Titles vary: head of asset management, asset strategy manager, network strategy, sometimes "asset policy". They own the investment plan — which assets get replaced, refurbished, monitored or run to failure, and in what order. They think in criticality, condition and consequence. They are usually engineers by training and they are unusually literate about statistics, which means bad methodology in your product gets caught fast.

Regulation and commercial. These are the people who build the submission to the regulator. They decide whether your product shows up as capex, as opex, as part of a totex allowance, or in an innovation funding pot. They are not on your calls and they will read your business case. Write it for them, not for your champion.

Operations and control. The control room and field ops decide whether the thing is workable. If your product implies an engineer does something differently at three in the morning during a storm, ops has a veto and will use it. Ops also owns the reason your integration is hard: the SCADA system, the ADMS, the historian, the GIS, the works management system. None of those were built to be integrated with.

IT, security and procurement. Security is a real gate, not a checkbox, particularly anywhere near operational technology. In the US that means NERC CIP conversations for anything touching bulk electric system assets; everywhere it means someone will ask hard questions about what data leaves the estate and what direction traffic flows. Procurement then applies a framework, a competitive process and a set of terms that were written for buying cable drums.

If your deal has one contact in it, your deal is not real. The single strongest qualification question in this sector is not about budget. It is "who else has to be comfortable with this before it can be funded, and have they seen it?" I go deeper on how to sequence those questions in the twenty-five minute discovery playbook for network and asset buyers, because the sequence matters more here than in almost any other vertical.

The four risks your buyer is actually managing

When you pitch efficiency, you are speaking a language your buyer does not get graded in. He gets graded on risk. There are four, and every serious conversation maps to one of them.

Safety

Public safety and workforce safety. A failed asset that injures someone is career-ending and licence-threatening. This risk outranks everything, including cost. If your product reduces the number of times a person has to climb a pole, go into a substation or stand next to energised kit, say that first and say it plainly.

Supply interruption

Customers off supply. The regulator measures it and attaches money to it. In the UK the language is customer interruptions and customer minutes lost — CI and CML. In the US you will hear SAIDI, SAIFI and CAIDI. These are not vanity metrics; they are incentive mechanisms, which means performance against them moves allowed revenue. If your product can be tied to a reduction in unplanned outages on a specific class of asset, you are speaking directly to a number your buyer's boss is measured on.

Regulatory and compliance risk

The risk of not being able to justify the decision later. This is the quiet one and it is where most software actually sells. A head of asset management who intervenes on an asset that had years of life left has wasted money. One who does not intervene on an asset that then fails catastrophically has a much bigger problem. What he wants is an auditable trail showing the decision was reasonable with the information available. That is a product benefit. Nobody writes it on a slide.

Asset failure and whole-life cost

The engineering core. Condition, criticality, probability of failure, consequence of failure, health indices, intervention timing. The buyer is trying to spend the smallest amount of money at the latest defensible moment across an enormous population of assets with patchy data.

Notice what is not on this list: headcount reduction, seat licences, user adoption, time-to-value. Those are your metrics. They are not his.

The buying window belongs to the regulator, not to your quarter

Here is the structural thing that ruins forecasts.

A regulated network operates in multi-year investment periods. Before each one, there is a long submission process — building the plan, justifying it, negotiating it, having it determined. During the period, the operator delivers against that plan and reports on it. Near the end, the whole cycle starts again.

Where you land in that cycle changes what kind of deal is even possible.

If you arrive while the business plan is being written, you are not selling a product. You are selling a line in a submission. This is the highest-leverage moment in the entire cycle and almost nobody sells into it deliberately. Your champion's problem is that he has to justify a category of spend to a regulator, and evidence helps him. A vendor who shows up with a credible method, a reference from a comparable network and a willingness to be a named part of the plan is enormously useful right then. The contract may be a long way off. The commitment is not.

If you arrive early in a delivery period, budget exists and is allocated. Your job is displacement or expansion of something already planned. Deals here are real but the question is always "what does this replace?"

If you arrive late in a period, when the operator is scrambling to deliver committed outputs before the clock runs out, you get one of two responses. Either total disinterest, because nobody is starting anything new, or unexpected urgency, because something in the plan is failing and they need a fix that can be delivered inside the window.

So the first thing I would establish about any utility account, before I write a single line of outreach, is where they sit in their cycle and when the next submission is being drafted. That is public information. Regulators publish determinations, operators publish business plans, and trade press covers all of it. Reading one of those documents will teach you more about an account than a year of LinkedIn scrolling.

Then time the call. Prospecting a network operator in the month the plan is being finalised is a different conversation from prospecting them eighteen months earlier, and your opener should reflect it. I wrote a thirty-second cold call script for a head of asset management that leans on exactly this — naming the period they are in is the fastest way to prove you are not a generic SaaS rep working an industry list.

What "pilot" means here, and why eleven months is normal

In most software sales, a pilot is a two-week trial with a handful of users and a Slack channel. In a network, a pilot is a supervised trial on a defined, non-critical piece of the network, and it carries its own risk assessment.

Walk through what actually has to happen.

Someone has to choose a feeder or a substation group where a failure of your product does not create a customer or safety event. That choice has to be signed off. Data has to be extracted from systems that were not designed to export it, which means a person's time, which means it competes with that person's other work. Security has to assess anything touching the operational estate. If hardware is involved, it needs approval for installation, an outage or a live-working method statement, and a field crew whose calendar is booked around the network's own seasonal rhythms.

Then the trial has to run long enough to mean something. Asset behaviour is seasonal. Load peaks in winter or summer depending on where you are. Faults cluster with weather. A trial that runs for six weeks in mild conditions has told your buyer almost nothing about what happens in a storm. Engineers know this. They will not sign off on an evidence base they know is thin, because the evidence base is the thing that gets read later by people who were not in the room.

So eleven months is not a failure of your sales process. It is the number of months required to get through a procurement gate, a security review, a data extract, an installation window and at least one meaningful season. When a rep tells me their utility pilot has been running since last spring, my first question is not "how do we speed it up?" It is "who is writing the evaluation, what does it have to prove, and is that person in your forecast conversations?"

What you can control is scope. A tight pilot with a pre-agreed success definition, on a named set of assets, with a named evaluator and a written statement of what result triggers what next step, will finish. A vague pilot will drift until the champion changes role.

The vocabulary test

You will be sorted into insider or outsider within about two minutes, and it happens on language.

Things that mark you as an outsider: calling everything "the grid" when the buyer means their distribution network specifically. Saying "power lines" instead of overhead lines or circuits. Talking about "downtime" instead of outages or interruptions. Using "customers" to mean the utility's staff. Referring to a substation as a "site" throughout. Not knowing the difference between transmission and distribution, or between a network operator and a supplier — the company that sends a household its bill is frequently not the company that owns the wires.

Things that mark you as credible: talking about assets by class and voltage level. Knowing that criticality and condition are different axes and that intervention decisions need both. Understanding that a health index is a model output, not a measurement, and that your buyer knows its limitations better than you do. Asking about their data quality without implying it is bad — every network has gaps in asset registers, and the ones who admit it are being honest, not disorganised.

And never, ever use the word "disrupt" in a room where people are responsible for keeping supply on.

The demo is where this shows up hardest, because the temptation is to show the pretty map and the risk score. What an asset engineer wants to know is what is behind the score, what happens when the input data is missing, and how the output slots into a decision he already has to make. I broke down that whole flow in the demo script for selling asset risk analytics to a distribution network, including the questions that will get asked about methodology and how to answer them without bluffing.

Write the business case for the person who was not in the room

Your champion will not present your deck. He will translate it into an internal paper that goes to an investment committee, and possibly into language that ends up in a regulatory submission.

So give him the raw material in a form that survives translation. That means: what problem, on which assets, evidenced how. What intervention changes as a result. What that is worth against a named risk — safety, interruptions, deferred capex, compliance. What it costs across the full period, not annually. What the do-nothing option looks like. And what could go wrong with the proposal, stated by you before someone else states it for you.

That last one feels counterintuitive to sellers and it is the single most effective thing you can do. A network buyer trusts a vendor who names the limitations of their own product, because he is going to find them anyway and he has to defend the decision either way. Handing him the counterargument in advance makes him look thorough. It makes you look like an engineer.

And stop asking for the close on your timeline. "Can we get this signed by end of quarter" tells your buyer you do not understand his world. "What has to be true for this to sit inside the next investment period, and who needs to see it before the plan is drafted" tells him you do.

What I would do next

If I were picking up an energy and utilities patch tomorrow, I would spend the first week reading one regulator determination and two operator business plans end to end, and I would build my account list around where each one sits in its cycle. Then I would rehearse the conversation until the vocabulary was automatic, because you get one shot at sounding like an insider and you cannot look up "totex" mid-call. That is what we built DrillCall for — running the same call over and over against a buyer who pushes back the way a head of asset management actually pushes back, so the first time you say it out loud is not the first time it matters.

The deals in this sector are large, they are sticky, and the competition is mostly people who never bothered to learn how the money works. That is a good place to be selling.