Telecom
Network and customer data in one model, so the operation can act before a problem reaches either the customer or the report.
the entity here isa line, or a cellWhat the model actually reads
No aggregation, no feature engineering — the events your systems already write, in the order they happened.
- CDRs
- data sessions
- cell handovers
- network alarms
- top-ups and plan changes
- support tickets
What breaks with one model per problem
Network and CRM never meet
The reason a customer is leaving is usually in the network data, and the reason a cell matters is usually in the CRM.
The volume defeats aggregation
Billions of events a day is precisely the regime where summarising first throws away the signal.
Maintenance is scheduled, not predicted
A model that reads alarm sequences knows which site is about to degrade, and which one can wait.
One foundation, a specialisation per question
Each of these is a head on the same trained model, not a separate project with its own pipeline.
Next Best Offer
One offer per line per moment, ranked by what that line has actually done.
Network optimisation
Capacity where the demand is going to be, read from the movement of the traffic itself.
Predictive maintenance
The alarm sequence that precedes a failure is learnable. The calendar is not.
Fraud detection
Subscription and usage fraud show up as a shape in the sequence well before they show up in the bill.
What we can point at
of at-risk customers identified before the cancellation call
more accurate predictions than the scorecards they replace
faster training cycles