Your Vendor Manages the Network. Who Is Managing the Vendor?

Published by Phillip Smith, Milewire LLC

Most utility and industrial private LTE operations follow the same pattern.

The operator signs a managed services contract with Ericsson or Nokia. The vendor manages the equipment, alarms, incident response, KPI reporting, and monthly performance package. The operator receives the report, attends a quarterly business review, and pays the invoice.

On paper, this is a clean model.

In practice, the vendor holds nearly all of the operational knowledge. The operator holds the contract, but has no independent way to verify whether the vendor is actually performing against it.

That is not a small detail. It defines the entire relationship.

SLA Credits Do Not Claim Themselves

Managed services contracts often contain SLA credits that almost nobody claims.

The contract schedule may define availability thresholds, response times, restoration targets, priority levels, credit formulas, and escalation paths. It may describe what happens when the vendor misses a threshold. It may even define how credits are calculated.

But the credit does not usually appear automatically on the next invoice.

Someone on the operator's side has to identify the breach, preserve the evidence, calculate the credit, and formally claim it according to the contract process.

Most operators are not staffed to do that.

The monthly report may show strong headline availability while hiding specific threshold misses in the detail. An SLA clock may start later than it should. A priority classification may be lower than the operational impact justified. A recurring degradation may never cross the reporting threshold the vendor chose to emphasize.

If nobody on the operator's side can read the report critically, the contract terms become theoretical.

Credits accumulate unnoticed. Performance issues become normal. The vendor may still be working hard, but the accountability mechanism is not functioning.

Vendor RCAs Need To Be Reviewed

When a major incident occurs, the vendor produces a root cause analysis.

The RCA usually arrives as a PDF some number of days later. It names a cause, summarizes impact, describes corrective action, and closes the incident.

Many operators accept the document without review.

That is understandable. A cellular RCA can involve RAN counters, core events, transport alarms, software behavior, device attach patterns, and timing details that are outside the normal skill set of an enterprise IT or OT organization.

But accepting every RCA at face value creates a problem.

Sometimes the stated cause does not match the event timeline. Sometimes the corrective action does not address the real failure mode. Sometimes the RCA explains what happened inside the vendor's system but not why the operator experienced the outage. Sometimes the incident is closed even though the underlying condition is likely to recur.

Vendors know when the customer cannot challenge the technical explanation.

That does not mean the vendor is dishonest. It means the operator has no technical counterweight in a relationship where technical judgment matters.

An RCA should answer basic operational questions. What failed? Why did it fail? How was the fault detected? When did the SLA clock start? What prevented faster resolution? What corrective action was taken? How will recurrence be measured?

If the RCA does not answer those questions, the incident is not really closed.

Escalation Paths Are Usually Too Informal

When something goes wrong, many operators email their account manager.

The account manager escalates internally. Someone responds. The relationship carries the process.

That may work for routine issues. It is not vendor governance.

Managed services contracts usually contain formal escalation paths. Those paths define severity levels, notification requirements, executive escalation points, response obligations, and sometimes contractual consequences.

Those paths often go unused because nobody has translated them into an operational procedure.

The helpdesk does not know when to invoke the contractual escalation process. The operations manager does not know what language to use. The executive sponsor may not know a formal escalation exists until a major incident has already dragged on for days.

Informal escalation depends on goodwill and memory. Formal escalation depends on documentation and practice.

For a network that supports grid operations, production lines, mines, ports, warehouses, or field crews, goodwill is not enough.

Renewal Is Where Dependency Shows Up

The vendor dependency becomes most obvious at contract renewal.

The vendor has the operational data. The vendor has the incident history. The vendor has the performance record. The vendor has the institutional knowledge. The vendor knows which issues were difficult, which sites are fragile, which configurations are unusual, and which parts of the network carry the most risk.

The operator often has an invoice history and a stack of monthly reports.

That is not a negotiation between equals.

If the operator cannot independently summarize performance, identify recurring issues, quantify service gaps, and evaluate technical recommendations, then the renewal conversation is mostly shaped by the vendor's view of reality.

This is how managed services contracts become difficult to challenge and difficult to replace. The longer the network operates without independent governance, the more leverage moves to the vendor.

What Independent Governance Looks Like

Independent vendor governance does not mean the operator has to run the network.

It means someone on the operator's side can verify the work.

That includes the ability to read a 3GPP KPI report and identify a threshold breach. It includes a documented escalation procedure that invokes the contract rather than relying only on the account manager relationship. It includes a monthly SLA compliance review that runs independent of the vendor's own narrative.

It also includes the capacity to challenge an RCA when the explanation does not hold up technically.

The goal is not to argue with the vendor. The goal is to make the managed services model work the way the contract intended.

Vendor governance is not about distrust. It is about accountability.

A managed services vendor performs better when the operator can verify performance independently. That is not a hostile relationship. It is a professional one.

Author Bio

Phillip Smith is the founder of Milewire LLC, a private LTE operations advisory firm based in Arlington, Texas. He has over 25 years of hands-on RAN and private LTE engineering experience across AT&T, Verizon, T-Mobile, Ericsson, Nokia, and Celona environments. Milewire LLC is a veteran-owned and minority-owned small business serving utilities, industrial operators, and enterprises running private wireless networks.