Telecommunications · Discovery Call
Discovery Call Questions for Telecommunications: A 25-Minute Diagnostic Playbook
You've got 25 minutes with a Head of Network Operations who has already sat through three AIOps pitches this year, or a GM Consumer who can name the suburbs that churned after the POI incident in March. They cleared the diary. They read your one-liner. If you open with logos and "we work with carriers like you," they'll be polite, they'll answer in short sentences, and they will not take the second meeting.
The surface symptom in telco is always handed over free in the first two minutes — "our truck rolls are too high," "churn spiked after the outage," "average speed of answer falls over during a mass service disruption." None of that is worth anything. The mechanism underneath it — the L1 queue that can't triage a GPON degradation without dispatching, the closure codes that are 40% "other," the retention team throwing bill credits at a base that decided to leave two billing cycles ago — only comes out if you ask a decent follow-up. And the layer beneath that, the one that moves deals, is political: which peer's budget this comes out of, what the COO promised the board about cost to serve per service, and whether the CFO already knows the per-service numbers better than the CTO does.
This playbook gives you the clock, the question set, the layering mechanic, and the objections you'll actually hear — OSS/BSS integration scar tissue, "we already have event correlation," "half our faults sit on the access network anyway," and the quarterly capex committee. Read it ten minutes before the call. Every line is meant to be said out loud.
The discovery call script
Say it in your own words. The structure is the part that matters.
- 1
0:00–2:00 — Frame (do not re-pitch)
"Thanks for clearing the time. When we spoke, you said the thing keeping you up isn't the outage itself — it's the cancellations that land in the two billing cycles after. That's what I want to dig into. Fair warning on how I run these: I'm going to ask questions for the first fifteen minutes or so. I don't want to show you anything until I know whether it's relevant to your network and your book — I'd genuinely rather tell you this isn't a fit than burn a demo slot on both of us. Still good for 25? And is there anything you want to make sure we get to, so I don't run us out of time?"
- 2
2:00–6:00 — Open one thread (pick ONE, not five)
Pick the thread that matches the title on the other end of the phone. **Head of Network Operations / GM Service Assurance:** "Walk me through how a degradation gets from the EMS to a technician in a van today. Start to finish — where does it enter, who touches it, where does it stall?" **Director of Field Operations / Field Services:** "On a bad week, what does your dispatch volume look like versus a normal week — and what proportion of those come back no-fault-found?" **GM Consumer / Retention or Head of Customer Experience:** "You mentioned churn after the POI incident. Take me back to that — what did the cancellation curve actually do, and when?" **COO / CTO:** "What made this something you're looking at now rather than last budget cycle? Something changed." Then shut up. Let them run for two minutes.
- 3
6:00–11:00 — Layer 2: the mechanism (three follow-ups before you change subject)
You are trying to get from "truck rolls are too high" to the exact step where it breaks. - "Walk me through the last one. A specific ticket — what came in, who looked at it, what did they see?" - "When it hits the L1 queue, what does the agent actually have in front of them? Can they see line performance, or just the ticket?" - "Where does that sit between your assurance platform and the dispatch system — is that a human decision or a rule?" - "Who's the person who knows, at 2am, which of those thousand events actually matters? What happens on the night they're not rostered?" - "What's the workaround the team has built? There's always one — a spreadsheet, a group chat, someone's saved query." - "When it turns out the fault is on the access side — how do you find that out? Before or after the tech is standing at the premises?" If they answer in one sentence, ask the next follow-up on the same thread. Do not move to a new topic.
- 4
11:00–16:00 — Layer 3: the cost, then "how do you know?"
Put at least two of their own metrics into the questions. Their numbers, said out loud, are what you reuse in the follow-up email. - "How many dispatches is that a month? And where does that land you on truck rolls per 1,000 services?" - "What's your fully loaded cost per truck roll — van, tech, fuel, the two-hour window?" - "What's your no-fault-found rate sitting at, and what's the target you've been given for first-time-fix?" - "On mean time to detect — what share of faults does the customer tell you about before the NOC knows?" - "During the last mass service disruption, what did average speed of answer do, and how many of those turned into complaints per 10,000 services?" - "After the outage, what did the retention team hand out — credits, downgrades, free speed tier? What did that do to ARPU in that cohort?" Then the beat almost everyone skips: **"How do you know?"** If they can't source the number, that's a finding. It means the problem is invisible to the CFO, and your first job isn't selling — it's helping them build the number. Say so. Then count to three in silence. The sentence after the pause is the one that matters.
- 5
16:00–18:00 — Layer 4: the stake
- "Who's feeling this most — is it Field Ops wearing the dispatch number, or the GM Consumer wearing the churn?" - "Whose number does this actually show up in at the exec meeting?" - "What did you commit to your COO on cost to serve per service — and by when?" - "Is the CFO across the per-service economics on the wholesale book, or is that still a network conversation?" - "If this is exactly the same in twelve months, what's the conversation you're having with the board?" Silence again after the answer. Three full seconds.
- 6
If they ask at minute 6: "So what do you actually do?"
Thirty seconds, tied to what they just told you, then hand the ball straight back. "Short version — we sit on the alarm and performance feeds you already publish and flag the services that are degrading before the customer calls, so your L1 queue can tell an on-net fault from an access-side one without sending a van to find out. That's it. But I'd be guessing at whether it matters until I understand one more thing: when a ticket comes back no-fault-found, does anyone close the loop on why?" If they push a second time, give a clean 60 seconds, then: "Can I come back to the thing you said about the L1 queue not being able to triage without dispatching? That's the part I'm not clear on." Almost everyone lets you.
- 7
18:00–20:00 — Qualify the path (never a BANT recital)
- "If you decided this was worth doing, what actually happens next in your shop? Who gets pulled in — architecture, security, procurement?" - "Have you tried to fix this before? What happened?" — the graveyard of the last failed AIOps project is your real competitor. - "What's forcing the timing — a regulator, a wholesale contract, the capex cycle, a churn number someone's already promised to fix?" - "Is this a line item that already exists — field services, contact centre, assurance tooling — or does one have to get created?" - "And if you just keep running it the current way, what does that look like at end of financial year?"
- 8
20:00–23:00 — Targeted relevance (90 seconds, only what they raised)
Do not tour the product. Address one mechanism they named. "On the access-side thing specifically — the pattern you described, where the tech gets to the premises and it's upstream. What we do there is score the degradation signature before dispatch, so the queue sees 'this looks upstream, raise a wholesale fault' instead of 'unknown, send someone.' First phase is read-only and out-of-band — we write nothing back into your ticket flow until you tell us to. And on precision: I'd want your NOC lead to set the threshold up front. If it fires on noise, your team ignores it by week three and we've both wasted a quarter. That's a real risk and I'd rather name it now." Stop. Ask: "Does that land anywhere near the problem, or have I got the wrong end of it?"
- 9
23:00–24:00 — Playback in their words
"Let me make sure I've got it. Dispatch volume is the number you've been told to cut, and the reason it's stuck is the L1 queue can't tell an on-net degradation from an access-side one without sending someone — so roughly a third come back no-fault-found. At your cost per truck roll that's the number you quoted me, per quarter. The pressure's coming from the COO because you committed to a cost-to-serve figure at the half-year, and the capex committee doesn't sit again until the second week of next quarter. Did I miss anything, or get anything wrong?" The "or get anything wrong" is where the last hidden detail falls out. Wait for it.
- 10
24:00–25:00 — Close a dated, named next step
"Based on what you've described, the useful next thing isn't a demo. It's 45 minutes with you and your NOC lead — you said Priya — where we go through one region's fault and dispatch history from last quarter and I come back with how many of those dispatches were predictable from the telemetry you already have, and what they cost you. What I'd need from you is one region, one quarter, alarms and dispatch records. No integration, no change window. I've got Tuesday at 2, or Thursday morning. Which works?" Send the invite before you hang up. Confirm out loud: who's on it, what you'll bring, what they're pulling.
- 11
What goes in the CRM
Their words, verbatim. Not your tidy summary. Good: "'We sent a tech to Ballarat three times in a fortnight and every one came back NFF — it was a CVC congestion thing the whole time. Field Ops wears the dispatch number and I wear the complaints, so nobody owns fixing it.'" Useless: "Prospect has dispatch efficiency challenges." Capture: the metric and its source, the peer whose budget it would come from, the last failed project and why it failed, the date of the next capex committee, and the exact phrase they used about the person who's exposed.
How the call actually sounds
Prospect on the left, the rep on the right.
Rep
Thanks for making the time. When we spoke you said the thing that actually hurts isn't the outage, it's what shows up 30 to 60 days later. That's what I want to dig into. I'll ask a lot of questions for the first fifteen minutes and I won't show you anything unless it's relevant — still good for 25?
Buyer
Yeah, fine. I'll tell you up front though — we've got an assurance platform and event correlation already. If this is another alarm source, we're done in five minutes. My NOC has been trained by two vendors to ignore the tool.
Rep
That's a fair position and I'd hold it too. Tell me about one of those — which tool, and what went wrong with it?
Buyer
Doesn't matter which. It fired forty times a shift, thirty-eight of them were nothing, and within a month the operators had a filter rule that binned the lot. That's the pattern. So no, I don't need more events.
Rep
Understood. Then let's leave that alone for now. Walk me through the last time a degradation ended up as a dispatch — a specific one. What came in, who looked at it, and what did they have in front of them?
Buyer
Standard. Customer calls, says the service is slow at night. L1 runs the script, reboots the CPE, nothing. It goes to the queue. Nobody in the queue can see line performance history, so they book a truck. Tech turns up, tests fine at 10am because the congestion is a 7pm problem, closes it no-fault-found.
Rep
And when it turns out it's a congestion issue on the aggregation side rather than yours — at what point in that chain does anyone find that out?
Buyer
Usually after the second or third dispatch, when someone senior finally looks at the CVC utilisation for that POI. Sometimes never. It shows up as three NFF tickets and an angry customer who's now written to the ombudsman.
Rep
How often is that? Ballpark — how many dispatches a month land as no-fault-found, and where does that put your NFF rate?
Buyer
NFF is sitting around a quarter of all dispatches. Field Ops has been told to get first-time-fix up and dispatch volume down at the same time, which is a lovely piece of executive maths.
Rep
A quarter. And your cost per truck roll — what's the fully loaded number you use internally?
Buyer
I'm not giving you that on a first call.
Rep
That's fine, don't. Different question then — is that number one you and the Director of Field Services agree on, or do you each have your own?
Buyer
...Honestly? Finance has one, Field Ops has another, and they're about forty percent apart because of how the contractor panel gets allocated. Which is part of the problem — when I go to argue for anything, the first ten minutes is arguing about the cost per truck roll instead of the truck rolls.
Rep
That's a bigger finding than the rate itself. So who's most exposed on this — is it Field Ops wearing dispatch volume, or is it you wearing mean time to detect and the complaint numbers?
Buyer
Both, but the sharp end is the GM Consumer. She can tell you which suburbs churned after which POI incident. She's carrying an annualised churn target and she's burning ARPU on retention credits to hold a base that already decided. When she's in the exec meeting, it becomes a network problem in about ninety seconds.
Rep
And what have you committed to her, or to the COO, on that?
Buyer
I said we'd cut mean time to detect this year. I've got no credible way of doing it that doesn't involve capex, and capex is committed to the fibre-to-the-node replacement programme through to next June. So it waits.
Rep
Right. Then this shouldn't be a capex conversation — if it doesn't pay out of the field services or contact centre line, it shouldn't happen. Let me play back what I've got. L1 can't triage without dispatching because they can't see line performance history, so about a quarter of dispatches come back NFF, a chunk of those are actually aggregation-side. Nobody agrees on cost per truck roll, so the business case argument starts from zero every time. And the GM Consumer is carrying churn and ARPU erosion from the retention offers she's throwing at post-outage cohorts. Anything wrong, or missing?
Buyer
That's about right. The missing bit is the contact centre — during a mass service disruption our average speed of answer falls apart and the outbound retention campaign gets paused to cover inbound. So the outage doesn't just create churn, it stops us saving anyone.
Rep
That's the part I hadn't heard. Here's what I think the next step is, and tell me if it's wrong: 45 minutes with you and whoever owns the L1 triage rules, where we take one region's alarm, fault and dispatch history from last quarter and I come back with how many of those dispatches were predictable from telemetry you already publish. Read-only, no engineering sprint. If the number's small, you've lost 45 minutes and you can tell me to go away with evidence.
Buyer
And you're not writing anything back into our ticket flow.
Rep
Nothing. Out-of-band until you decide otherwise, and I'd want your NOC lead to set the precision threshold before anything goes near an operator's screen. Tuesday at 2, or Thursday morning?
Buyer
Thursday. I'll bring the assurance lead. Don't come with slides — come with the region.
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. |
| “The capex committee meets quarterly and nothing moves faster than that.” | Then we shouldn't be a capex item. What we're proposing 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 we could spend proving the number so you walk in with your own data instead of my slide. |
| “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 you already work. And I'd want to agree the precision threshold with your NOC lead up front — if it fires on noise, kill it. |
| “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, 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 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
- What are the best opening discovery call questions for telecommunications buyers?
Open one thread matched to the title, not five. For a Head of Network Operations or GM Service Assurance: "Walk me through how a degradation gets from the EMS to a technician in a van — where does it enter, who touches it, where does it stall?" For a Director of Field Operations: "On a bad week, what does dispatch volume look like versus normal, and what share come back no-fault-found?" For a GM Consumer or Head of Customer Experience: "Take me back to the last POI incident — what did the cancellation curve do, and when?" Then stay on that one thread for three follow-ups before you change subject.
- How do I get past the surface symptom in a telco discovery call?
Telco buyers hand you the symptom free — "truck rolls are too high," "churn spiked after the outage," "ASA collapses during a mass service disruption." The mechanism only appears when you ask for a specific instance: "Walk me through the last one. What came in, who looked at it, what did they have on screen?" That's how you learn the L1 queue can't see line performance history, or that CVC utilisation for a POI only gets checked after the third dispatch. Symptoms don't build a business case. Mechanisms do.
- Which metrics should I ask about on a telecommunications discovery call?
Ask for the ones the buyer is personally measured on and always follow with "how do you know?" Useful ones: truck rolls per 1,000 services and fully loaded cost per truck roll, no-fault-found rate against the first-time-fix target, mean time to detect and what share of faults the customer reports before the NOC knows, average speed of answer during peak faults, monthly and annualised churn by cohort and region, ARPU erosion from retention credits and downgrades, cost to serve per service per month, and ombudsman complaints per 10,000 services. If they can't source a number, that's a finding — the problem is invisible to the CFO and your first job is helping build the number.
- How do I handle a Network Operations buyer who says they already have event correlation?
Agree with them immediately. "You don't need another alarm source, and if this generated a new queue your NOC would filter it out by week three." Then ask which tool burned them and what the false positive rate looked like — the graveyard of the last AIOps project is your real competitor. Draw the distinction between correlation, which tells you what already broke, and a lead indicator on degradation ahead of the customer call, delivered into the ticket they already work. Offer to let their NOC lead set the precision threshold before anything reaches an operator's screen.
- What's a good next step to close on a telecom discovery call?
Never a demo and never "I'll send some information." Prescribe a data-based session: 45 minutes with them and the person who owns L1 triage or dispatch rules, where you take one region's alarm, fault and dispatch history from last quarter and come back with how many dispatches were predictable and what they cost. Name the region, name the quarter, name the attendees, offer two specific times, and get the invite out before you hang up. It works because it puts their own data in the room instead of your slide — which is the only thing that survives the capex committee.
- How do I avoid the discovery call becoming a capex conversation that stalls for a quarter?
Raise it before they do. Say plainly that this shouldn't be a capex item — network capex is already committed to core upgrades, tower builds and node replacements, and anything unbudgeted waits. Frame it as opex against an existing line, usually field services or contact centre, and tie it to avoidable dispatch volume. Then ask the sizing question, not the budget question: "Is this a line item that already exists, or would one need to get created?" Also ask when the next committee sits — if it's nine weeks out, that's nine weeks to prove the number so they walk in with evidence.