Telecommunications · Warm Call
Warm Call Script for Telecommunications: Cashing a Referral with a Network Ops or Retention Leader
You've got ninety seconds of somebody else's credibility and a Head of Network Operations who is halfway through a P2 on a regional POI. They took the call because a peer told them to. They cannot tell you what you sell, they probably skimmed the intro email on their phone between a change-window approval and a CSG breach report, and the moment you say "just to give you a bit of background on us," you've turned a warm call into a cold one they now feel slightly embarrassed to be on.
Telco makes this harder than most industries, because the people worth calling have all been sold this before. Every GM Service Assurance in the country has sat through an AIOps demo, watched the false positives train their NOC to ignore the tool by week three, and quietly turned the feed off. Every Director of Field Operations has been promised a lift in first-time-fix rate by a vendor who then wanted nine months of engineering time to build a data model against a homegrown inventory layer that doesn't match what's actually in the ground. Your referral doesn't clear any of that. It just buys you the pickup and permission to be direct.
So use the permission. This script is built to do one thing: convert borrowed goodwill into one specific, testable reason you are relevant to their book — their truck rolls per 1,000 services, their no-fault-found rate, their post-MSD churn cohort — inside the first minute, then get out with a diarised second meeting and a named attendee. Not "send me a deck." A date, a length, and a reason built from their own words.
The warm call script
Say it in your own words. The structure is the part that matters.
- 1
1. Pre-call: write the provenance line before you dial
One sentence, out loud, before you touch the phone: "[Referrer] mentioned you because [specific, checkable reason]." Good: "Tom Callaghan pulled down our dispatch-avoidance breakdown last month and said you'd taken the assurance remit at Westline in February when they folded service assurance into network ops." Dead: "Tom thought you'd be interested in what we do." Also pre-decide three things: - **Exactly what Tom said, word for word.** If he said "you should call Ellen," you say "Tom said I should call you." You do not upgrade that into "Tom said you'd be really interested." Field Ops and Network Ops leaders at competing RSPs sit on the same industry panels. They check. - **Your relevance hypothesis about them, not the referrer.** New in role. A publicised mass service disruption in a named region. A wholesale migration. A job ad for an L1 triage team lead. Something with a date on it. - **Your 15-second re-brief**, assuming the intro email was never opened. No product name in it. Just the problem, in their language.
- 2
2. The open — name, referrer, provenance, permission (target 25 seconds)
"Ellen — Sam Whitfield, from Harlow. Tom Callaghan said I should call you. He picked up something we published on avoidable dispatch and mentioned you'd taken assurance under network ops at Westline in February. He may have been overselling my usefulness. Have you got four minutes for me to work out whether this is actually relevant to you, or should I come back?" That's the whole open. Name, referrer immediately, why they specifically, time-boxed permission. If they say **"Yeah, Tom said you'd ring"** — that is your entire warmth budget being handed over in five words. Do not spend it asking how they know Tom. "Good, he said he'd flag it. Then I'll be quick."
- 3
3. If they can't place the referrer
Extremely common. Two-line intro, Friday afternoon, archived. Don't argue them into remembering. "No reason you would — it was a two-line intro and you've got a network to run. Short version: we work on the gap between when a GPON segment or a DSLAM port starts degrading and when the customer rings in about it. The bit where mean time to detect is basically 'whenever the first call lands.' Worth four minutes or not really?" No company overview. No platform. One problem, stated in their vocabulary, then straight back to permission.
- 4
4. The relevance bridge — name why you might be irrelevant
This is the beat the call lives or dies on, and you have to hit it inside the first minute. Structure: what the referrer's world looked like → the specific difference → a question that hands them control. "What Tom was dealing with is a fairly big field force and a truck roll number he'd been told to bring down while the L1 queue kept dispatching on tickets it couldn't triage. His no-fault-found rate was the thing keeping him up. That's his shop, not yours — you're carrying a lot more wholesale access than he is, and half your faults probably aren't even yours to fix. So I honestly don't know if this lands. Where does your NOC currently find out a segment is degrading — is it the assurance platform or is it the contact centre?" Why it works: it proves you researched them, it names a real reason you might be wrong, and it ends on a question about their operation. Naming your own possible irrelevance is the fastest credibility move available on a warm call. **Never** transplant the referrer's pain: "Tom was drowning in no-fault-founds, so I imagine you are too" tells them you did zero work on their network.
- 5
5. Discovery — three questions, maximum four
This is not a booked discovery. Four to twelve minutes, no agreed agenda. Eleven questions reads as an abuse of the referral. **1. Current state, mechanical.** "When a customer in a bad pocket rings in, who actually decides whether that becomes a dispatch or a wholesale fault? Is that an L1 call or does it go to an assurance engineer?" **2. Cost or friction, in their numbers.** "What's your truck rolls per 1,000 services sitting at, roughly — and what proportion are coming back no-fault-found? I'm not after a precise figure, I want to know if it's the two-in-ten problem or the four-in-ten problem." Or, if you're on with a GM Consumer / Retention or Head of Customer Experience: "After the last material outage, what did the churn cohort look like 30 to 60 days out — and what did the retention offers do to ARPU in that base?" **3. Priority test — the one that saves you a wasted follow-up.** "Is that a this-quarter problem or a live-with-it problem? Because if it's already funded and being worked, I'll leave you alone." **Optional fourth.** "Besides you, who'd care about this — is your Director of Field Operations carrying the dispatch number, or does that sit with the COO?" Listen for the correction. When they say *"it's less the detection, it's more that we detect it and still can't stop the dispatch going out"* — that's the call working. Write their exact phrasing down. It goes in the follow-up email and the second-meeting agenda.
- 6
6. Reading the cool-off and naming it
Warmth withdraws politely in telco. The signals: - Short agreeable answers. "Yeah. Yeah, that's fair." - Logistics narration: "Can you send something through and I'll circulate it." - Price before problem: "What does something like this cost?" - The referrer reappears as an exit: "Well, if Tom rates you..." Stop and name it: "I get the feeling this isn't the pressing thing this quarter — which is completely fine, Tom was guessing. Is it not the problem, or not the moment? Because if you're mid-migration and every spare cycle is committed, I'd rather know that now than send you a PDF nobody opens." A clean "not the problem" is a good outcome. It protects the referral and stops you spending a quarter on a ghost.
- 7
7. The close — a date, a length, a reason in their words, a name
"Then here's what I'd suggest. You said the issue isn't spotting the degradation, it's that the dispatch goes out anyway because L1 can't prove it's upstream. Give me thirty minutes and I'll show you how another RSP put an upstream-versus-in-home indicator in front of L1 before the booking was made, and what it did to their no-fault-found rate. I'd want whoever owns the dispatch number on it — is that your Director of Field Operations? Thursday morning, or Monday after your ops review?" Must contain: **a date, a length, a reason built from their sentence, and a named second attendee.** If they genuinely can't commit: "Fine. Send me one region's fault and dispatch history for last quarter — closure codes can be a mess, I don't care. I'll come back with how many of those dispatches were predictable off the alarm and performance feeds, and what they cost you. Then it's your data in front of the exec, not my slide. I'll call you Thursday week either way." Diarise it on your side, not theirs.
- 8
8. Close the loop with the referrer, same day
Two lines, non-negotiable, and routinely skipped: "Tom — spoke to Ellen, thanks for that. Her issue is a bit different to yours, more about proving the fault is on the access side before L1 books the appointment. Meeting her and her field ops director Thursday. Appreciate the intro." This thanks them, tells you whether you can use their name again, and is the only reliable way one referral turns into a second one. Sources who never hear back stop referring.
How the call actually sounds
Prospect on the left, the rep on the right.
Rep
Ellen — Sam Whitfield from Harlow. Tom Callaghan said I should give you a call. He picked up something we put out on avoidable dispatch and mentioned you'd taken assurance under network ops back in February. He may have been overselling my usefulness. Four minutes to work out if this is even relevant, or should I come back?
Buyer
Four minutes. I'm on a bridge at two for a POI incident in the north, so genuinely four. And I'll save you some time — if this is AIOps, we've done AIOps. We had a correlation overlay running eighteen months ago, it fired on everything, the NOC turned the notifications off inside a month and we quietly let the contract lapse.
Rep
That's the right thing to be suspicious about, and I'd rather deal with it now than at minute three. What Tom's got is a big field force and a dispatch number he's been told to bring down while L1 keeps booking trucks on tickets it can't triage. That's his shop. You're carrying far more wholesale access than he is, so a lot of your faults aren't even yours to fix — which is a different problem. Where does your NOC actually find out a segment is degrading at the moment? Assurance platform, or the contact centre?
Buyer
Honestly? Depends on the fault. Hard down, the EMS tells us. Degradation — intermittent dropouts, a port that's flapping, throughput sliding on a GPON branch — usually the first we know is when forty people in the same suburb call in on a Monday. Mean time to detect on that class of fault is basically 'whenever the phones light up.'
Rep
So the detection gap is on soft degradation, not hard down. What happens next — when those forty calls land, who decides whether it's a truck or a wholesale fault?
Buyer
L1 runs the script, and the script ends in a dispatch more often than it should. They can't prove it's upstream, the customer's angry, so they book an appointment. Then the tech drives out, finds nothing in the premises, closes it 'other', and we've burned a two-hour window and a van.
Rep
Roughly what proportion come back no-fault-found? I don't need a precise figure — I want to know if it's the two-in-ten problem or the four-in-ten problem.
Buyer
It's not two. But look, before you get excited — our closure codes are garbage. Half of them say 'other'. And the inventory doesn't match what's physically in the ground in about a third of the estate, because we inherited two networks and never reconciled them. Every vendor who's looked at our data has gone quiet after the first extract.
Rep
That's true at nearly every carrier I've worked with, and it's actually the argument for doing this off telemetry rather than tickets. The signal we're reading is performance and alarm data — port-level throughput, error counts, flap patterns — not closure codes. Bad inventory affects where you send the tech, not whether you can see the degradation coming. One of the first things that usually falls out is a list of where your inventory record and your telemetry disagree.
Buyer
Maybe. But my engineering team is mid-migration on the BSS side and has precisely zero spare cycles this year. If this needs a data model built, it's a next-financial-year conversation and probably a capex one, and the capex committee has already committed everything to the fibre-to-the-node replacement programme.
Rep
Then it shouldn't be capex and it shouldn't touch your migration. The ask is two hours from someone who can point us at the northbound feed you already publish, and your NOC lead looking at the output once a week. Read-only, out of band, we write nothing back into your ticket flow until you tell us to. If it needs more than that from your engineers before you see anything useful, we've designed it wrong.
Buyer
And if it does work, what am I supposed to do with it? Half those degradations are on the access network. I don't own the fault. I just wear the customer call and the ombudsman complaint when the tech turns up and says it's not us.
Rep
That's exactly the truck roll you shouldn't be sending, though. If L1 can see before the booking that the pattern is upstream, you raise the wholesale fault, you tell the customer the truth on the first call instead of the third, and your tech stays in the van. Fewer no-fault-founds, and fewer 'we sent someone and they said it wasn't ours' conversations — which is where a decent chunk of your complaints per 10,000 services come from.
Buyer
That last bit is the part my Head of Customer Experience would actually care about. She's the one wearing the CSG exposure when average speed of answer falls over during a regional fault.
Rep
Then let's do this. You said the problem isn't spotting the degradation, it's that the dispatch goes out anyway because L1 can't prove it's upstream. Give me thirty minutes with you and her, and I'll walk through how another RSP put an upstream-versus-in-home indicator in front of L1 before the booking was made and what it did to their no-fault-found rate. Thursday morning, or Monday after your ops review?
Buyer
Monday. And bring the number on how you handle precision — if it fires on noise, my NOC lead will kill it in the first week and he'll be right to.
Rep
Agreed, and I'd want to set that threshold with him up front rather than defend it after. I'll send an invite for Monday, thirty minutes, you, your CX lead, and your NOC lead if he'll come. One line in the invite so nobody wonders what it's about: reducing avoidable dispatch on upstream faults.
Objections you will hear
What they say, and what you say back.
| Objection | How to answer it |
|---|---|
| “Integration with our OSS/BSS stack kills most vendors. Everyone says they've got connectors and then we spend nine months on a data model.” | Fair — so let's not talk connectors. Which systems hold your fault tickets, your inventory and your dispatch? If it's a standard assurance platform plus a homegrown inventory layer, we read from the northbound feed you already publish and write nothing back until you tell us to. First phase is read-only, out of band, no change to your ticket flow. If we can't produce useful predictions off your existing alarm and performance feeds within six weeks, there's nothing to integrate and you've spent no engineering time. |
| “We've already got an assurance platform and event correlation. Why do I need another alarm source?” | You don't, and that's the point — if this generated a new alarm queue your NOC would ignore it by week three. Correlation tells you what already broke. What we're adding is a lead indicator on degradation before the customer calls, delivered into the ticket your team already works. And I'd want to agree the precision threshold with your NOC lead up front — if it fires on noise, kill it. |
| “The capex committee meets quarterly and nothing moves faster than that.” | Then we shouldn't be a capex item. This sits in opex against dispatch cost — if we take 15% of avoidable truck rolls out, it pays from the field services line, not the network build. And realistically, if the next committee is nine weeks out, that's nine weeks you could spend proving the number so you walk in with your own data instead of my slide. |
| “Our field and fault data is a mess. Half our closure codes are 'other' and the inventory doesn't match what's actually in the ground.” | That's true at nearly every carrier I've worked with, and it's the reason the prediction is worth something — the signal comes from performance and alarm telemetry, not from closure codes. Bad inventory affects where we route the dispatch, not whether we spot the degradation. And honestly, one of the first outputs is a list of where the inventory is wrong, because the telemetry doesn't match the record. |
| “Half our faults sit on the access network. We don't own the fault, so we can't fix it — we just wear the customer call.” | Right, and that's exactly the truck roll you shouldn't be sending. If you can tell before dispatch that the degradation pattern is upstream, you raise the wholesale fault, you tell the customer the truth on the first call, and you keep your technician in the van. Fewer no-fault-founds and fewer 'we sent someone and they said it wasn't us' calls — which is where a lot of your complaints come from. |
| “We're mid-migration and my engineering team has zero spare cycles this year.” | Understood — so what's the actual ask? Two hours from someone who can point us at the data feed, and a NOC lead to look at the output weekly. No integration sprint, no change window, nothing that touches the migration. If it needs more than that from your engineers before you see value, we've designed it wrong. |
| “Send me something and I'll take it to the exec. We look at this stuff once a year.” | Happy to, but a deck won't survive that room — the CFO will ask what it does to cost to serve per service and nobody will have the number. Give me one region's fault and dispatch history for the last quarter and I'll come back with how many of those dispatches were predictable and what they cost you. Then you're presenting your own data, not a vendor's. |
Questions reps ask about this call
- How is a warm call script for telecommunications different from a cold one?
A cold call has to earn the right to ask a question. A warm call already has it — the referral bought you the pickup, roughly ninety seconds of suspended disbelief, and a permission slip to be direct. What it does not buy you is interest, budget, or a problem. Telco leaders in particular have been pitched assurance and AIOps repeatedly, so the referral gets you heard, not believed. The practical difference is that you skip the credibility-building preamble entirely and spend the time on a relevance bridge instead: what the referrer's network looked like, why theirs is different, and one question about how faults actually get triaged in their shop.
- Which telco titles should the warm call actually target?
It depends on which number the referral points at. If the story is avoidable dispatch, no-fault-found rate and first-time-fix, go to the Director of Field Operations or Head of Network Operations. If it's detection and alarm noise, the GM Service Assurance or CTO. If it's post-outage cancellations and ARPU erosion from retention offers, the GM Consumer / Retention. If it's average speed of answer, CSG exposure and ombudsman complaints during a mass service disruption, the Head of Customer Experience. The COO is the right call when the problem crosses two of those and neither peer wants to fund it out of their own line.
- What do I do when they can't remember the person who referred me?
Assume it from the start — most intro emails in this market are skimmed between change approvals and never opened again. Don't make them work to remember. Say "no reason you would, it was a two-line intro," then deliver a fifteen-second re-brief with no product in it: the gap between when a segment starts degrading and when the customer rings in, or the share of dispatches that come back no-fault-found. Then re-ask for the four minutes. Arguing them into recalling the referrer burns the goodwill you were trying to spend.
- How many discovery questions should I ask on a telco warm call?
Three, four at most. This is not a booked discovery and they never agreed to an agenda. Ask one mechanical question (who decides whether a ticket becomes a dispatch or a wholesale fault), one in their numbers (truck rolls per 1,000 services, no-fault-found rate, or the 30-to-60-day churn cohort after the last material outage), and one priority test — "is that a this-quarter problem or a live-with-it problem?" Running eleven questions on a referral reads as an abuse of the introduction and gets shut down with "can you just send me a deck?"
- How do I handle the AIOps objection without sounding like the last vendor?
Concede it before they finish. Most network operations and service assurance leaders have already run a correlation overlay that fired on noise until the NOC muted it. The move is to agree that a new alarm queue is worthless, distinguish what you do from correlation (correlation explains what already broke; a lead indicator flags degradation before the customer calls), and then hand them the kill switch: offer to set the precision threshold with their NOC lead up front and agree that if it fires on noise, it gets turned off. Suspicion is reasonable here — arguing with it costs you the call.
- What counts as a successful close on a telecommunications warm call?
A diarised thirty minutes with a named second attendee and a reason built from their own sentence — not "I'll send some info." Pleasant is not progressed. If they genuinely can't commit while mid-migration or pre-committee, take a smaller real commitment instead: one region's fault and dispatch history for the last quarter, which you come back with as a count of predictable dispatches and what they cost. That way the CTO or COO walks into the capex conversation with their own data rather than your slide. Then close the loop with the referrer the same day, in two lines, or you won't get a second introduction.