AI for Telco Enterprises: Answers Across the Silos

A regional VP asks a simple question in a Monday review: why did revenue dip in this region last month? In most telcos, that question does not get answered in the meeting. It gets assigned. Commercial pulls activation and ARPU numbers. Network checks for outages or degraded coverage in the region. Customer care checks complaint and churn volume. Finance reconciles what actually posted versus what was billed. Four teams, four systems, and a follow-up meeting scheduled for Thursday.

Telcos are, by structure, the most systems-heavy of the enterprise archetypes. A retailer might run POS and an ERP. A telco runs billing, network operations, CRM, customer care, provisioning, and finance. Each was accumulated over years, each built for its own function, and none shares a common data model. The question was never hard. Getting an answer that spans four systems is.

Why telcos accumulate silos faster than other industries

Most enterprises grow one core system and bolt satellites onto it; an FMCG distributor, for instance, tends to orbit a single ERP. Telcos grow six or seven core systems at once, because network operations, billing, and customer service each run specialized software with no reason to talk to one another. A BSS billing dispute, an OSS outage ticket, and a churned subscriber can all describe one underlying event, and none of those systems knows the other two exist.

Within any one system the records are usually clean. What no system owns is the join. Stitching a network incident to the billing account to the subscriber who eventually left is nobody's standing responsibility, so the work waits until a report forces it. The business-support stack and the operations-support stack each hold half of every cross-functional question, and neither was built to hand its half to the other.

This is also why telco AI pilots tend to stall in a specific way: a team builds a capable assistant on top of one system (usually billing or CRM, because those are the friendliest APIs) and it works well for exactly the questions that system can answer alone. The moment someone asks a question that needs network data too, the assistant either guesses or says nothing, and the pilot quietly stops expanding.

Churn signals are cross-system questions in disguise

Ask "which subscribers are likely to churn" and the honest answer pulls at least three inputs from three places: a usage or quality trend from the network and billing platforms, complaint and ticket history from customer care, and payment friction from finance. Churn even means different things across the base. A prepaid subscriber leaves silently by letting top-ups lapse, so a falling reload frequency and a climbing drop-call rate in their cell area are the only warning you get. A postpaid subscriber usually leaves a paper trail first: a dunning sequence, a billing dispute, a coverage complaint. One signal on its own is weak, since a usage dip with no complaint may be seasonal and a complaint with steady usage may be a one-off. Read together, they form a pattern worth acting on.

This is where an AI intelligence layer earns its keep in telco specifically: not by predicting churn on its own, but by making the three signals queryable in one place, so a retention team asks one question instead of running three exports and joining them by hand in a spreadsheet.

What about the enterprise and B2B division?

Consumer-side telco reporting gets the investment, because consumer volume dwarfs B2B account count. That leaves enterprise and B2B account teams waiting on a shared data function tuned for millions of consumer records, when what they need is account-level detail on a few thousand contracts: usage against commitment, SLA breaches, renewal dates, and support ticket history per account.

A layer scoped to the B2B division's own systems and accounts removes that bottleneck. The account team queries its own book of business directly: which enterprise accounts are trending under their committed usage, which contracts renew this quarter, which accounts have open SLA disputes, all without filing a request with a team whose priorities run consumer-first by necessity.

This matters more in telco than in most industries because B2B contracts carry real downside if missed: a committed-usage account trending over its cap for three months is a renegotiation waiting to happen, and an SLA breach nobody flagged internally becomes a penalty clause invoked by the customer instead. The account team catching either one a week earlier is not a convenience. It is the difference between renewing the deal on its current terms and defending it.

From deck cycle to daily brief

The Monday review exists because someone assembles the numbers by hand first, and that takes long enough to justify doing it only weekly. This is also the ceiling a static BI dashboard hits: it can chart last month's ARPU by region, but it cannot chase down why one region moved once the answer spans billing, network, and finance. An agent that queries those systems directly changes the cadence. An executive gets a daily brief covering regional revenue movement, network incidents with commercial impact, and top accounts with usage or payment anomalies, without anyone building a deck.

Whose numbers should each agent see?

A telco's divisions guard their numbers carefully, and for good reason: commercial does not want network's raw incident data leaking uncontextualized into a board deck, and finance does not want every regional manager pulling unreconciled revenue. An intelligence layer that connects everything but enforces nothing just moves the trust problem instead of solving it.

The right pattern mirrors how agents should be structured: department-scoped access, so a regional commercial lead sees commercial and customer signals for their region, a network engineer sees infrastructure data, and only cross-department roles — like the executive asking the original question — get a view that spans divisions, with the underlying permission checks intact at every layer.

This is not a hypothetical concern specific to telco — it is the same governance problem every enterprise faces, just sharper here because the divisions are more numerous and more jealously guarded than in, say, a single-plant manufacturer. Getting it wrong in either direction has a cost: over-restrict and the executive brief goes back to being manually assembled; under-restrict and you have built a faster way to leak commercially sensitive network data across the org.

Where Nalar fits

Nalar models telco as one of its industry archetypes, shaped around the divide this piece describes: BSS, OSS, customer care, and finance connected into one queryable layer, with department-scoped agents answering inside their own division and a master agent reaching across divisions only for the roles cleared to ask. Because a network engineer or a regional account manager spends the day away from a desk, the same answers reach them through WhatsApp rather than a dashboard they will not open.

The interactive demo walks a cross-system telco question from prompt to resolved answer, and BARI gives an honest read on how connectable your billing, network, and finance systems really are, including where the answer today is still "not yet."