What Should You Actually Automate First?

Most network owners and service providers we meet have the same picture in mind: AI that takes over the workflows where people today click between systems, hunt for the right piece of information, and copy data from one interface to another. Case management that runs itself. Provisioning without manual steps. Troubleshooting that points to the cause instead of just showing that something is wrong. An organization that can answer questions about its own business without someone first having to build a report.

It's a reasonable vision. In most cases, it's also technically possible today.

And yet many are standing still. Not for lack of will, and not because the technology is too immature. It's because the next question is hard to answer: where do we start, and how does it work in practice?

The Question That Stalls Everything

We most recently heard it from a customer who put it roughly like this: if there’s a clear target vision and a project plan, the decision is easy. Without one, every individual investment is hard to justify. Should we buy a new API? An integration? Build a data platform? For what purpose, and in what order?

The result is usually no decision at all. They take it away for an internal discussion about where they’re headed, and the decisions get postponed. Not because anyone said no, but because no one could say yes to anything concrete.

What’s missing is rarely ambition. It’s knowledge of where in your own operations automation actually makes a difference, and what it takes to get there.

Why It’s Harder Than It Sounds

AI in an operator environment has to work with systems that were never built for AI. Legacy applications. Databases carrying history from several generations of systems. APIs designed for integrations between two known parties, not for an agent asking open-ended questions. Authentication layers, permission models, and processes that have grown organically over time.

Then add the fact that information is scattered. Network planning knows where the fiber runs and where it physically lies. OSS knows what has been delivered and what is alarming. BSS knows what the customer is paying for. Each system is right, on its own.

This works as long as there’s a human in the middle. Experienced staff know which system applies in a given case, what the comment field really says, and which data can be ignored. It’s invisible work that is rarely documented, and often not even conscious.

An agent doesn’t do that work. It reads what is actually written, not what someone meant should be written. So when automation fails, it’s usually not because the model is too weak. It’s because the business logic lives in people rather than in systems.

That’s a risk worth taking seriously for an entirely different reason too. What happens the day that person leaves the company?

One System Only Gives You Part of the Answer

As long as a question stays within a single system, it's manageable. The problem arises when the question requires information from more than one system — which the most important business questions almost always do. A couple of examples make the problem concrete:

Can you see today how many customers you're winning and losing? Not after the fact, in a report someone built for a quarterly meeting, but continuously. And can you see how customers move between the service providers on your network, and how that affects billing? For a network owner with a wholesale business, this is fundamental information. Yet it's surprisingly often unanswered, because the answer requires both current data and history from orders, the service inventory, and billing.

Can customer service or the NOC see what's actually causing an outage? Not just that the service is down — that's visible. But where the fault is, which customers are affected, and whether it's related to ongoing work. The answer exists, but it's spread across alarm management, network documentation, the ticketing system, and field operations in progress.

In both cases the point is the same. No single system can give a complete answer. The question spans several, and whoever answers it must be able to reach all of them, understand how the data connects, and know which source takes precedence when they disagree.

That's where the idea of a unified AI layer comes in. Several of our customers are already thinking along these lines, some more concretely than others: a layer that can talk to network planning, OSS, CRM, the billing solution, and other BSS applications, and assemble the picture instead of a person doing it manually every time.

But such a layer is only as good as what feeds it. References between systems must hold. The same customer must be recognizable at every step. And every connected system needs to meet a common bar for data quality and access — otherwise the answer is just wrong faster.

Five Questions to Bring to Your Next Internal Meeting

The conversation about AI almost always starts with the model. The work starts with the workflow. Before you choose technology, ask these questions about a workflow you already know is heavy:

1. Which process are we trying to improve, and what does it cost us today?

2. Where is the data needed to make decisions in that workflow?

3. Which system governs the outcome — in other words, who has the final say when the data differs?

4. What is still manual, and why?

5. Which part of today's solution is actually holding us back?

Take one workflow at a time. Provisioning. Fault resolution. Dark fiber management. Billing data.

The answers usually fall into three categories. Some workflows are closer to automation than expected, because the data actually exists and holds up. In others, the data exists but is incomplete or has quality issues no one has had to care about before, because a person has filled in the gaps along the way. And some can't be automated at all yet, because critical information only exists in someone's head or in a free-text field.

All three answers are useful. The first gives you a starting point. The second gives you a concrete action list instead of a vague feeling that your data is a mess. The third tells you what needs to be moved into the systems before automation is even on the table.

It Starts with the Foundation

When we map this out with customers, we usually draw it as a stack.

At the bottom is the data in the systems. On top of that, the data model and processes — what determines whether quality is even possible. Then access, in the form of a data layer and well-defined APIs. After that, security and permissions, because an AI answer must be based on what that particular user is entitled to see. And at the top of the foundation is what we call trust: a concept has a definition rather than a colleague who knows how to interpret it, a number can be traced back to its source, and the answer is the same whether the question comes from a report or an agent.

Only above that comes usage — analytics and automation. And at the very top, the customer's own target vision: what should be automated, and in what order.

Value is defined from the top down. Strength comes from the bottom up. That's why the order matters.

But — and this is important — you don't need to wait for a finished target vision to get started. The moment information becomes visible and reliable, you can work with it, long before any workflow is fully automated end to end. Seeing customer churn is valuable even if the response is still manual. And it makes the target vision easier to formulate, because you then see how the business actually works rather than how you think it does.

What We Do

We're building a data warehouse designed for exactly this purpose, with definitions and traceability that hold up for both reporting and automated workflows. And we're developing MCPs — interfaces designed to let an AI query the system in a controlled way, using the same definitions as the rest of the platform.

We don't solve all of our customers' internal processes for them, and we can't fill in data that was never collected. That responsibility stays with the business. But we can show where the gaps are, what they cost in terms of workflows that can't be automated, and which order will have the greatest impact.

Where Do You Stand?

We'd love to hear your perspective. If you already have an AI strategy and a picture of where to start, we're curious to hear about it. If you don't, you're in good company — and we can help you map out where you stand today and which workflows are closest to being automated.

Get in touch and we'll set up a call.

By Ulf Engstrand - Director of R&D, Victor Andersson - BI Product Manager - Antymos Dag - BI Software Engineer, Netadmin Systems

Related links:

Closing the AI Readiness Gap in Telecom with API-First OSS/BSS Platforms

Release the Potential of AI with Netadmin MCPs

Netadmin MCP Services

Netadmin Professional Services