Selling Into Telecom Network Ops: Talking to a Room That's Already Been Burned by AIOps

The failed project is already in the room

You get twenty-five minutes with a Head of Network Operations. You open your deck. Somewhere between slide two and slide four you say the word "anomaly" or "machine learning" or "correlation engine," and something goes flat in the room. The camera stays on. The nodding stops.

What happened is that you just reminded them of the last vendor.

Most network ops organizations of any size have already bought an AIOps or anomaly-detection platform. It went in with a real budget, a real integration effort, and a real executive sponsor. Then it started firing alerts. More alerts than the team could read, let alone action. The on-call engineers started filtering the tool's output into a channel nobody watched. The tuning that was supposed to happen in month two never happened, because the person who understood the model left, or was never assigned, or was assigned but also had a day job keeping the network up. By renewal, the platform was a line item with no defenders.

Nobody in your demo is going to say this out loud. They are going to sit politely and let you present, and then they are going to give you a soft no dressed up as a timing objection. The failed project does not need to be named to be the reason you lose.

So name it.

What the burn actually was

If you want to talk about the previous failure credibly, you need to understand the specific mechanics of it. "Their last tool didn't work" is not a diagnosis. There are three distinct failures that show up over and over, and they require different responses from you.

False positives at a volume nobody budgeted for

The first failure is the obvious one. A model trained on a network's telemetry with insufficient context flags everything unusual, and a live network is unusual constantly. Maintenance windows look like outages. A planned capacity migration looks like a fault. A seasonal traffic pattern the model has never seen looks like an attack.

The operational cost is not the alerts. It is what the alerts did to the humans. Once a NOC engineer learns that a channel is mostly noise, they stop reading that channel, and they stop reading it permanently. You cannot un-train that. The team's trust in automated detection is now a scarce resource that the last vendor spent.

This matters for how you sell, because it means precision beats recall in the conversation. A rep whose instinct is to say "we catch more" is talking directly into the wound. The Head of Network Ops does not want to catch more. They want to be told fewer things and be right about them.

Integration debt nobody scoped

The second failure is quieter and usually more expensive. The platform needed data. That meant SNMP polling, syslog, flow records, element management systems, the ticketing system, the CMDB, and whatever homegrown collector has been running on a box since before the current director was hired.

Each of those integrations was a project. Each one required a person who understood both the source system and the target schema. The vendor's professional services team scoped some of it. The rest landed on the network engineering team, who were already carrying a backlog. So the tool went live on partial data, which made its output worse, which made people trust it less, which made nobody want to invest the effort to finish the integrations. The loop closed on itself.

When you walk in and say "we integrate with everything," you are saying the exact sentence the last vendor said. They remember.

Nobody owned the tuning

The third failure is the one that actually killed it. Anomaly detection is not a product you install. It is a practice you staff. Someone has to review what fired, decide what was real, and feed that back. In a healthy deployment, that person exists and has time.

In most failed deployments I have heard described, that role was assumed rather than assigned. The vendor assumed the customer would do it. The customer assumed the vendor's model would learn on its own. The sponsor who signed the contract moved to another initiative. Six months in, the model was still running on its day-one configuration and everyone had quietly agreed not to mention it.

This is the most useful failure for you to understand, because it is the one you can design around in your first phase. More on that below.

Name it in the first two minutes

The instinct is to avoid the topic. Don't remind them of a bad experience with a category you belong to. That instinct is wrong, and it is wrong for a simple reason: they are already thinking about it, and pretending otherwise makes you look either naive or evasive.

Here is roughly how I would open a demo with a network ops room:

"Before I show you anything — most of the network teams I talk to have already run an anomaly detection project. Usually it fired more than the team could triage and got turned down or turned off. If that happened here, I'd rather hear about it now than find out at the end of this call, because it changes what I show you."

Then stop talking. The silence is going to feel long. Let it.

What you get back is one of three things. You get a real story, which is the best outcome, because now you are having a diagnostic conversation instead of a presentation. You get a partial deflection — "we've looked at some things" — which tells you the burn is real and probably political. Or you get a flat "no, we haven't," which is occasionally true and which you should test gently once more before believing.

The reason to do this early rather than late is that everything after it is different. If they tell you the previous tool drowned them in false positives, you can cut half your demo and spend the time on how alerts get suppressed and grouped. If they tell you the integrations never finished, you spend the time on what data you need on day one versus day ninety. You cannot make that adjustment from slide fourteen. I have written a fuller version of this in the telecom demo script for a room that's already been burned by AIOps, including what to do when the person who bought the failed tool is sitting in the meeting.

And if you are earlier than the demo — if you are still trying to get the meeting — the same principle applies to the opener. Referencing the category's failure rate on a cold call is one of the few things that makes a network ops leader stay on the line, which is most of what the telecommunications cold call script is built around.

The metrics a network buyer will actually hold you to

Once you have named the burn, the conversation moves to proof. Network operations is a numbers culture. These people run to SLAs. They will not accept "improves visibility" as an outcome. Know the four measures they think in, and know what each one means to them specifically.

Mean time to detect. How long between something going wrong and someone knowing. This is the metric most AIOps tools claim to improve and the one where the previous project probably did show some benefit — the tool did detect things faster, it just also detected a thousand things that weren't happening. Be careful here. If you lead with MTTD, you sound like the last vendor. Lead with it only alongside precision.

Mean time to resolve. How long from detection to service restored. This is the one the ops lead is measured on internally, and it is the harder one to move, because resolution involves humans, field techs, parts, and vendor escalations that your software does not control. If you claim to move MTTR, you had better be specific about which part of the resolution path you touch. "We shorten triage by giving the on-call engineer the correlated event set instead of forty raw alarms" is a claim you can defend. "We reduce MTTR" is not.

Alert-to-incident ratio. How many alerts fired for every real incident. This is the metric that describes the previous failure most precisely, and most vendors never bring it up because it is unflattering. Bring it up. Ask what theirs is today. Many teams do not measure it formally, and asking the question positions you as someone who understands the actual problem. If they do measure it, the number is a direct read on how much pain they are in.

Truck rolls avoided. This is the one with a dollar sign attached. Sending a field technician to a site costs real money in labor, vehicle, and time, and a meaningful share of those visits find nothing wrong or find something that could have been fixed remotely. If your product can distinguish a fault that needs a human on site from one that does not, that is your CFO story. The ops lead cares about it because their budget is tight. Finance cares about it because it is the only one of the four that converts cleanly to currency.

What you must not do is bring your own numbers to this fight unless you can source them. Telling a network operations leader that customers see some improvement percentage, when the number came from a marketing deck and cannot be traced to a named account with a named metric, is how you lose credibility permanently in a technical room. These are people who spend their day distinguishing signal from noise. They can smell an unfounded number. If you have a reference customer who will speak to a specific result, use that. If you do not, say what your product does mechanically and let them do the arithmetic on their own environment.

Scope phase one so it cannot repeat the last failure

This is where deals in this category are won.

The previous project failed at scale. It went in across the whole estate, took every data source it could get, and fired on everything. So the single most reassuring thing you can propose is something small enough that it structurally cannot fail the same way.

Small means a defined scope of the network — one region, one technology domain, one class of element. It means a defined set of data sources you can integrate without a six-month engineering effort, and an explicit list of what you are not connecting to in phase one. It means a defined success measure agreed before you start, ideally one of the four above, with a baseline captured first.

And it means a named tuning owner on their side, with an agreed time commitment, plus a named counterpart on yours. Say it out loud in the room:

"The reason these projects die is that nobody owns the false positive review after go-live. I'd want us to agree now who that is on your side and how much of their week it takes. If nobody has that time, I'd rather scope smaller than pretend it will happen."

That sentence closes deals. It closes them because it is the one thing the last vendor did not say, and because volunteering a reason to shrink your own deal is the strongest available signal that you are not just trying to book a number.

The diagnostic discipline here transfers well from adjacent markets. The structure I use for diagnosing a SOC before pitching it — establish current volume, establish who triages, establish what already got switched off — maps almost directly onto a NOC. Different acronyms, same failure pattern: too many alerts, not enough humans, a tool nobody defends.

The CTO and the ops lead want different things

One more split to get right, because reps routinely call the wrong one first.

The CTO or VP of Network Engineering is thinking about architecture, roadmap, and whether this fits the direction they have committed to publicly. They have opinions about automation strategy. They are the person who signed the last contract, which means they may also be the person carrying the political cost of its failure. That cuts both ways — they may be motivated to fix it, or they may be motivated to never discuss it again.

The Head of Network Ops or NOC director is thinking about this week. Their on-call rotation is thin. Their alert queue is unreadable. They got paged twice last night. They are the person whose life your product either improves or complicates, and they are the person who will kill your deal quietly by not engaging during the pilot.

You need the ops lead first. Not because they sign — often they don't — but because the CTO's first question after your meeting will be "what does the ops team think of it," and you want that answer to already exist. An ops lead who has been listened to will carry you upward. A CTO who is excited about your architecture cannot force an ops team to adopt a tool they distrust, and after the last project, distrust is the default state.

The practical sequence: earn the ops lead's honesty about what went wrong, scope a phase one that respects it, then go to the CTO with the ops lead's endorsement and a business case built on truck rolls or headcount pressure. Reverse that order and you spend three months in an evaluation that dies without anyone telling you why.

What I would do next

If I were carrying a telecom patch right now, I would write out the burn-naming opener and the tuning-owner line, and then I would say them out loud until they stopped sounding like a script — because both of them only work if they land as a genuine question rather than a technique, and the difference is entirely in delivery. That is the kind of thing I built DrillCall for: rehearsing the four or five sentences a deal actually turns on, against a buyer who pushes back, before you spend a real meeting learning them.

The category burned these buyers. You cannot undo that. What you can do is be the first vendor in the room who says so.