Machine Learning for Telecom and Internet Providers

Telecoms data is plentiful and split in two

Few industries generate as much useful data as telecoms. Every router reports line stats, every cabinet reports alarms, every customer has a billing history and a support record. The large operators have used this for years. Regional fibre altnets, wireless ISPs, business connectivity providers and MVNOs are now in a position to do the same, often with a team of a few dozen people.

Picture a regional fibre operator with 60,000 connected homes. It spends heavily on acquisition, loses customers at the end of their minimum term, and sends engineers to homes where the fault turns out to be the customer's own Wi-Fi. Each of those three costs is a prediction problem, and the data to address them already exists. It is just that network data lives in the OSS and monitoring tools while customer data lives in billing and the CRM, and nobody has joined them.

Telecom machine learning use cases

• Churn prediction. Identifying customers likely to leave at or before contract end, using usage, faults, support contacts, speed tests and pricing history.
• Truck roll avoidance. Predicting whether a reported fault is in the network, the premises equipment or the home Wi-Fi, so engineers only go when needed.
• Network fault prediction. Spotting degrading optical signal levels, rising errors or equipment alarms before customers notice.
• Alarm correlation. Grouping hundreds of related alarms into one probable root cause for the network operations centre.
• Capacity planning. Forecasting traffic growth per area or link, so upgrades happen before congestion.
• Fraud detection. Catching SIM swap fraud, subscription fraud and unusual international call patterns.
• Next best offer. Suggesting upgrades that fit a customer's usage, rather than blanket promotions.

Churn: model it together with the network

Most churn models in telecoms use billing and contract data only. They find the obvious: customers near contract end, on older tariffs, with recent price rises. What they miss is the experience signal. A customer whose line dropped four times last month and who ran eleven speed tests is telling you something billing data cannot see.

Joining network quality data to customer records usually improves churn prediction noticeably, and it points to a fix rather than just a discount: send a proactive engineer, replace the router, or offer a mesh Wi-Fi unit. The mechanics of building and using churn scores are covered in our guide to churn prediction models.

The cheapest retention offer is fixing the connection the customer is quietly unhappy with.

Keep regulation in mind. In the UK, Ofcom rules require end-of-contract notifications and best tariff information, and fairness rules make it risky to offer loyal customers worse deals than new ones. Use churn scores to target service and genuine offers, and check them against those obligations.

Truck roll avoidance pays for itself fastest

An engineer visit is expensive, and a significant share of visits for many ISPs find no network fault. A model trained on past faults, combining line diagnostics, router telemetry, the customer's description and the eventual resolution, can predict the likely cause while the customer is still on the phone or chat.

1. Pull historic fault tickets with their final resolution codes
2. Join them to line and router data from the hours before the report
3. Train a model predicting where the fault lies
4. Give support agents the prediction and a recommended script
5. Track visits avoided, and repeat contacts, to confirm customers were actually fixed

The last step matters. Avoiding a visit only to have the customer call back three days later is not a saving. Where support runs through chat, the same prediction can guide a support chatbot through diagnostics before a human is needed.

Data sources and their usual problems

Resolution codes are the recurring weak spot. If agents close tickets with whichever code is first in the list, the model learns nothing about causes. Tidying the code list and training the team is cheap and makes most fault-related models possible. Anomaly methods for network telemetry are covered in anomaly detection for business operations.

Costs, and when to wait

Indicative ranges: joining network and customer data into one analytics store, eight to twelve weeks; a churn model with retention campaign integration, six to ten weeks after that; truck roll avoidance for support agents, ten to fourteen weeks; network fault prediction, heavily dependent on how much telemetry history exists.

Wait if you are still in heavy build-out with few customers past their first contract term, because there is little churn history to learn from. The same applies if detailed telemetry is not stored beyond a few days. Start keeping it now, and model in six months.

How we would approach it

SpiderHunts would usually start with truck roll avoidance or churn, whichever costs you more, and both begin with the same step: joining network and customer data at the level of one connection. That joined dataset becomes the foundation for every later model. Our machine learning services page explains how we take a model from backtest to something your support and retention teams use every day.

Frequently asked questions