Telecom­mu­ni­ca­tions

A telecom provider produces data without a pause: connection and network data, telemetry from radio cells and network elements, contracts and invoices, fault reports, service contacts. The volumes are large, and many questions concern live operations. Network operations, sales, finance and service work in their own systems and often arrive at different numbers.

We build data platforms that combine streaming and batch and turn these sources into consistent metrics. Business intelligence is the core. We add AI where it can be tested and people keep the decision.

Which customers does this outage hit?

The question sounds simple, and it is only simple when network and business data fit together. A line, a radio cell and a fault report have to be matchable. Otherwise it stays unclear who is affected by an outage, and service finds out from the incoming calls.

The data sits in separate worlds. On the network side there are element managers, monitoring and telemetry from radio cells, routers and the core network, often as a continuous stream. On the business side there is billing and rating with raw records of calls and data volume, plus plans, options and discounts, the customer base in the CRM, the contact center and fault management, including field service visits. Sites, assets and capacities from inventory are the basis for expansion and maintenance. We build the mapping between these worlds first and the dashboards after.

Churn and ARPU: who counts what?

Sales and finance rarely agree on these metrics. When does a cancellation count? How are changes within the provider and contract renewals treated? What belongs in ARPU when add-on services, bundles, discounts and one-off revenue are involved? Depending on the answer, two departments report different rates for the same month.

We fix these definitions in a central metric model, together with the network measures such as availability, latency, packet loss and drop rates per cell, region or technology. For faults, the model includes count, duration, time to repair and number of affected lines, and for utilization, traffic relative to capacity. Service and cancellations are especially revealing when looked at together: contacts per line, first-contact resolution and whether outages lead to cancellations.

Aggregate network data early, keep little of it

With network data, architecture decides. Events are ingested continuously and aggregated early into metrics per cell or time window. Raw data is kept only as long as someone needs it. Storing everything costs twice: storage costs and data protection risk grow while nobody ever looks at the raw data again. Data governance defines who may access which data and how long it is retained.

A data lakehouse can bring raw data, analytics and models together on the same data, and streaming pipelines connect network and business. On that base, dashboards for network operations, sales and service use the same definitions. With conversational analytics, business teams can also ask questions in a chat, provided permissions and the metric model are in good shape.

Fault prediction and AI in service

Predictive analytics can find anomalies in telemetry before customers notice them. What matters is the test against historical incidents, where hit rate and false alarms count equally. A model that keeps raising false alarms soon gets ignored in network operations and helps nobody. So we always also assess whether the alert load is acceptable. Capacity forecasts for traffic and utilization support network planning but do not replace the expertise of the planners. The models run in monitored production, including a check on whether data and network behavior have changed.

In customer service, summaries of contacts and suggested answers from vetted sources relieve the staff. Anyone who lets AI agents perform actions such as a plan change needs human approval and logs. And wherever a chatbot talks to customers directly, there must always be a way to reach a person, otherwise satisfaction suffers more than automation saves.

Communications secrecy, NIS2 and the AI Act

Traffic data may only be processed under strict purpose limits, mainly for connection setup and billing. Using it beyond that, for example for marketing or value-added services, generally requires consent or anonymization. Anonymization and access rights can be built in technically, while the legal assessment belongs with data protection and legal counsel.

Providers of public communications networks and services are among the entities covered by the NIS2 rules, which apply across the EU through national laws. National telecommunications law often adds its own security requirements. For a data platform this touches access control, logging, supply chain and recovery, among other things. Under the EU AI Act, chatbots must be recognizable as AI, and AI used as a safety component in the operation of critical digital infrastructure can count as high-risk. Whether a specific application falls under that has to be checked case by case.