Selling Into Telecom Network Ops: Why 'AIOps' Is a Dirty Word in the NOC

The word that gets you hung up on

Say "AIOps" in the first thirty seconds of a call with a Head of Network Operations and you have told them something about yourself before you've said anything about your product. You've told them you are the fourth vendor this quarter with the same deck. You've told them you read the same analyst page everyone else read. And you have handed them a clean, polite exit that costs them nothing: "We already have something for that."

They do. That's exactly the problem.

Almost every network operations leader I have spoken to in telecom has already signed a contract for a platform that promised to cut alarm noise, correlate events, and surface the root cause before the ticket ever got written. Some of those platforms are still running. A few of them are even useful. But the pattern I hear over and over is the same one: the thing got installed, it got a dashboard, the dashboard got a wall mount, and within a couple of quarters the shift leads were back to working off the same alarm queue they worked off before, with one extra screen glowing in the corner that nobody looks at.

That is the room you are calling into. Not a room that doesn't understand the category. A room that understands it too well, from the wrong side.

What actually happened the last time they bought this

If you want to sell into a NOC you need to be able to describe their last purchase back to them more accurately than they expected a stranger to be able to. Not to be clever. To buy yourself the next two minutes.

Here is the scar tissue, as I understand it from the operators I've talked to.

The correlation engine nobody had time to tune

Correlation is the whole promise. Take a thousand alarms from a single upstream failure and roll them into one actionable event. It works, in demos, on the vendor's data.

Then it lands in a real network with a mix of legacy element managers, a transport layer that was inherited through an acquisition, three naming conventions for the same site, and a CMDB that has been wrong since a reorg two years ago. Correlation rules run on topology and topology runs on data quality. The engine is only as good as the model underneath it, and building that model is not a vendor task. It is an internal project that requires the same engineers who are currently carrying the pager.

So it gets tuned for the first two or three fault domains, the ones covered during the deployment sprint, and then the professional services hours run out. Everything else falls through as raw alarms. Now the NOC has a system that is smart about a slice of the network and silent about the rest, which is arguably worse than one that is dumb about all of it, because nobody can remember which slice is which at three in the morning.

The false positive tax

An alarm suppression system that suppresses one real event has spent its credibility. Once, permanently. It doesn't matter what it caught the other times.

This is the piece that sales people consistently underweight. In a NOC, a false negative is a customer-affecting outage that nobody saw coming, and it goes into an incident review with names attached. A false positive is a wasted truck roll or a tech woken up for nothing, which is expensive and annoying but survivable. So the entire operational culture is biased toward keeping noise rather than risking silence. When you walk in offering to reduce alarm volume, part of the room hears "we will hide things from you."

They will not say that out loud on a first call. They will say "send me some information."

The vendor who disappeared after go-live

The last one is the simplest and the most damaging. Somebody sold a platform, somebody deployed it, and then the account team changed, the implementation partner rotated off, and the ongoing tuning that the whole value proposition depended on became a ticket queue with a four-day SLA. Networks change constantly. New sites, new vendors, new firmware, a fresh set of alarm types after every upgrade cycle. A correlation model that isn't maintained decays on a schedule.

When your prospect is quiet and slightly cold on a first call, this is often what they're being quiet about. They don't think your software is fake. They think you personally will not be there in eighteen months. Nothing in your deck addresses that, which is why the deck isn't working.

Stop selling the category. Sell the shift.

Here is the shift in language that changes calls for me. The category name describes what your product is. The NOC does not buy what your product is. They buy a change to a number they already report on, and they have a specific, short list of those numbers.

Talk about ticket volume per shift. Talk about mean time to isolate. Talk about what happens at 2am when a fibre cut hits three regions at once. Those are the units the room counts in. Use them and you sound like an operator. Use "AI-driven observability" and you sound like the last four people.

Ticket volume per shift

Every NOC I've encountered knows roughly how many tickets a shift absorbs and how many of those are junk. The junk has a name locally — flapping ports, chronic alarms, the site that reports a power fault every time it rains. This is the most concrete, least abstract thing in their world and it is a much better opening than noise reduction as a concept.

What that sounds like on a call:

"When your overnight shift comes on, how many of the tickets in the queue are ones they've seen before that week? I'm not asking for a number off the top of your head. I'm asking whether there's a handful of sites everybody knows by name."

There always is. And now they are telling you about their network instead of listening to you talk about yours. If you want the full structure for getting to that point on a first call, I laid out how I open a cold call with a CTO or Head of Network Ops who did not ask to hear from you, including what to do in the first eight seconds when they're clearly busy.

Mean time to isolate, not mean time to repair

MTTR is a boardroom number and it is contaminated by things the NOC does not control — truck rolls, spares availability, whether the fault is on a partner's segment, permit windows for a dig. Mention MTTR and you are asking an operations leader to be accountable for a metric they can only partially move.

Mean time to isolate is theirs. From the first alarm to knowing which element, which span, which card. That is the piece a correlation and enrichment tool genuinely touches, and it is the piece the NOC gets judged on internally even when the external metric is repair time.

Ask about it directly:

"Where does the time actually go between the first alarm and somebody knowing what broke? Is it finding it, or is it proving it to the field team so they'll roll?"

That second half of the question is the one that gets a real answer. In a lot of organisations the bottleneck is not detection at all. It's the internal negotiation between the NOC and field operations about whether the fault is real and whose it is. If that's the actual problem and you show up selling faster detection, you're solving the part that already works.

The 2am three-region event

This is the story every network ops leader has, and it is the single best discovery device I know. A fibre cut, a power event at a core site, a bad config push — something that lit up multiple regions at once and turned the board into a wall of red.

"Tell me about the last event where the board went solid red across more than one region. What did the first twenty minutes look like?"

Then shut up. What comes back is a narrative, not a metric, and the narrative contains everything you need: who got called, how many bridges got opened, whether anyone trusted the correlation output or went straight to the raw alarms, how long it took before somebody had a picture the exec on the bridge would accept. You will hear the exact moment their existing platform stopped being useful. That moment is your product's job description, in their words, which you now get to repeat back for the rest of the cycle.

This kind of narrative discovery is not unique to telecom, by the way. The same approach works with grid operators and asset-heavy utilities, and I put the timing and question order for that into a 25-minute discovery playbook for network and asset buyers that transfers over almost cleanly.

The one question that separates a pilot from an evaluation

Here it is:

"If this worked exactly the way I'm describing, whose day changes first — and have you talked to them about it?"

That's it. It sounds soft. It is the sharpest qualifier I have found for this buyer.

A NOC that will only ever evaluate answers in the abstract. "It would help the team broadly." "We'd need to look at how it fits the roadmap." "Operations would benefit." Nobody named. No conversation has happened. What you are talking to is an architecture or strategy function doing category research, possibly to build an internal business case, possibly to renegotiate with the incumbent, possibly because someone upstairs asked what they were doing about AI. They will take every meeting you offer and they will never sign anything, because the person whose day changes has not been consulted and will not accept a tool that arrives from above.

A NOC that will pilot answers with a name and a grievance. "Marcus runs the overnight shift and he's been complaining about the transport alarms since we cut over." "Our tier two leads spend their whole morning triaging the same chronic sites." That person exists, they have already said the thing out loud, and your champion has already heard them say it. That's a live wound with an owner. Pilots happen around wounds with owners.

The follow-up matters as much as the question. If you get a name, get to that person. "Would it make sense to have Marcus on the next call? I'd rather show this to the person who'd be using it at 2am than build a version of the demo that only makes sense to the two of us." Almost nobody refuses that, and the shift lead in the room changes the entire character of the second meeting. They will ask the hostile, specific, operational questions that a strategy buyer never asks — and every one of those questions is a buying signal, because people don't interrogate tools they have no intention of running.

Handling the objection you will absolutely get

"We already have a platform for this."

Do not compete with it. Do not ask what they're using so you can explain why yours is better. That is the reflex and it loses.

What I'd say:

"Good — most people do. I'm not trying to replace it, and honestly if the correlation is tuned well I'd be wasting your time. What I'm curious about is the stuff that falls outside the model. When you brought new sites on after the last integration, did those alarm types get picked up, or are they still coming through raw?"

You have just done three things. You have refused the replacement fight, which lowers the defences immediately. You have signalled that you know the failure mode is scope, not capability. And you have asked a question that only has one honest answer, because the model is never fully current. Every acquisition, every vendor swap, every firmware cycle pushes fresh alarm types into the queue faster than anyone tunes rules for them.

The wedge in this market is almost never "our engine is smarter." It's "here is the part of your network your engine has never seen."

What the demo has to survive

The demo is where most of these deals actually die, and they die for a reason that has nothing to do with product quality. The room has been burned. They are not watching your feature set. They are watching for the specific moment where you show them clean, synthetic, well-behaved data and expect them to imagine it on their mess.

So don't. Show something ugly. Show a case where the correlation got it wrong and explain how the operator overrides it and what the system learns. Show what happens with an alarm type the model has never encountered — because their network will throw one at you in week two and if you haven't answered that question they will assume you were hiding it. I wrote a full structure for this in the telecom demo script for a room that's already been burned, and the core of it is that you earn the second half of the meeting by volunteering the limitation before anyone has to dig for it.

The other thing the demo has to survive is the vanishing-vendor fear. Address it directly, unprompted, out loud: who is tuning this in month nine, what the cadence is, what happens when their network changes. If your company has a real answer, say it plainly. If it doesn't, you have a bigger problem than a script.

Where I'd start this week

Pick your ten best network operations accounts and rewrite the opening line on every one of them so the category name does not appear. Replace it with a question about their overnight queue or their last multi-region event. That's a twenty-minute exercise and it will change what your calls sound like by Thursday.

Then go say it out loud somewhere other than a live prospect. The reason reps default to the category name under pressure is that it's the phrase they've rehearsed most, and pressure pulls you toward whatever is most rehearsed. That's the whole reason I built DrillCall — so you can run the fibre-cut question and the "we already have a platform" objection against something that pushes back, a dozen times, before you spend a real Head of Network Ops on your first attempt. Whatever you use, drill the second question rather than the opener. The opener gets you five seconds. The second question is where the call is actually won.