Telecommunications · Demo Call
The Telecommunications Product Demo Script for a Room That's Already Been Burned by AIOps
You've had the pitch call. The Head of Network Operations said yes to seeing it, the Director of Field Operations got dragged onto the invite, and someone forwarded it to the GM Service Assurance an hour ago. None of them are here to learn what your product does. They're here to find out where it breaks: whether it reads their northbound feed or needs a nine-month data model project, who on the L2 roster owns it once your implementation engineer disappears, what happens to their ticket flow at 2:40am when your platform falls over, and how many weeks before it changes a single dispatch decision.
They have also been sold this before. Somebody stood in front of them with the word AIOps on a slide, the tool fired on noise for three weeks, the night shift learned to close its tickets without reading them, and now the mention of a new alarm source makes the room go flat. That history is the actual competitor on this call — not another vendor. Which means the strongest thing you can do in the first ten minutes is show a screen that adds no new queue, and say out loud that if it fires on noise, they should kill it.
This Telecommunications product demo script is built for that room. It assumes the buyer interrupts, and treats every interruption as either a buying question or a disqualification test. It puts the numbers they're actually measured on — truck rolls per 1,000 services, no-fault-found rate, mean time to detect, average speed of answer during a mass service disruption, cost to serve per service per month — inside the demo narration rather than on a summary slide. Rehearse the detours, not the tour. The click path is a resource; the call is won on what happens when the NOC lead cuts you off ninety seconds in and asks what your precision is per shift.
The demo call script
Say it in your own words. The structure is the part that matters.
- 1
Pre-call email: confirm the stack in writing
Send this 48 hours out, not the morning of: "So I don't burn your forty minutes on screens that don't apply — three quick things: 1. What's holding your fault tickets and event correlation, and what does the northbound feed out of it look like today: a Kafka topic, a trap collector, an hourly file drop? 2. Who makes the dispatch call right now — an L1 agent following a runbook, or does workforce management auto-assign off ticket type? 3. Is anyone from field ops on the call? If field ops are in the room I'll build the pre-dispatch screen. If it's you and your assurance lead, I'll build the degradation view instead. I'd rather show you one of them properly than both badly." If they answer, you now know which demo to give. If they don't answer, ring the person who booked the meeting. Do not walk in guessing whether they're GPON, FTTN-served copper, HFC or a mix — you will use the wrong word in the first sixty seconds and the CTO will file you.
- 2
Know which three demos are in the one hour
Same screens, three different questions in three different heads. Name them silently before you start: - **Head of Network Operations / GM Service Assurance**: does this create a queue my night shift will ignore, and what's the precision? Wants the degradation view and the threshold controls. - **Director of Field Operations**: does this stop me sending a van to a fault that sits on the access network? Wants the pre-dispatch panel and nothing else. - **Head of Customer Experience / GM Consumer**: when the POI goes, do I get the affected-service list before the phones melt? Wants the MSD hour and the cohort view. - **CTO / COO**: whose budget, whose engineers, and what does it do to cost to serve per service per month? If all four are on, say out loud in the opening: "There are three different demos in this hour. I'm going to do the field ops one first because that's where the money is, and I'll hold ten minutes at the end for architecture. Shout if that order's wrong."
- 3
Opening — ninety seconds, no company slide
"Last time you told me two things. One: the POI incident in the northern region is still showing up in cancellations two billing cycles later, and your GM Consumer can name the suburbs it came out of. Two: truck rolls per 1,000 services haven't moved in three quarters and the no-fault-found rate is the line the COO circles in the pack. Still the picture, or has something shifted since we spoke?" [Let them answer. Something has usually shifted.] "Two ground rules from me. First — please stop me. If you're sitting there thinking 'that won't work on our estate', say it in the moment. That's the useful part of this call; me talking uninterrupted for forty minutes is not. Second — before I share my screen: what's the one thing that, if this can't do it, we don't need to keep talking? If it's precision, I'll start there. If it's whether this writes anything into your ticket flow, I'll start there instead." Then actually reorder the demo based on the answer. That reorder, visible to them, is worth more than any screen you'll show.
- 4
Core loop 1 — the 2:40am degradation (MTTD)
**Problem:** "It's 2:40 on a Wednesday morning. An aggregation card at your OLT in [their suburb name] starts dropping frames. Not hard down — degraded. Under what you run today, the first anyone knows is when the fourth customer rings at 7:15 and an L1 agent notices they're all on the same street." **Screen — narrate as the operator, not the software:** "This isn't a new dashboard. This is the ticket in the queue your L2 already works, with one extra field on it. The field says: eleven services behind this OLT, same degradation signature, first appeared at 02:41, confidence high. Your night operator doesn't open another tool. He opens the ticket he was going to open anyway." **Consequence:** "What changes is mean time to detect. It stops being 'when the customer tells us' and starts being 'when the telemetry tells us'. That's the number that feeds everything downstream — MTTR, unplanned outage minutes, and how many of those eleven customers ring you at all." **Check:** "Is that actually how your night shift runs it, or does the 2am operator sit on a degradation until day shift picks it up? Because if it's the second thing, this field is landing in the wrong place and I want to know now."
- 5
Core loop 2 — the pre-dispatch panel (the truck roll you shouldn't send)
This is the screen the Director of Field Operations came for. Give it the most time. **Problem:** "L1 has a customer on the phone with intermittent dropouts. No visible fault on the service, nothing in the outage tool. Under the current runbook that's a dispatch — two-hour window, van, technician, fuel." **Screen:** "Before the agent commits the dispatch, this panel says: three other services on the same GPON branch are showing the same optical power drift over the last nine days. The signature is upstream of the premises. Recommended action is not a truck — it's a wholesale fault raised at the access layer, and a truthful message to the customer." **Consequence:** "Two things stop happening. You stop paying for the no-fault-found — the one where your tech stands in the customer's lounge room and says 'it's not our end'. And you stop generating the complaint that comes out of that visit, which is a decent share of what ends up in front of the ombudsman. Your first-time-fix rate lifts without you touching field productivity at all, because you're only sending vans to faults that are actually yours to fix." **Check:** "Who owns that decision today — is it the L1 agent's judgement, or does workforce management auto-dispatch off ticket type? Because if it's automated, this panel needs to sit in front of the WFM rule, not in front of a human, and that's a different conversation."
- 6
Core loop 3 — the MSD hour (CX and retention)
Only run this if the Head of Customer Experience or the GM Consumer is on the call. If they're not, skip it — features they didn't ask about are features they now have to evaluate. **Problem:** "Fibre cut at 4:50pm on a Thursday. Four thousand services. Your average speed of answer goes from forty seconds to eleven minutes inside twenty minutes, handle times blow out, and the outbound retention campaign gets paused to cover inbound. That's a compliance clock as well as a bad afternoon." **Screen:** "This is the affected-service list, keyed to the fault, at 4:53. Not an estimate of the region — the actual service IDs. It's an export your comms team can push to IVR messaging and SMS, and it's the same list your retention team gets." **Consequence:** "Your CX lead isn't waiting for a spreadsheet from network at 9am the next morning. And your GM Consumer gets something she can't get today: the affected cohort, by suburb, before the churn shows up in the numbers thirty to sixty days later — rather than after, when the only lever left is a bill credit that trashes ARPU to save a service you lose anyway." **Check:** "How does that list reach your contact centre today, and how long after the fault?"
- 7
Handling 'will it handle X?' — get the specific first
"Will it work on our copper?" is unanswerable. Slow it down every time: "Tell me the actual case — is that FTTN-served copper where you're seeing line rate instability, or genuine DSLAM-served ADSL in the regional footprint? They're different signals and I'll give you a different answer." Then answer one of three ways, out loud: **Yes, and here it is.** Go show it live. This is the strongest thing that happens on a demo call. Don't describe it — click it. **Yes, but not how you'd expect.** "You don't see it in this panel. You see it in the daily digest, and it's a day behind. That's ugly and I'd rather you know now than find it in month three." **No.** Say no. "No. We don't run against RAN KPIs today and it isn't on this year's roadmap — this is fixed access only." Then: "How much of your complaint volume is mobile versus fixed? Because if it's mostly mobile, we should stop." Never say "we can build that." To a carrier buyer who has sat through two vendor slippages, that sentence is a memory, not a promise. And write it down visibly: "Let me note that — behaviour on bonded services. I'll come back to you Thursday with a straight answer." Then come back Thursday.
- 8
Pressure line 1 — OSS/BSS integration
Raise it before they do. What they're really asking is: how many of my engineers does this cost me and does it break at the next platform upgrade? "Let's do integration now, because I know it's where most vendors die on you. I'm not going to say the word 'connectors'. Phase one, we read. One feed — whatever your assurance platform already publishes northbound, plus performance counters. We write nothing back into your ticket flow until you tell us to, and 'tell us to' means a change window you own, not a config toggle we flip. What we do not touch: your inventory. We don't write records into your BSS. We don't create a new alarm queue — the output lands as a field on a ticket you already work, or it lands nowhere. Direction and frequency, so you can hand this to your architect: read every fifteen minutes off the feed, out of band, nothing in the fault path. If we disappear tomorrow you unplug one consumer and nothing in your OSS notices. And because your inventory doesn't match what's in the ground — nobody's does — one of the first things you get back is a list of where the telemetry disagrees with the record. That's a by-product, not the product, but people tend to want it."
- 9
Pressure line 2 — who owns it after you leave
"Ongoing ownership: one NOC lead, roughly an hour a week. It's threshold tuning and reviewing what fired — it isn't engineering work and it doesn't need a developer. If that person goes on leave, nothing stops; the predictions keep landing on tickets, nobody's tuning them for a fortnight. On my side: an implementation engineer for the first six weeks, and then the same person stays on as your contact. You don't get handed to a support queue after go-live — you'd have my engineer's mobile and mine. What I won't pretend: if you want us writing back into dispatch decisions in phase two, that does need someone technical on your side for a couple of weeks. I'd rather say that now than have it turn up at contract stage."
- 10
Pressure line 3 — what happens at 2am when it falls over
Never answer this with an uptime percentage. They will stop listening. "Here's the failure mode, which is more useful than a number. We sit out of band and read-only. If we fall over at two in the morning, your alarms still arrive, your correlation still runs, your tickets still open and your night shift works exactly the way they did before we turned up. What you lose is the lead-indicator field on new tickets. You don't lose a ticket, you don't lose a fault, you don't lose a dispatch. Support: P1 is a phone number and a human answers it, any hour. P3 is email and next business day — I'm not going to dress that up. And if you ask me about our last incident I'll tell you what it was and how long it took. I'd rather do that than claim we've never had one."
- 11
Pressure line 4 — time to value, in three dates
Split it. One date is a lie; three dates are a plan. "**Live** — week two. We're reading your feed and producing output. Nothing has changed for anybody in your business. **Useful** — around week six. Your NOC lead is reviewing the predictions at the Monday meeting and telling me which ones were noise. That's the honest point at which you know whether this works on your estate, and it's also the point you'd walk away if it doesn't. **Actually changing a decision** — one region, next quarter, when field ops trusts the pre-dispatch panel enough to change the runbook. Not before. If a vendor tells you they'll be changing dispatch policy in week three, they've never worked inside a NOC. What you have to do, and I'd rather over-state it: one quarter of fault and dispatch history for one region, feed credentials, about two hours from someone who knows where the data lives, and thirty minutes a week from a NOC lead. That's the whole ask. If it needs more than that from your engineers before you see something, we've designed it wrong."
- 12
Reading the room and recovering
Telco-specific tells: the Head of Network Operations goes quiet the moment you show something that looks like a dashboard he already owns. The Director of Field Operations starts answering in two words when you drift off dispatch. Someone's camera goes off during the architecture bit. Stop. Do not talk faster and do not add a feature. Pick one: - "I've been talking a while — is this the part you care about, or should I jump to the pre-dispatch screen?" - "Let me stop the tour. What's the thing you're worried about that I haven't gone near?" - "Do you want to drive? Tell me what to click." Almost nobody offers this and it works. - "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?" Losing twenty minutes of a demo to save the deal is a good trade. Pushing through to the end of your click path so you can say you finished is not.
- 13
Closing — gaps out loud, next thing booked live
"Let me give you back what I heard. Three things landed: the pre-dispatch panel, the fact this doesn't create a new queue, and that phase one writes nothing. Two are open: whether we get useful signal off fifteen-minute polled counters on your copper estate, and what your assurance platform upgrade in March does to the feed. I'll have both answered by Thursday, in writing. Where does this sit for you now — worth pursuing, or is there something that's already ruled it out?" [Let them say no. A clean no beats four weeks of chasing.] "Who else needs to see it? I'd run a twenty-minute version for your GM Consumer that's only the cohort view — churn by region after an incident, nothing else. And if your CFO's going to be in the room eventually, the only slide he'll care about is cost to serve per service per month, so let's build that off your numbers, not mine. Last thing before we drop off — can we get the next one in the diary now? I've got your calendar open. And send me one region's fault and dispatch history for last quarter; I'll come back with how many of those dispatches were predictable and what they cost you, so you're presenting your own data instead of my slide." Within 24 hours: the gap list with answers, the four screens that mattered, the architecture and security doc if the CTO's people were on, and a one-line list of what you need from them.
- 14
Language that works vs. language that loses the NOC
| Instead of | Say | |---|---| | "Our AI-powered assurance platform..." | "This is the ticket your L2 already works, with one extra field on it." | | "We integrate with all major OSS/BSS." | "We read one northbound feed. We write nothing back until you tell us to." | | "Predictive analytics for network health." | "Nine days of optical power drift on the same GPON branch before the customer rings." | | "We reduce operational costs." | "That's a truck you don't send. Your no-fault-found rate is the line it comes off." | | "We can build that." | "No, we don't do that today. How often does it come up?" | | "99.95% uptime, backed by SLA." | "If we fall over at 2am, your fault flow doesn't change. You lose one field on new tickets." | | "Most carriers see ROI in six months." | "Reading your feed week two. Your NOC lead judging it week six. Dispatch policy next quarter." |
How the call actually sounds
Prospect on the left, the rep on the right.
Rep
Before I share anything — last time you said the POI incident up north is still turning up in cancellations two billing cycles later, and that truck rolls per 1,000 services haven't shifted in three quarters. Still the picture, or has something changed?
Buyer
It's the picture. Don't share your screen yet. What's your false positive rate?
Rep
Per what, though? Per event, per service, or per shift? Because per event I can give you a flattering number that means nothing to your night operator.
Buyer
Per shift. My 2am operator has six screens open. The last mob who sat in that chair had us firing four hundred tickets a week and maybe forty were real. By week three the night shift was bulk-closing them without reading. I'm not doing that again.
Rep
Then we should agree the precision threshold with your NOC lead before anything goes live, and we should set it stupidly high to start — fewer, boring, correct. And this doesn't create a queue. There's no new inbox. The output is a field on the ticket your L2 already opens. If it fires on noise, you turn the field off and your operator's day is identical to today. Can I show you where that threshold lives?
Buyer
In a minute. Our northbound feed isn't streaming telemetry. It's fifteen-minute polled SNMP off the collector, and on the copper estate some of it's hourly. So your lead-time story is dead before you start.
Rep
It changes what we can and can't claim, so let me split it. On slow degradations — optical power drift on a GPON branch, line rate instability creeping over a week — fifteen-minute polling is fine. You're looking at days of lead time, not minutes. On sudden hard-down, fifteen-minute polling gives you nothing useful, and I'm not going to pretend otherwise.
Buyer
So you can't predict a fibre cut.
Rep
No. Nobody can predict a backhoe. What we can do is stop you dispatching to the four hundred services that were already degrading before the cut, and give your CX team the affected-service list at 4:53 instead of 9am the next morning. Different problem, and if the fibre cut is what you're buying for, we're the wrong vendor.
Buyer
The dispatch bit is what field ops care about. But half our faults sit on the access network. We don't own them. We just wear the call and then the technician stands there telling the customer it's not our end.
Rep
That's exactly the van we're trying to keep in the depot. Let me show you this one screen. L1's got a customer with dropouts, no visible fault, current runbook says dispatch. This panel says three other services on the same branch are showing the same signature and it's upstream of the premises. Recommended action isn't a truck — it's a wholesale fault raised and a truthful message to the customer. That's a no-fault-found you didn't pay for, and a complaint you didn't generate.
Buyer
How would you even measure that? Sixty per cent of our closure codes are 'other'. My field data is rubbish and I'll be honest, our inventory doesn't match what's actually in the ground either.
Rep
The prediction doesn't come from closure codes — it comes from performance and alarm telemetry, so the rubbish closure codes don't poison it. For measurement I wouldn't use them either. I'd use dispatch cost and repeat dispatch within thirty days on the same service, against a control region you pick. And on inventory — bad records affect where we route the van, not whether we spot the degradation. One of the first things you get back is a list of where telemetry and record disagree.
Buyer
Fine. Who's on the hook at two in the morning when your platform is the thing that's down?
Rep
Nobody on your side, because nothing stops. We sit out of band, read-only. Alarms arrive, correlation runs, tickets open, dispatch goes. You lose the extra field on new tickets and that's the whole blast radius. P1 for us is a phone number with a human on it, any hour.
Buyer
And what does this cost my engineering team? We're mid-migration, I've got zero spare cycles this year, and capex committee doesn't sit again until March.
Rep
Two hours from someone who can point us at the feed, and thirty minutes a week from a NOC lead to tell me which predictions were noise. No integration sprint, no change window, nothing near the migration. And this shouldn't go to capex at all — it comes off the field services line, because that's where the saving lands. If March is nine weeks away, that's nine weeks we could spend proving the number so you walk into that room with your own data. Send me one region's fault and dispatch history for last quarter and I'll tell you how many of those were predictable.
Buyer
One region. Northern. If the precision looks like the last vendor's, I'll tell you and we're done.
Rep
That's the deal I want. Can we put the review in the diary now — three weeks from Thursday, you, your NOC lead, and I'll bring the numbers with the misses shown, not just the hits.
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. Phase one 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 would I want another alarm source?” | You wouldn't, and that's the point — if this created a new queue your NOC would be ignoring it by week three. Correlation tells you what already broke. This is a lead indicator on degradation before the customer calls, and it lands as a field on the ticket your L2 already works, not as an inbox. I'd want to agree the precision threshold with your NOC lead before go-live, and set it high enough that it's boring. 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 it takes a meaningful share of avoidable truck rolls out, it pays from the field services line, not the network build. And if the next committee is nine weeks out, that's nine weeks we could spend proving the number on one region 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 in the ground.” | That's true at nearly every carrier I've worked with, and it's part of why 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 one of the first outputs is a list of where the telemetry disagrees with the record, which is usually the first honest inventory audit anyone's had in years. |
| “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 your technician stays in the van. Fewer no-fault-founds, and fewer of the 'we sent someone and they said it wasn't us' calls — which is where a lot of your complaint volume comes from in the first place. |
| “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 team. 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 per month and nobody will have the number. Give me one region's fault and dispatch history for last quarter and I'll come back with how many of those dispatches were predictable and what they cost. Then you're presenting your own data with your name on it, not a vendor's. |
Questions reps ask about this call
- How is a telecommunications product demo script different from a normal SaaS demo script?
The buyer set is technical and adversarial by role, and they've usually been burned by an assurance or AIOps purchase before. A generic script opens with a dashboard; a telco script opens by naming what you don't touch — the ticket flow, the inventory, the fault path. Interruptions also arrive earlier and harder, because a Head of Network Operations disqualifies on precision and integration surface before they'll look at any screen. Build the script so the first ten minutes can be reordered live around whichever deal-breaker they name.
- What should I prepare before a demo with a CTO, Head of Network Operations and Director of Field Operations on the same call?
Confirm the stack in writing beforehand: what holds fault tickets, what the northbound feed physically looks like, and whether dispatch is a human decision or a workforce management rule. Then pre-build two or three screens tied to the pain they named last time — usually the pre-dispatch panel and the degradation view — and decide what you will not show. Say out loud in the opening that there are three different demos in the hour and which order you're running them in, so the field ops leader knows their part is coming.
- How do I handle the false-positive question without sounding defensive?
Ask them to specify the denominator — per event, per service, or per shift — because per shift is the only one their night operator experiences. Then concede the history: a tool that fires on noise gets bulk-closed by week three, and you'd expect the same. Offer to set the precision threshold with their NOC lead before go-live and to start it deliberately high. The strongest position is that your output adds no new queue, so the worst case is they turn one field off.
- Which metrics should I put inside the demo narration?
Use the ones they're reviewed on, spoken as part of the workflow rather than as claims: truck rolls per 1,000 services and no-fault-found rate on the pre-dispatch screen, mean time to detect on the degradation view, average speed of answer during a mass service disruption on the CX screen, and cost to serve per service per month when the CFO or COO is in the room. Never attach a percentage improvement to them that you can't source — agree the baseline with the buyer and let them supply the number.
- What's the biggest mistake reps make on a telco demo call?
Two, usually together. Running the rehearsed tour — setup screens, then a dashboard — before showing the one workflow the buyer complained about on the pitch call. And saying "we can build that" or "that's on the roadmap" to dodge a no. To a carrier buyer who's already lived through a vendor slippage on an OSS project, that phrase is the exact sentence they heard last time. A flat "no, not today, and not this year" followed by "how often does that come up?" keeps far more deals alive.
- How can I rehearse the interruptions rather than the click path?
Practise the detours out loud, in order of likelihood: precision per shift, polled versus streaming telemetry, access-network faults you don't own, rubbish closure codes, no engineering cycles mid-migration, and the quarterly capex committee. Run them as live voice roleplay with a buyer persona who interrupts inside ninety seconds — that's what DrillCall is for — until each answer is short enough to give without a slide, and until you can say "no" cleanly and keep going.