Selling Into Telecom Network Ops: Alert Fatigue, Failed AIOps and a CTO Who's Heard It

The project you're competing with already happened

If you sell anything with the word "correlation" or "anomaly" in the datasheet into a carrier, the Head of Network Ops you're calling has almost certainly already bought a version of your product. It was pitched as noise reduction. It went through a security review, a network access review, a lab trial and a long procurement cycle. It got connected to two or three of the northbound feeds, not all of them, because the older element managers wouldn't play nicely. And then it started generating its own alarms.

That's the part that stays with people. Not that the platform failed to correlate. That it became one more thing in the stack that pages someone at three in the morning, and one more dashboard on a wall nobody looks at, and one more line item procurement wants explained at renewal. The ops leader who championed it had to stand in front of a CTO and account for it.

So when you dial in, you are not opening a conversation. You are joining one that's been running for a year and a half, and you're joining it late. Every question they ask you is really a question about that project. "How do you handle multi-vendor topology?" means "the last one couldn't ingest our optical layer." "What's your accuracy?" means "the last one told us it was accurate and it wasn't." "Who else in tier one is running this?" means "I am not spending my remaining credibility on another pilot."

Most reps hear those questions as objections and answer them as objections. They're not. They're the prospect telling you what happened to them. The single biggest change you can make in selling to telecom network operations is to answer the question underneath rather than the one on the surface.

What actually keeps a network ops leader up

Forget the marketing category for a second. Here's what shows up in their weekly ops review.

MTTR, and why it's a trap

Mean time to restore is the headline metric in almost every NOC I've encountered, and it's the one your slides will be judged against. It's also close to useless as a discovery topic on its own, because everyone measures it differently and everyone knows it. Some carriers start the clock at first alarm. Some start it at ticket creation, which can be a long way after first alarm. Some exclude planned maintenance, some don't, some exclude anything where the root cause turned out to be a third-party fibre cut they couldn't touch.

The useful question isn't "what's your MTTR." It's "where in that number does the time actually go." In my experience the answer is rarely the fix. It's the identification. Something degrades, a hundred devices scream, and the first stretch of the incident is three engineers on a bridge call trying to work out which of the hundred is the cause and which are downstream. If your product touches that stretch, say so precisely. If it doesn't, don't claim MTTR as your metric, because they will ask you where the time goes and you'll have nothing.

False positives, and the asymmetry nobody says out loud

Every vendor pitches noise reduction. Very few pitch what happens when the suppression is wrong. And in a carrier, those two errors are not equal. A false positive costs an engineer an hour. A false negative — a suppressed alarm that turned out to be a real service-affecting event — costs an SLA credit, a regulatory conversation if it hits emergency services routing, and the job of whoever signed off on the suppression rule.

So the ops leader is not optimising for noise reduction. They're optimising for noise reduction that they can defend in a post-incident review. That's a different product. If you understand this and say it out loud in the first call, you separate yourself from the field immediately, because the last vendor led with the reduction number and never mentioned the downside.

Truck rolls

Field dispatch is where alarm quality turns into hard money. A wrongly diagnosed fault sends an engineer to the wrong cabinet, or sends one when a remote reset would have done, or sends one without the right part so a second visit is needed. Ops leaders track this closely and CFOs understand it instantly, which makes it the best bridge between the technical buyer and the money. If your platform can improve the accuracy of the dispatch decision, that's a stronger business case than anything you'll build out of MTTR, because it converts to a line the finance team already tracks.

SLA credits and the enterprise book

Consumer outages are a brand problem. Enterprise and wholesale outages are a contractual one. Carriers write availability commitments into enterprise circuits, and breaching them pays out in credits. Ask which customer segments have the tightest commitments and how often credits get paid. You will sometimes find that the entire budget you're chasing sits under one account team who lost a big renewal after a bad quarter of outages. That's a much better story to walk into a business case with than a generic efficiency claim.

The CTO and the ops leader disagree about what "good" means

This is the thing that kills otherwise well-run deals in this vertical, and it's worth being blunt about it.

The Head of Network Ops runs a floor. Their world is shift handovers, on-call rotas, escalation paths, the tier-one engineer who quits because they're paging out four nights a week, ticket volume per shift, and whether the team trusts the tooling enough to act on it. "Good" to them means the night shift is quieter and the escalations that do come up are real. They care enormously about whether their engineers will believe the output, because a tool the floor doesn't trust is a tool the floor works around.

The CTO runs a portfolio. Their world is opex per subscriber, the cloud-native transformation programme, the ORAN commitment they made to the board, vendor count, and whether the operational model can absorb the network they're about to build. "Good" to them means fewer platforms, a credible automation roadmap, and no surprises in front of the board. They are frequently one or two abstraction levels above the alarm problem and are impatient with detail about it.

Here's the failure mode. A rep runs a strong technical discovery with the ops leader, builds real credibility on false positives and topology ingestion, then gets the CTO meeting and repeats the same conversation. The CTO hears a point tool. Point tools are exactly what the consolidation programme exists to kill. The deal doesn't get rejected, it gets deferred into an architecture review, which is where deals go to age out.

The reverse fails too. Rep leads with the transformation narrative, CTO likes it, hands it down to ops, and ops sees a rep who can't answer how the product handles a flapping interface. Ops says "we tried this, it didn't work," and the CTO has no reason to overrule the person who owns the outcome.

What works is naming the difference explicitly. In the ops conversation: "I know your CTO is going to ask why this isn't a module in something you already own. Can I give you the answer I'd give them, so you're not defending it alone?" In the CTO conversation: "Your ops team's real objection won't be the roadmap, it'll be whether they can defend a suppression to your regulator. Here's how we handle that." You're doing the internal selling for them. In a buying group this large, that's most of the job.

Why consolidation pressure hits harder here

Every enterprise has vendor rationalisation. Telecom has it worse, for structural reasons. Carriers accumulated tooling through decades of acquisitions and network generations, so the same operator is often running element managers from three vendors, an old fault management platform, a newer service assurance layer, an ITSM system, and whatever the AIOps project left behind. Procurement teams in this sector are strong, professional, and mandated to cut that count.

Which means the question you must have a real answer for is not "why are you better than competitor X." It's "why is this not a feature of something we already pay for." Your incumbent competitor is rarely another startup. It's the OSS suite the carrier already licences, plus a services engagement, plus a roadmap slide from an account team who has been in the building for fifteen years and plays golf with the CTO.

Don't argue with that head-on. Ask what the incumbent has committed to and when. Most of the time you'll find a roadmap date that has already slipped once. You don't need to attack it; you need to establish that the operational pain is happening now and the roadmap is arriving later, and then position around a specific gap rather than the whole category. Deals that survive procurement in this sector are usually the narrow ones with an owner who can articulate exactly what breaks without them.

Budget cycles also matter more than reps expect. Carrier capex and opex planning is annual, sometimes with multi-year commitments attached to network build programmes. If you find the pain in month nine of their planning year, your realistic outcome is a slot in next year's plan and a pilot in the meantime. Knowing that early changes how you forecast and stops you burning the relationship with pressure that can't produce anything.

Talking about model accuracy without triggering the reflex

Here's the trap. They ask about accuracy. You have a good number. You say it. And you have just done the exact thing the last vendor did, which means the number lands as noise and the rest of the meeting is spent on defensive questions.

What I'd do instead is refuse the frame first.

"I'll give you the number, but I want to say first that I don't think it should decide anything for you. The last platform you looked at had a good number too. What I'd rather show you is what it does when it's wrong, because that's the part you'll actually live with."

Then talk about failure behaviour. Does the system suppress silently or does it keep a visible record of what it held back? Can an engineer see why a correlation was made, in terms of topology and timing they recognise, or is it a confidence score with no reasoning attached? Can the ops team override it, and does the override teach it anything? What happens on day one before it has learned anything about their network — does it fail open and pass everything through, or does it start suppressing on defaults?

That last one matters more than any accuracy figure. A platform that fails open is a platform an ops leader can approve without personal risk. A platform that starts confident is one they'd have to defend.

And be honest about the categories you don't handle. Say the thing your product is bad at, unprompted, early. Almost every rep I have watched is terrified of this and it is the single fastest way to buy credibility with a technical buyer who has been oversold before. The demo is where this gets tested hardest, which is why the demo script for a room that's already been burned by AIOps is built around showing failure cases on purpose rather than a clean happy path.

The proof format that works: replay, not synthetic

Synthetic demos are dead in this vertical. They know the data was chosen to make the product look good, because that's what happened last time. A live demo on your own environment proves you can run a demo.

The proof that moves telecom ops leaders is a replay against their own historical incident data. You ask for an export of alarm history over a defined window, plus the incident and ticket records for the same period, ideally including a handful of majors they can describe from memory. You run your system against it offline. Then you sit down and go through, incident by incident, what your platform would have done.

Three things make this work.

First, they already know the answers. They lived through those incidents. They remember the Tuesday night when a card failure in one site lit up half the region. If you show them your correlation grouping that event correctly, they don't need to trust your methodology, they can verify it from memory. That is a completely different kind of belief than a number on a slide.

Second, it surfaces the ingestion problem early, which is where the last project actually died. If you can't parse their legacy element manager output, you find out during the replay instead of during month four of a paid pilot. Painful, but far cheaper for both sides, and telling them you'd rather find it now is itself a differentiator.

Third — and this is the part reps get wrong — you present the misses. Go in with a short list: here are the incidents we would have grouped correctly, here are the ones we'd have got partially right, and here are the two we'd have missed entirely and why. Volunteering the misses is what converts the replay from a sales artefact into an engineering conversation. Once they're debating with you about why one of the misses happened, you're inside the evaluation rather than outside it.

Getting the data out is its own negotiation. Expect anonymisation requirements, a security review, and a legal step. Ask for it early and ask for less than you want — a single region or a single technology domain is enough to prove the point and much easier to approve.

Discovery that doesn't sound like a survey

The pattern here maps closely to what works in security operations, where the same alert fatigue dynamic plays out with different vocabulary. If you want a structural template for diagnosing an operations function before pitching it, the SOC discovery playbook transfers almost directly — swap analysts for NOC engineers and detections for alarms and the sequencing holds.

The questions I'd want answered before I ever build a business case:

"Walk me through the last major you had. Not the fix — the first twenty minutes." This gets you the identification bottleneck in their own words.

"What did you buy last time to solve this, and what did it actually do?" Ask it directly. They will tell you, usually at length, and you'll learn what the internal narrative about that project is — which matters, because your deal has to survive being compared to it in a committee.

"Which alarms does the floor already ignore?" Every NOC has a list of known-noisy sources that engineers filter out by habit. That list is a map of where trust broke.

"Who has to sign off on suppressing a service-affecting alarm?" This finds your real risk owner, who is often not the person you're talking to.

"When your CTO reviews the tooling estate, where does this sit on the list?" This tells you whether you're a consolidation candidate or a consolidation casualty.

What I'd do next

If I were running a team into this vertical tomorrow, I wouldn't start with the pitch deck. I'd start by making every rep able to handle the moment where the prospect says "we've tried this, it didn't work" without flinching, without reaching for a differentiation slide, and without agreeing so hard they lose the frame. That exchange happens on nearly every first call in telecom and it's a reflex, not a knowledge gap — you can't read your way into it. It's why we built DrillCall, so reps can run that specific conversation against a sceptical Head of Network Ops until the answer stops sounding rehearsed. Then take it to a real dial and go get the alarm history.