A tale of two ARPUs
The core problem: Telcos treat data cleanup as a prerequisite for AI, funding multi-year readiness programs that never finish because source systems keep diverging. That’s the wrong approach, because data quality is an output of connecting systems to one operational model, and the fixes that matter happen at the source rather than in a copy like a data lake. Operators need an operational ontology like the Totogi Ontology, which surfaces discrepancies, ties them to the decisions they distort, and drives their resolution at the source.
A telco just found out it had two different calculations for ARPU.
For a long time, two formulas ran in parallel, each producing its own answer to the most important question a telco asks about itself: what is a subscriber worth to us? Everyone assumed they produced the same number. They didn’t, and nobody could see it, because nobody had ever put them next to each other.
No data program found the discrepancy. No readiness initiative, no reconciliation project, and no consultant with a six-month contract caught it. Connecting the systems to the Totogi Ontology did. We didn’t just integrate the systems to each other. We connected each one to a single model of what the business means, put AI on top to answer a real business question, and let the cleanup follow.
That sequence runs backwards from what almost every AI roadmap in this industry assumes. I want to make the case that backwards is the right direction.
Get the data ready first. Then AI.
The first workstream in any telco AI strategy deck is the same: data readiness. Cleanse it. Normalize it. Reconcile it. Govern it. Once the data is ready, the thinking goes, you can finally point AI at it.
It’s logical. It’s tempting. It’s also a trap.
That’s because your data will never be perfect. You run hundreds of BSS/OSS applications, and every one of them keeps evolving on its own release schedule, owned by its own vendor, with its own definition of what a subscriber, a product, or an active line means. Reconciliation is a snapshot of a moving target. By the time your data readiness program closes one gap, two new ones have opened somewhere else, so the program gets extended and funded again next year.
So why does every roadmap still start here? Because “clean data first” is the most profitable belief in enterprise AI, and two industries are selling it to you. The consultants sell the program itself: assessments, data strategies, governance frameworks, all billed by the month, forever. A program that actually finished would end the engagement. The data companies sell the destination: one more platform where the numbers can finally agree, once you’ve moved everything into it. Consultants get paid to keep cleaning; data companies get paid to keep storing. Neither gets paid when you start AI before the data is “ready.”
None of this is on you. You inherited an estate that vendors built to stay separate, and you did the reasonable thing with the tools you were sold. I’m suggesting that this time around, we try something different.
You don’t need the data to be ready
The question I hear most from telco executives is some version of this one: when will our data be ready for AI? I’ve stopped answering it, because every honest answer means more waiting.
The question I ask back is simpler. What would make your data better than it is today? Put the discrepancies in front of the people who run the business and attach them to an important decision.
That’s exactly what happened with one operator. With its systems connected to the Totogi Ontology, we built an AI interface on top, the CEO Cockpit, that would reveal where the next dollar of network CapEx should go. Running on the Totogi Ontology, the tool allocates revenue and cost down to individual sites and subscribers, then recommends which sites to upgrade.
To make those recommendations, it needed every system to agree on revenue and cost. They didn’t. Revenue lines didn’t reconcile, cost items refused to allocate, and the two ARPU formulas sat side by side for the first time.
What I find most interesting is that the team knew something was off. Every finance team does. What they couldn’t do was point at it, and a discrepancy you can feel but can’t locate never makes it onto anyone’s priority list.
An ontology changes that. It surfaces each discrepancy with its address attached: which systems contributed which numbers, and exactly where the definitions diverge. The team knows which source to fix, no fishing expedition required.
Then the decision, informed by the data, sets the priority. While a data readiness program fixes whatever’s next in the backlog, a decision-based system fixes whatever’s getting in its way. That’s why the work that matters gets finished first, and the rest can wait.
Data-quality tools flag mismatches too, but they flag them to IT, in a report detached from the decision makers. And there they sit: unprioritized and unfinished, maybe forever.
The “extra benefit”
After the latest meeting with this operator’s CFO, we got a “WOW.” You don’t usually get a WOW from a Group CFO looking at his own cost allocation. Here’s what he told us:
“[The model] will never be perfect. We could continue to refine. But I’m very impressed and pleased with the format of the dashboard and the quality of the data. We’re getting an extra benefit of this: identifying for ourselves all of the holes in our source data… We’ve known there’s discrepancies for a long time, but it’s helping us devote resources to getting those matching to each other.”
That’s right: A CFO called the discovery of his own data problems a benefit.
Not every gap disappeared, and that’s fine. Some revenue and cost items genuinely can’t be distributed to individual sites or subscribers. Together with his team, we agreed to carry those as common revenue and cost items, and he confirmed they don’t affect the decisions they’ll make from the platform.
That’s what “ready” looks like in real life: data whose imperfections are known, bounded, and agreed on by the people accountable for the numbers.
Decisions don’t wait
The data readiness roadmap implies there’s some future moment when decisions start depending on data. Yet the reality is you set prices today on ARPU. You decide which sites to upgrade on site economics. You report these numbers to your board and shareholders every quarter. This operator was running its business trusting that its two ARPU calculations matched.
The usual fix is a data lake. It reconciles a copy, while the numbers in the source systems go right on disagreeing. At the end of the day, you’ve cleaned the reflection and left the original untouched. Every other report, workflow, and integration that reads from the source still gets the old (bad) answer.
An ontology works the other way. Because every discrepancy arrives with its address, the fix can be applied in the source system itself, and every downstream consumer inherits the correction: the finance close, the pricing model, the retention campaign, even the AI agent you haven’t built yet.
An ontology is the compounding asset. It’s an investment that pays off more with every fix. Every rule it runs on is written in plain language, has a named owner on the operator’s team, and logs every revision. When the team decides to allocate a cost differently, it changes the rule instead of the code, and the ontology (and everything else built on it) uses the new decision from that day forward.
One of the operator’s leaders pointed out that this inventory is the key to future adjustments. Each fix the CFO’s team makes at the source improves the next CapEx recommendation. The telco gets better, one resolved discrepancy at a time. And as AI agents start acting on those source systems at machine speed, that’s exactly where you want the truth to live.
Turn on the light
Here’s my suggestion. Take the budget earmarked for year two of your data readiness program and spend a fraction of it on something that shines a light on the places your systems disagree. The Totogi Ontology runs as an overlay on the systems you already have, so nothing gets ripped out.
You might find two ARPU calculations of your own.
The CFO said it best at the end of that call: “It’s mind-boggling to think how many carriers are basically shooting in the dark.”
He’s right. And the only reason he knows is that he turned on the light.
Recent Posts
Get my FREE insider newsletter, delivered every two weeks, with curated content to help telco execs across the globe move to the public cloud.
Get started
Contact Totogi today to start your cloud and AI journey and achieve up to 80% lower TCO and 20% higher ARPU.
Explore
Telco AI needs an ontology. Should operators buy one and customize it, or build their own from scratch? Here’s how to decide.
Engage
Set up a meeting to learn how the Totogi platform can unify and supercharge your legacy systems, kickstarting your AI-first transition.
Evolve
6G is different. AI is why. DR took the stage at the AI-Native Telco Forum to talk about how AI can inform your 6G decision.
Frequently Asked Questions
No. Waiting for clean data is one of the most common reasons telco AI stalls. Source systems keep changing on their own release schedules, so a data-readiness program never finishes. A faster path is to connect existing systems to one operational model, such as a telco ontology, put AI on top to answer a specific business question, and let the discrepancies surface. Data quality then becomes an output of the work rather than a prerequisite for it.
A typical telco runs hundreds of BSS/OSS applications, each evolving independently, owned by a different vendor, and carrying its own definition of a subscriber, a product, or an active line. Reconciliation captures a snapshot of a moving target, so new gaps open as old ones close. The business model reinforces the problem: consultants bill by the month for the program, and data platform vendors get paid to store the copies. Neither gets paid when the program ends.
A data lake copies data out of operational systems and reconciles the copy. The numbers agree inside the lake while the source systems keep disagreeing, so every report and workflow that reads from the source still gets the old answer. A telco ontology connects to the operational systems in place and surfaces each discrepancy with its location: which systems contributed which numbers and where the definitions diverge. The fix lands in the source system, and every downstream consumer inherits it.
An ontology improves data quality in three ways. First, it shows exactly where each discrepancy lives, so teams know which system to fix. Second, it ties each discrepancy to the business decision it distorts, so the fixes that matter most get done first. And third, it records every business rule in plain language, with a named owner and a revision history, so a change in how the business calculates something becomes a rule update instead of a code change. Each fix improves every decision that runs on the model afterward.
Most telcos still direct network CapEx primarily by traffic, because revenue, cost to serve, and network performance live in separate systems. When those systems connect to one ontology, revenue and cost can be allocated down to individual sites and subscribers. An AI application running on that model can then recommend which sites to upgrade, based on what each site actually earns and costs, across the whole network.
Different teams build ARPU formulas for different purposes. One might estimate subscriber revenue from site traffic averages, while another uses actual revenue per subscriber from billing records. Each formula is defensible on its own terms, and because the systems behind them have never been compared side by side, the business can run for a long time assuming they match. Connecting those systems to one operational model is often the first time anyone sees the gap.
An ontology runs as an overlay on the systems a telco already has, including vendor and homegrown applications, so nothing gets ripped out. The practical starting point is a single, high-value decision, such as network CapEx. Once the systems are connected to the ontology for that decision, the same model is reusable, so each additional AI use case builds on the work already done.
The Totogi Ontology is a unified operational model of a telco’s business, built on open industry standards, that sits above existing BSS, OSS, and network systems from vendors such as Amdocs, Ericsson, Huawei, and Salesforce. It gives AI a shared understanding of subscribers, products, revenue, and cost across the stack; surfaces discrepancies at their source; and records every business rule with an owner and a revision history. Telcos use it to run AI-driven decisions, such as network investment, without replacing any of their systems.