Energy / Utilities · Demo Call
The Energy / Utilities Product Demo Script: Selling Asset Risk Analytics to a Distribution Network
You are forty minutes out from a demo with a Head of Asset Management who brought the Chief Engineer and someone from Network Performance & Reliability. They already had the pitch call. They said yes to seeing it. That does not mean they are curious — it means they have written down four things they intend to break: what touches the OT network, what happens when the model is wrong about an energised asset, whose team owns it after you leave, and where the money comes from when the determination is locked until the next reset.
This is not a market where a dashboard tour lands. The people on this call have sat through a post-event review defending which outage minutes were excluded from the normalised SAIDI figure. They have signed a permit-to-work. They have a condition monitoring platform they bought three years ago that nobody logs into, and they are quietly checking whether you are that vendor again. If you open with your architecture slide, you will hear typing by minute six and "send it through and I'll take it to the asset committee" by minute thirty-five.
The demo below is built around three moments in their week — the fourth day of a heat run, the vegetation program review, and the works program build for next year's submission — and around the four questions they will interrupt you with. Use the screens as a resource. The call is won on the detours.
The demo call script
Say it in your own words. The structure is the part that matters.
- 1
Before the call — confirm the stack in writing
Send this in the confirmation email, two days out: "So I don't waste the Chief Engineer's time showing screens that don't apply — three quick ones: what are you running for your asset register (Ellipse, Maximo, SAP PM?) and which version; what's the ADMS/OMS and is the outage data coming out of it or out of a separate reporting layer; and where does the SCADA historian sit — inside the OT zone, or is there already a one-way replica in the corporate network?" The answer changes the demo completely. "Historian replica already published to the data warehouse" means you can talk about a first analysis in weeks. "Everything lives inside the OT zone and nothing leaves it" means the whole first half of your demo is the retrospective, file-based path and you should not show live integration at all. Also ask: how many distribution transformers in the fleet, and how many line kilometres in the vegetation program. You want their numbers in your mouth on the call, not round numbers.
- 2
Before the call — know who is in the room and what each one is defending
Three people, three demos, one hour. Write their names down before you dial. - **Head of Asset Management** — wants the unplanned distribution transformer failure rate per 1,000 units to come down without blowing the replacement program. Cares about the ranked list and whether it survives a cost-benefit test. - **Chief Engineer / Principal Distribution Engineer** — is the veto. Cares about one thing first: does anything you sell go on or near an energised asset, and if it fails, what happens. Answer that in the first ninety seconds, unprompted. - **Manager Network Performance & Reliability** — owns the SAIDI and SAIFI numbers and the STPIS exposure at the end of the period. Cares about worst-served customers and GSL payments and whether your output changes any of it before the next reset. - If **Manager Regulatory Affairs** is on, the entire call is really about whether this becomes a defensible line in the next submission. If a **Vegetation Management Program Manager** is on, do not lead with transformers.
- 3
Before the call — load their network, not ACME Corp
Rebuild the demo dataset with their feeder names, their zone substation names, their region codes. If they gave you nothing, use the naming convention from their annual reliability report — it's public, it takes ten minutes, and "Kyneton 22kV, feeder KYN-11" on screen buys you more credibility than any slide. Decide what you will not show. No admin screens. No user management. No configuration. Every feature you show that they did not ask about is now something they have to evaluate, question and defend to the asset committee.
- 4
Opening — set the contract in ninety seconds
"Quick recap so I show you the right things. Last time you said two things. One: you lost a cluster of pole-mounted units in the back half of January, third and fourth day of the heat run, overnight temps never dropped, and every one of them was an unplanned outage with a night callout and a pole-top fire report. Two: your vegetation spend per line kilometre has gone up three years running and the regulator keeps asking whether it's risk-targeted or cycle-driven. Still the two live ones? Anything shifted since we spoke — people, budget, anything? One request before I share a screen. I'd rather you stop me than sit through something irrelevant. If you're thinking 'that won't work on our network', say it in the moment — that's the useful part of this call, not the part where I talk. And before I start: what's the one thing that, if this can't do it, we don't need to keep talking?" Then shut up and demo in the order they just gave you.
- 5
Pre-empt the veto — say the safety line before the Chief Engineer asks
Say this before you share your screen, every time, even if nobody asked: "Before anything else, for the engineering side of the room: nothing we sell goes on a pole. There is no device, no sensor, no clamp, no antenna on an energised asset. Nothing connects to your control system. There is no path from us into SCADA and nothing we produce can operate a recloser, a sectionaliser or an ACR. If our platform is completely offline for a week, nothing on your network changes and no operator loses a screen. Everything you're about to see reads data you already have and produces a ranked list that a planner reads. That also means there's no type approval gate and no isolation or access authority involved in step one. There is still an OT security question about where the data comes from, and I'll show you exactly how we handle that in a minute." This single paragraph moves you from "grid-adjacent vendor, two-year process" to "analytics on our own data", which is a different approval path and both of them know it.
- 6
Core loop 1 — day four of the heat run
**Problem:** "It's the fourth day of a heat run. Overnight minimum didn't get below 26. Air-con load is peaking, the units got no thermal recovery, and your crews are already committed. Historically that's when you lose a batch — not one unit, a batch, because they went in during the same build-out wave in the seventies and they age together." **Screen:** "This is the list your asset planner opens in October, not January. Every distribution transformer we could model, ranked by probability of failure over the next twelve months, with the drivers next to it — sustained loading against nameplate, overnight temperature recovery, fault history on the spur, age band, and the switching record. These are your units on KYN-11." **Consequence:** "The point isn't the score. The point is the top of this list becomes a planned replacement with a permit-to-work in daylight, instead of a night callout to an energised fault. That moves minutes off your unplanned SAIDI and it moves jobs out of the emergency callout count that goes into your TRIFR conversation." **Check:** "Is that how your replacement program actually gets built, or is it coming out of the condition assessments from the inspection cycle?"
- 7
Core loop 2 — the vegetation program review
**Problem:** "Your program manager is defending spend per line kilometre for the third year running. Vegetation is still the top cause of unplanned minutes on the rural feeders, so cutting it lifts SAIDI, and growing it draws the question about whether it's risk-targeted or just the cycle." **Screen:** "This is span-level, not feeder-level. Every span on this rural backbone scored on strike risk — growth rate from the imagery, species, clearance at last cut, customers downstream, and whether the span is upstream or downstream of the recloser. Red spans are where a strike takes out 400 customers. Grey spans are where it takes out nine and the cycle says trim them anyway." **Consequence:** "What you get out of this isn't 'spend less'. It's a defensible answer to 'which spans justified the truck'. You can hold spend per line kilometre flat and shift the mix toward the spans carrying the outage minutes — and you can show the working." **Check:** "When the regulator asks how you targeted the program, what do you currently put in front of them?"
- 8
Core loop 3 — the works program and the submission
**Problem:** "Anything that isn't in the submission has no allowance and no recovery. So the useful question isn't 'is this a good idea', it's 'does this make next reset's reliability program business case stronger'." **Screen:** "This is the export. Ranked units with quantified risk, consequence in customer minutes, and cost-benefit at unit level — the format that goes into a CBRM-style asset criticality ranking, not a PDF. Your regulatory team can trace every number back to your own SCADA, outage and asset data." **Consequence:** "A submission with two years of your own failure data behind the risk model is a different document from one with a vendor's case study in it." **Check:** "Who actually writes the reliability program business case — is that in Asset Management or does Regulatory Affairs own the pen?"
- 9
Handling "will it handle X?" — the three honest answers
Slow down and get the specific first. "Will it handle condition data?" is unanswerable. "Do you mean DGA and tap changer data from the zone substation power transformers, or condition on the distribution fleet?" — those are completely different scopes. Then answer one of three ways: **Yes, and here it is.** Show it live. Strongest thing that happens on a demo. **Yes, but not how you'd expect.** "We don't score the unit inside your asset register. We push a risk field back as a nightly file and your planner sees it in the works program view. Two extra steps for your integration team, and I'd rather you know that now than in month three." **No.** "No. We don't model zone substation power transformers today — no DGA ingestion, and it's not on this year's roadmap. Distribution fleet only. How often does that come up for you — is the power transformer fleet the bigger worry, or is it the pole-mounts?" Half the time it was an edge case they raised to test you. Never say "we can build that." To a Chief Engineer who has been through a failed condition monitoring rollout, "we can build that" is the exact sentence their last vendor said. And write it down out loud: "Noting that — MAIFI treatment for momentary events on the recloser. Straight answer to you Thursday." Then Thursday, not Friday.
- 10
Pressure line 1 — integration and OT security
"Let me be specific rather than saying 'we integrate'. There are three inputs. Historian data — loading and temperature, we take a periodic extract, not a live connection. Outage and switching records out of your OMS. Asset register extract out of Ellipse — nameplate, install date, location, whatever's populated. The path is one-way and file-based. You publish to a landing zone in your corporate network — SFTP or a cloud bucket, your choice. We pull. There is no inbound path from us to you and nothing of ours sits inside the OT zone. No agent on a substation host, no firewall rule from the control system outward. Your security architecture review is reviewing a data export, not a connection. What we don't touch: we never write to SCADA, we never write to the OMS, and we don't write to your asset register unless you specifically ask for the risk field written back — and if you do, it's a nightly file your team loads, not us reaching in. If you're on an older Ellipse instance, the extract is a scheduled report your team already knows how to build. I'll send the field list before we go further so your data team can tell you in an hour whether it's easy or awkward." Saying what you don't touch calms this room more than any capability claim.
- 11
Pressure line 2 — who owns it after you leave
"Ongoing effort on your side, honestly: it needs one analytical owner, not a team. Usually that's an asset analytics engineer or a network planner who already builds the replacement program. Call it half a day a month once it's running — reviewing the ranked list before the works program cut, flagging units where they disagree with the score so the model learns. It's not an IT job and it's not a control room job. The control room never opens it. That matters, because the most common way a platform like this dies here is that it lands as a separate login that the people making decisions never open. If it doesn't show up inside the works program the planners already run, it will die the same way your last one did. On our side: the same engineer who runs your data onboarding stays on the account. If your analytical owner leaves, handover is one day — the model runs on the data feed, not on someone's configuration."
- 12
Pressure line 3 — what happens when it breaks
Do not say a percentage. Say this: "If our platform is down, here's what happens on your network: nothing. No outage, no loss of visibility in the control room, no operator impact, because we're not in that path. What you lose is the ranked list refresh. If we're down for a week during storm season, your works program is running on last week's ranking, which is fine — the ranking moves monthly, not hourly. Support: if the data feed breaks and the ranking goes stale, that's a phone number and someone picks up during business hours. Genuine P1 for us is a data integrity issue — a bad extract that shifts the rankings — and that's a call-out, any hour. Happy to walk your team through the last incident we had and what we changed, if that's useful for the security review."
- 13
Pressure line 4 — time to value, tied to their calendar
Three dates, not one: "**Live** — we have your extracts and the first backtest runs. Four to six weeks from the data being available, and most of that is your team's extract, not our modelling. **Useful** — you have a ranked list you trust enough to argue with. That's the first works program cycle after go-live. If your program cut is in March, you want data flowing by January. **Fully embedded** — the ranking is a field in your planning view and it's driving the proactive replacement volume. Second program cycle. What you have to do, so nobody's blindsided in week three: one historian extract spec'd and scheduled, one outage and switching extract, one asset register dump, and roughly four hours of a planner's time to walk us through how the replacement program is actually built. That's it. If your data team can't get to the extracts until after the reset submission goes in, tell me now and we'll set the start date accordingly rather than pretending." One reference, one sentence, in their world — not a logo slide.
- 14
Recovering the room when it goes quiet
The signs: shorter answers, "mm-hm", a beat of delay, "yeah, no, that makes sense" said flat, camera off. Stop. In this order: "I've been talking for a while — is this the part you care about, or should I jump to the vegetation side?" "Let me stop the tour. What's the thing you're worried about that I haven't touched?" "Do you want to drive? Tell me what to click — pick a feeder you know is a problem and let's see what it says about it." This one is extremely effective with a Principal Distribution Engineer and almost nobody offers it. "I think I'm showing you the wrong things. Can I stop, take ten minutes on what actually matters, and come back with a demo built for that?" What never works: talking faster, adding features, "one more thing I want to show you."
- 15
Closing — gaps out loud, then a date
"Let me summarise including the gaps. Three things landed: the ranked distribution transformer list against your fleet, the span-level vegetation targeting, and the export format for the business case. Two open: whether we can model your rural pad-mounts given the install date problem — I'll come back with a coverage estimate once I've seen a sample extract — and the MAIFI question, which I owe you Thursday. Where does this sit for you now — worth pursuing, or is there something that's already ruled it out? I'd rather hear a no today than chase you for a month. Who else needs to see it? If your OT security lead wants twenty minutes on architecture and data flow with no product screens at all, I'll run that separately. And if this goes to the asset committee, tell me what a paper has to contain to survive it — cost-benefit, risk quantification, alignment to the reliability program — and I'll build that with you rather than sending a PDF that gets forwarded once and dies. When's the committee? Let's put fifteen minutes in the diary the week before so I know what questions to expect, even if I'm not in the room." Calendar open, invite sent before you hang up. Within 24 hours: the gap list with answers, the four screens that mattered, the field list for the extracts, and the security architecture note if OT was on the call.
How the call actually sounds
Prospect on the left, the rep on the right.
Rep
Before I share anything — last time you said you lost a cluster of pole-mounts in the January heat run, and that the vegetation spend per line kilometre has climbed three years running. Still the two live ones, or has something moved?
Buyer
They're still live. Before you share your screen — is there anything in this that goes on a pole?
Rep
No. No device, no sensor, no clamp, nothing on an energised asset. Nothing connects to your control system, nothing of ours can operate a recloser or a sectionaliser. If we're offline for a week nothing on your network changes and no operator loses a screen. There's no type approval gate and no access authority involved in step one.
Buyer
Then what's it reading? Because if it wants a live feed off the historian, that's an OT security architecture review, a segregation assessment, and you're looking at nine months before anyone opens the box.
Rep
One-way, file-based, and it stops at your corporate network. You publish a periodic extract — loading and temperature from the historian, outage and switching from the OMS, an asset dump from Ellipse — into a landing zone you own. We pull. There is no inbound path from us into anything. Your security team is reviewing a data export, not a connection. Does that change which review it goes through?
Buyer
It changes it. It doesn't remove it. And I'll tell you the real problem — half our rural pad-mounts have install dates that were guessed when we migrated the register in 2011. We don't have nameplate data for a big chunk of the rural fleet. Your model's going to be reading fiction.
Rep
Then let me scope it honestly rather than tell you data quality doesn't matter. Loading history, fault history on the spur and switching records carry more signal than the register does — install date is helpful, not load-bearing. Realistically we'd model the portion of the fleet where the operational data is usable, and the first thing the exercise gives you is a list of exactly which records to fix first. On your fleet, my guess is that's most of the urban pad-mounts and a thinner slice of the rural. I'd rather show you the coverage number after I've seen a sample extract than promise you a hundred percent now.
Buyer
Look, we've got district engineers who've run these feeders for thirty years. Barry could tell you which feeders are the problem without a model. What's this doing that he isn't?
Rep
Nothing at feeder level, honestly — he'll be right about the feeders. The gap is which of the four thousand units on those feeders goes first, and roughly when. Here's what I'd propose: we run it blind on your historical data, you have Barry write his list independently, and we compare. If it just confirms what he already knows, that's a cheap validation and you've lost nothing. If it flags units nobody was watching, that's the conversation. He's the judge, not the target.
Buyer
Say it does flag one. Unit 44821 on a rural spur. What am I supposed to do with that? I'm not getting a permit, a crew and a spare 200 kVA out there on a probability score.
Rep
You're not — you're bundling it. This screen is the works program view: the flagged units sorted by geography and by planned switching windows, so the ones that make sense get picked up with work you're already sending a truck for. The value isn't 'replace it tomorrow', it's that the job becomes daylight switching under a permit instead of a 2am callout to an energised fault. That's an unplanned SAIDI minute you don't book, and it's one fewer emergency job in the number you report against TRIFR.
Buyer
And when it's wrong? We pull a healthy unit with ten years left, and at the next reset someone asks why we spent allowance on it. That's a worse conversation than a failure.
Rep
Fair, and that's why the first thing we run is a backtest against your own failures — we take your data up to a cut-off date, rank, and check where your actual failures landed in that ranking. You get a precision number on your fleet before you replace anything, not a claim from me. If it can't beat the age curve you're already using, it's not worth your time and I'd rather find that out in six weeks.
Buyer
Which brings me to the real problem. Our determination is locked. There's no allowance line for analytics in this period, and the next submission is being drafted eighteen months out.
Rep
Then the submission is the actual target, and I'd rather aim at it than pretend otherwise. Two things. One: who's holding the pen on the reliability program business case — is that you or Regulatory Affairs? Because that paper is far stronger with two years of your own failure data behind the risk model than with my brochure. Two: for this period, it may not need capex at all. If it defers a handful of unplanned replacements and takes truck rolls off unplanned faults, it can sit inside the maintenance line. Worth testing with whoever owns that budget.
Buyer
I'll test it. Send me the architecture doc and the field list and I'll put it to the asset committee next month.
Rep
I'll have both to you tomorrow. Two questions first — what does a paper need to contain to survive that committee, cost-benefit and risk quantification or is there a standard template? And can we put fifteen minutes in the diary the week before, so I can help you pre-empt the questions rather than hearing them second-hand afterwards. What date's the committee?
Objections you will hear
What they say, and what you say back.
| Objection | How to answer it |
|---|---|
| “Anything grid-adjacent needs two years of pilots and compliance review before it goes near an energised asset.” | Don't argue the process — it exists for good reasons and they know it better than you. Ask what the actual gate sequence is: type approval, OT security architecture review, segregation assessment, chief engineer sign-off. Then propose starting where none of those gates apply: a retrospective backtest on their own historical SCADA, outage and asset data. No hardware, no device on a pole, no connection to the control system. That gives the engineering team something to judge on their terms while the approvals run in parallel, and it tells you inside a few weeks whether the model finds anything real on their fleet. |
| “We plan capex in five-year regulatory cycles and this period is locked. There's no allowance for this.” | Position for the cycle instead of fighting it. Ask when the next submission is being drafted and who owns the reliability program business case — that's your real timeline and often your real champion. Then test the opex path: if it defers even a handful of transformer replacements or takes truck rolls off unplanned faults, it may sit inside the maintenance budget rather than needing new allowance. And start the evidence base now. A submission carrying two years of the utility's own failure data behind the risk model is a different document from one carrying a vendor case study. |
| “We already have a condition monitoring platform we bought three years ago that nobody uses.” | Ask what specifically killed it. It's almost always one of three things: alerts the engineers didn't trust, a separate login the planners never opened, or output that never made it into the asset register or the works program. Then be explicit about which of those you avoid and how — if the ranking doesn't land inside the planning view they already use, it dies exactly the same way. Offer to talk to the person who owned that failed system rather than around them; they know more about why it failed than anyone and they'll respect being asked. |
| “Our asset data is a mess. Half the transformer records have the wrong install date and we don't have nameplate data for the rural fleet.” | That's normal and it's usually the reason to start rather than wait. Separate what the model needs from what's nice to have: loading, temperature, fault history and switching records carry more signal than a tidy register does. Then scope down out loud — 'we model the portion of the fleet where the operational data is usable, and the first output tells you exactly which records to fix first.' Utilities trust a vendor who narrows the claim honestly far more than one who says data quality doesn't matter. |
| “How does this improve safety? If it doesn't, it's not a priority this year.” | Make it concrete instead of implied. A failure found before it happens is planned switching in daylight under a full permit-to-work. The same failure found the hard way is a night callout to an energised fault, a crew working near a burning pole-top, and kilometres driven under fatigue rules. Fewer emergency responses means fewer live-line jobs and fewer emergency callouts in the count that sits alongside TRIFR. Reducing unplanned reactive work is a safety outcome the Chief Engineer can put in front of the board without translation. |
| “We've got engineers who've run this network for thirty years. They know which feeders are the problem.” | Agree, immediately and without qualification — they're usually right about the feeders. The gap is which of the four thousand units on those feeders goes first and when, which is not a question thirty years of experience can answer unit by unit. Offer to run it blind, have the district engineers write their list independently, and compare. If it confirms what they know, it's a cheap validation. If it flags units nobody was watching, that's the conversation. Let the engineers be the judges rather than the thing you're replacing. |
| “Send me something and I'll take it to the asset committee.” | Find out what the committee actually decides and what a paper needs to survive it — cost-benefit, risk quantification, alignment to the existing reliability program, sometimes a specific template. Then offer to build that with them instead of sending a PDF that gets forwarded once and dies in an inbox. Get the committee date on the call, and get fifteen minutes in the diary the week before so you know what questions to arm them for, even if you're not in the room. |
Questions reps ask about this call
- How long should a utilities product demo actually run?
Book an hour, plan forty minutes of content, and expect to use twenty. In this market the interruptions are the call — a Chief Engineer asking what happens if a device fails on a live pole, or a Network Planning Manager asking where the risk field lands in the works program, is worth more than any screen you had queued. Cover three workflows completely rather than twelve partially. If you've talked for ninety uninterrupted seconds, you've drifted into tour mode and you should hand the mic back.
- What should I demo first when the Head of Asset Management, the Chief Engineer and Network Performance are all on the call?
Answer the Chief Engineer's veto question before you share your screen — what touches an energised asset, what touches the OT network, and what happens on their network if your platform is down. Ninety seconds, unprompted. Then demo in the order the room gave you when you asked 'what's the one thing that, if this can't do it, we don't need to keep talking?' Usually that's the ranked transformer list for Asset Management or the span-level vegetation targeting if the program manager is on.
- How do I answer the OT security question in a demo without a security architect on the call?
Describe the data path in plain terms and be specific about direction: one-way, file-based, published by them into a landing zone they own, pulled by you, no inbound path, nothing installed inside the OT zone, no write access to SCADA or the OMS. Then say what you don't touch — that calms the room more than any capability claim. Offer a separate twenty-minute session for their OT security lead that is architecture and data flow only, no product screens. Don't improvise beyond what you know; note the question and answer it in writing within two days.
- What do I say when a utility tells me their capex is locked for the current regulatory period?
Treat it as a timing question, not a rejection. Ask when the next submission is drafted and who writes the reliability program business case. In parallel, test whether it can be funded from maintenance opex on the basis of deferred replacements and fewer truck rolls on unplanned faults. Then start building the evidence base now — a retrospective analysis on their own data costs them little and makes the next submission materially stronger than a vendor brochure would.
- How do I make a demo credible when the buyer says their asset data is unreliable?
Scope down honestly on the call. Say which inputs actually carry the signal — loading, temperature, fault history, switching records — and which are nice to have. Then commit to a coverage estimate after you've seen a sample extract rather than claiming full fleet coverage. Frame the first output as a two-for-one: a ranked risk list, plus a list of exactly which register records to fix first. Utilities have been burned by vendors who waved data quality away; being the one who narrows the claim is a competitive advantage.
- What's the right next step to book at the end of a utilities demo?
Never 'I'll follow up next week.' Get the asset committee date on the call, plus a fifteen-minute prep session the week before it so you can shape the paper and hear what questions were raised. If OT security or Regulatory Affairs weren't in the room, offer the tailored short session for each. Within 24 hours send the gap list with your answers, the field list for the data extracts, and the security architecture note — nothing generic, and nothing you didn't specifically promise.