Energy / Utilities · Warm Call

Warm Call Script for Energy / Utilities: Cashing a Referral Before It Cools

You've got the pickup because a peer at a neighbouring network said your name. Maybe the Head of Asset Management at the DNSP next door pulled down your note on transformer failure clustering and said "call Ravi, he's just taken the reliability role." Maybe someone on the reliability working group fired off a three-line intro that got skimmed at a level crossing and archived. Either way, the person answering knows a name and almost certainly does not know what you sell.

That buys you three things: the pickup, about ninety seconds of suspended disbelief, and permission to ask a real question without warming up to it. It does not buy you a problem. Their world is not the referrer's world — one network is 80% urban pad-mount on a tight cycle, the next is long rural feeders, SWER spurs and vegetation as the top cause of unplanned minutes. Transplant the referrer's pain onto them and they'll hear, correctly, that you didn't do any work on them specifically.

Everything in this industry runs through gates: type approval, OT security architecture review, isolation and access authority, chief engineer sign-off, and a capex allowance that was locked into a submission years ago. None of that is an objection to argue with on a warm call. Your job in four minutes is to convert borrowed credibility into one specific, testable reason you're relevant to this network — and to book a second meeting with a date, a length and a named engineer on it.

The warm call script

Say it in your own words. The structure is the part that matters.

  1. 1

    Pre-call: build the provenance line

    Write one sentence you can say out loud before you dial: "[Referrer] mentioned you because [specific, checkable reason]." Good: "Kath Doyle pulled down our note on transformer failures clustering on day three of a heatwave, and said you'd taken over Network Performance and Reliability in February — right as the reset work started." Bad: "Kath thought you'd be interested in what we do." That's nothing, and it burns the whole ninety seconds. Pre-decide three things: 1. **Exactly what the referrer said.** If Kath said "you should talk to Ravi," you say that. Never inflate it to "Kath said you'd be really interested" — these people sit on the same reliability working group and they compare notes. 2. **Your relevance hypothesis, about their network, not the referrer's.** New in role. A major event review published. A determination submission being drafted. Worst-served customer numbers in the last annual report. A job ad for a Vegetation Management Program Manager. 3. **The 15-second re-brief**, on the assumption the intro email was never read.

  2. 2

    The open — name, provenance, permission (25 seconds)

    "Ravi — Sam Whitfield, from Kelvin. Kath Doyle at [Neighbour Network] suggested I call. She picked up our piece on distribution transformers failing in clusters on the third and fourth day of a heatwave, and said you'd taken the Network Performance and Reliability role in February. She may have been overselling my usefulness. Have you got four minutes for me to check whether this is even relevant to your network, or should I come back after the storm season debrief?" If they say "yeah, Kath said you'd call" — that's the whole warmth budget being handed over. Five words of acknowledgement, then move: "Good, she said she'd flag it. Then I'll be quick." Do **not** ask "so how do you know Kath?" It costs three minutes and returns nothing.

  3. 3

    If they don't remember the referrer

    "No reason you would — it was a two-line email on a Friday. Short version: we model which specific distribution transformers on a feeder are most likely to fail in the next summer, off SCADA, loading and outage history the network already has. Kath's been running it retrospectively on three summers of her data. Worth four minutes, or not really?" No company overview. No 'we're a leader in'. One sentence about what the thing does in their language, then hand the call back.

  4. 4

    The relevance bridge — the move the call lives or dies on

    This is where you convert their credibility into your relevance. Structure: **what the referrer's world looks like → the specific difference in yours → a question that hands them control.** "What Kath's chasing is a mostly urban pad-mount fleet with a decent proactive replacement program and reasonable nameplate data. That's her shop, not yours — you're what, sixty percent rural, long feeders, and I'd guess vegetation is still your top cause of unplanned minutes, not asset failure. So I genuinely don't know if this lands with you. When you break last year's unplanned SAIDI down by cause, where does asset failure actually sit?" Naming a reason you might be irrelevant is the fastest credibility move available on a warm call in this industry. Engineers respect scoping down. It also disarms the brace for a pitch.

  5. 5

    Discovery — three questions, four at most

    You have four to twelve minutes and no agreed agenda. Do not run eleven qualification questions at a Chief Engineer; it reads as an abuse of the referral. **1. Current state, mechanical.** "When a pole-mount lets go at four on a forty-degree afternoon, how do you find out — does something show at the recloser, or is it the call centre?" **2. Cost, in their numbers.** "What's your unplanned distribution transformer failure rate per thousand units doing year on year? And is your vegetation spend per line kilometre still climbing?" **3. Priority test — the one that saves you a wasted meeting.** "Is that a this-reset problem or a next-reset problem?" **Optional fourth — mapping.** "Who else would care about this besides you — does the Head of Asset Management own the replacement program, or is it the Chief Engineer's call?" Listen for the correction. When they say "honestly it's less the transformers, it's that I can't show the regulator which spans justified the truck" — write down their exact phrasing. It goes in the follow-up email and the second meeting agenda.

  6. 6

    Reading the cool-off

    Warmth withdraws politely. Watch for: answers getting shorter and more agreeable; logistics talk ("send something through"); a price question before any problem is established; or the referrer's name coming back as an exit ramp — "well, if Kath rates you..." Stop talking and name it: "I'm getting the sense this isn't the pressing thing for you this year — which is fine, Kath was guessing on my behalf. Is it not the problem, or not the moment? Because if the whole reliability conversation is parked until the next submission, I'd rather know that and come back when the business case is being drafted." A clean "not the problem" is a good outcome. It protects the referrer and it stops you burning a quarter on a ghost.

  7. 7

    The close — a meeting with a name on it

    The number one failure is a pleasant call that ends in "send me some info." Close on their words, and make the first step one that clears none of their gates because it doesn't touch anything. "Then here's what I'd suggest. You said the argument internally is which spans justified the truck, not whether vegetation is the cause. Give me thirty minutes and I'll show you what we did with three summers of Kath's outage and switching data — retrospective only, no hardware, nothing on an energised asset, nothing touching the OT network, so there's no type approval or security review in the way. And I'd want your Principal Distribution Engineer on it, because he's the one who has to believe the ranked list. Thursday morning, or Monday afternoon?" Must be present: **a date, a length, a reason built from their sentence, and who else attends.** If they truly can't commit: "I'll send two paragraphs and one chart — the ranked list versus what actually failed. Tell me Thursday whether it's worth thirty minutes." Then diarise it on your side, not theirs.

  8. 8

    Close the loop with the referrer, same day

    "Kath — spoke to Ravi, thanks for that. Turns out his issue is more the vegetation justification than the transformer fleet, so a bit different to yours. Meeting him and their Principal Engineer Thursday. Appreciate the nudge." Three jobs: it thanks them, it tells you whether you can keep using their name, and it's the only reliable way a referral source produces a second referral. In this industry the working groups and the reliability forums are small — a source who never hears back stops referring, and everyone finds out.

  9. 9

    Language bank

    **Works** - "Kath suggested I call — she may have been overselling my usefulness." - "That's her network, not yours, so I don't know if this lands." - "Is that a this-reset problem or a next-reset problem?" - "No hardware, nothing on an energised asset, nothing touching OT." - "Let your engineers judge it rather than be the target of it." - "Four minutes, or shall I come back?" **Kills the warmth** - "So how do you know Kath?" as an opener. - "Kath said you'd be really interested in this." They will check. - "Just to give you a bit of background on us..." - "As per the email below." - "Kath was drowning in transformer failures, so I imagine you are too."

How the call actually sounds

Prospect on the left, the rep on the right.

  1. Rep

    Ravi — Sam Whitfield, from Kelvin. Kath Doyle at Ridgeline Power suggested I call. She picked up our note on transformers failing in clusters on day three of a heatwave and said you'd taken over Network Performance and Reliability back in February. She may have been overselling my usefulness. Four minutes to work out whether this is even relevant to your network?

  2. Buyer

    Kath, yeah — we're both on the reliability working group. She didn't say what it was about. I'll save you some time though: we're two years into the determination period. If it costs money, it's a next-reset conversation, and honestly I've got a major event review due Friday.

  3. Rep

    Fair, and I'm not going to argue with the determination cycle. Two things then. One — when is the next submission actually being drafted, because that's the real timeline for anything with a capex allowance attached. Two — the first step I'd propose costs nothing off capex, because it's a retrospective run on data you already have. No hardware, no device on a pole, no connection to OT.

  4. Buyer

    The submission work starts late next year. And look, we've been here before. We bought a condition monitoring platform three years ago. Big rollout, a portal, dashboards. Nobody opens it. It's a line item now.

  5. Rep

    What killed it specifically — was it alerts the engineers didn't trust, or was it that it lived in its own login the control room never touched?

  6. Buyer

    Both. The alerting cried wolf constantly, so people stopped looking. And it never fed the asset register or the works program, so even when it was right, nothing happened. Planners kept working off the same spreadsheet.

  7. Rep

    Then I'd rather be honest with you: if what we do can't land in your ADMS and drop straight into the works program the planners already run, it dies the same way and I've wasted your Friday. That's a design question we should test before anything else. Can I ask what your unplanned distribution transformer failure rate per thousand units has been doing over the last three summers?

  8. Buyer

    It's trending the wrong way, but I'll tell you the real problem with your idea. Our asset data is a mess. Half the rural transformer records have the wrong install date and there's no nameplate data at all for a chunk of the SWER fleet. So whatever model you've got, there's nothing for it to eat.

  9. Rep

    That's normal and it's usually the reason to start rather than wait. The register matters less than people expect — loading, temperature, fault history and switching records carry more signal than install dates. And I'd scope it honestly: we can probably model the sixty percent of the fleet where the data's usable, and the exercise itself tells you exactly which records are worth fixing first.

  10. Buyer

    Maybe. But I've got engineers who've run this network for thirty years. Barry can stand at a whiteboard and tell you which four feeders are going to fall over this summer. I'm not sure what a model adds to that.

  11. Rep

    He's probably right about the feeders. Most of them are. The gap isn't which feeder — it's which of the four thousand units on those feeders goes first, and whether it goes in January or March. So run it blind. We produce a ranked list off your own history, you put Barry's list next to it, and he judges it. If it just confirms what he already knows, that's cheap validation for the business case. If it flags units nobody was watching, that's the conversation.

  12. Buyer

    Alright, that's a fairer framing than I expected. Though if I'm honest, transformers aren't what's actually hurting me. It's vegetation. Spend per line kilometre has gone up three years running and the regulator asked in the last submission why it's cycle-driven rather than risk-targeted. I can't answer that properly. That's the thing I get asked about.

  13. Rep

    Say that again for me — you can't show which spans actually justified the truck versus which got trimmed because the cycle said so?

  14. Buyer

    Correct. And vegetation is still the biggest single chunk of our unplanned SAIDI minutes on the rural backbone, so I can't just cut it either. Cut it and my STPIS position gets worse.

  15. Rep

    Then that's the conversation, not transformers. Same data spine, different question: which spans on which feeders produced outage minutes, and what the trim history was against them. Is that a this-reset problem for you or a next-reset problem?

  16. Buyer

    It's now. The asset committee meets monthly and vegetation justification is a standing item. Send me something and I'll take it in.

  17. Rep

    I'll do better than a PDF that gets forwarded once. What does a paper need to survive that committee — cost-benefit, risk quantification, alignment to the reliability program?

  18. Buyer

    All three, plus the Chief Engineer's comfort. And he'll ask what happens if there's any device on an energised asset. That's a genuine veto, not a formality.

  19. Rep

    Understood, and there's no device in this phase — it's a retrospective on your own outage, switching and vegetation records, so there's nothing to type-approve and nothing crossing the OT boundary. Thirty minutes, Thursday morning, with your Principal Distribution Engineer on the call, and we'll build the shape of that committee paper together rather than me guessing. Does Thursday work, or is Monday afternoon cleaner after the event review?

  20. Buyer

    Monday. Send an invite, put Barry and our Vegetation Program Manager on it, and keep it to thirty.

Objections you will hear

What they say, and what you say back.

ObjectionHow to answer it
Anything grid-adjacent needs two years of pilots and compliance review before it goes near an energised asset.Agree with the process, then shrink the first step until none of it applies. "Completely — and I'd want it to. Can you walk me through the actual gate sequence, type approval, OT security architecture review, chief engineer sign-off? Because the first thing I'm proposing clears none of them, since it doesn't touch anything. It's a retrospective run on your own historical SCADA, outage and asset data. No hardware, no connection, nothing energised. Your engineers get something to evaluate on their terms while the approvals run in parallel, and inside a few weeks you know whether the model finds anything on your fleet."
We plan capex in five-year regulatory cycles and this period is locked. There's no allowance for this.Don't fight the cycle, position for it. "Then the real question is when the next submission is being drafted and who owns the reliability program business case — that's my timeline, not this quarter. Two things in the meantime. First, test whether this sits in opex rather than capex: if it defers even a handful of transformer replacements or cuts emergency truck rolls on unplanned faults, it may live inside the maintenance budget. Second, build the evidence now. A submission with two years of your own data behind it is a much stronger paper than one with a vendor's brochure attached."
We already have a condition monitoring platform we bought three years ago that nobody uses.Ask what killed it before you defend anything. It's almost always one of three: alerts nobody trusted, a separate login the control room never opened, or output that never reached the asset register. "Which was it for you?" Then be explicit about which of those you avoid and how. "If this can't surface inside your ADMS and drop into the works program the planners already run, it dies exactly the same way and I've wasted your time. I'd also rather talk to whoever owns that platform than around them — they know more about why it failed than anyone."
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 clean register with correct install dates. Then scope down honestly out loud — "we can model the sixty percent of the fleet where the data's usable, and the exercise tells you exactly which records to fix first." Utilities trust a vendor who narrows the claim far more than one who insists data quality doesn't matter.
How does this improve safety? If it doesn't, it's not a priority this year.Make it concrete, not implied. "A failure found before it happens is planned switching in daylight with a full permit-to-work and access authority. A failure found afterwards is a night callout to an energised fault, a crew working near a burning pole-top, and a fatigue-managed drive home. Fewer emergency responses means fewer live-line jobs and fewer kilometres driven at 2am. That's a reduction in reactive work your Chief Engineer can put in front of the board alongside the TRIFR number."
We've got engineers who've run this network for thirty years. They know which feeders are the problem.Never imply they don't — they're usually right. "Barry's probably right about the feeders. The gap is which of the four thousand units on those feeders goes first, and when. So run it blind: we produce a ranked list off your history, he puts his list beside it, and he's the judge. If it confirms what he already knows, that's cheap validation for the business case. If it flags units nobody was watching, that's the conversation." Make the engineers the jury, not the defendant.
Send me something and I'll take it to the asset committee.Find out what survives that room before you write anything. "What does a paper need to contain to get through — cost-benefit, risk quantification, alignment to the reliability program? Rather than send a PDF that gets forwarded once, let me build that with you. When's the committee? Give me fifteen minutes the week before to prep it with you, and five minutes after so I know what got asked even if I'm not in the room."

Questions reps ask about this call

What actually counts as a warm call in the utilities space?

Somebody else's credibility got you the pickup — a Head of Asset Management at a neighbouring DNSP who downloaded your material and named a peer, a mutual contact from a reliability working group, or a three-line intro from a consultant who works both networks. The prospect took the call because of the name, not because of you. They can usually name the referrer and almost never name what you sell. Assume the intro email was skimmed and archived, and plan a fifteen-second re-brief in their language.

Should I lead with the referrer's problem to show relevance?

No — that's the single most common way these calls die. Networks differ enormously: urban pad-mount fleets versus long rural feeders and SWER spurs, transformer failure versus vegetation as the top cause of unplanned SAIDI minutes, a mature proactive replacement program versus effectively run-to-failure. Describe the referrer's situation, then name the specific difference in the prospect's world and say you don't know whether it lands. Then ask a question about their operation. Naming a reason you might be irrelevant is the fastest credibility move available.

They said the determination period is locked and there's no allowance. Is the call over?

Not if you stop selling into this period. Ask when the next submission is being drafted and who owns the reliability program business case — that's your real timeline. Then test two doors: whether it can sit in opex if it defers transformer replacements or reduces emergency truck rolls, and whether a retrospective evidence-building exercise can start now so the eventual submission carries two years of the utility's own data. A locked period is a reason to start the evidence, not a reason to hang up.

Who should I be calling — Asset Management or Network Performance?

It depends what you're actually reducing. Unplanned transformer failure rate per thousand units and replacement program strategy tends to sit with the Head of Asset Management or the Chief Engineer / Principal Distribution Engineer. SAIDI, SAIFI, STPIS exposure, worst-served customers and GSL payments sit with the Manager Network Performance & Reliability. Vegetation spend per line kilometre and the justification for it sits with the Vegetation Management Program Manager, with Manager Regulatory Affairs owning what goes into the submission. On a warm call, ask directly: "Who else would care about this — does Asset Management own the replacement program, or is it the Chief Engineer's call?" Warm calls have an unusually high hit rate on that question.

How much discovery should I run on a warm call?

Three questions, four at the absolute most. This is not a booked discovery meeting and running eleven questions at a Chief Engineer reads as an abuse of the referral. Ask one mechanical current-state question, one that gets a number they're measured on — unplanned failure rate per thousand units, vegetation spend per line kilometre, unplanned SAIDI by cause — and one priority test. In this industry the priority test is best phrased as "is that a this-reset problem or a next-reset problem?"

What's a realistic close, given nothing can go near an energised asset quickly?

A thirty-minute second meeting with a named engineer on it, on a specific date, built from a sentence they said. The strength of the close is that the first step clears none of their gates: a retrospective analysis on their own historical SCADA, outage and switching data means no hardware, no type approval, no OT security architecture review and no permit-to-work. If they won't take a slot, take a smaller real commitment — two paragraphs and one chart, with a date on your calendar to chase — and then close the loop with the referrer the same day.