A cancellation request is the end of the story, not its beginning. The subscriber made the decision weeks ago: after the third ticket about the same problem, after the call where they were promised a callback that never came, after the evening a neighbor showed off the speed on another provider. By the time the paperwork lands on the desk, there is nothing left to retain.
The good news: almost all of these signals are on record. They sit in the ticketing system, in call recordings, in billing. The bad news: in that raw form, no one reads them – the volumes are too large. A supervisor physically cannot re-listen to thousands of calls, and a billing analyst has no idea the subscriber was fuming in chat yesterday. In our reviews with telecom operators we see the same picture again and again: there is enough data to predict churn, what is missing is someone to pull it together for each subscriber. That is exactly the work the platform takes on.
Which signals appear before the request?
A subscriber almost never leaves quietly. The trail usually looks like this:
- repeat tickets about one problem – three speed complaints in two weeks speak louder than any loyalty survey;
- irritation in conversations: "how much longer," "this is the third time I'm explaining" – picked up from the call transcript along with the topic;
- questions about cancellation terms, remaining contract balance, number porting – the most direct signal there is;
- a drop in usage in billing: traffic and payments fall when the subscriber is already trying out a competitor;
- a broken promise: the operator said "we'll call back within the day" – and it has been silent for two days now;
- a competitor mentioned by name in a call or chat, especially next to the word "plan."
On its own, each signal is weak. The strength is in the sum and in the momentum: two weak signals in one week weigh more than one strong signal three months ago. For B2B customers the picture is even sharper: before they leave there is almost always a series of formally closed tickets and a call asking "how do I cancel without a penalty."
Why the churn report is always late
Classic reporting is built from the fact: the month closed, cancellations were counted, the percentage went into a deck. That is a rear-view mirror. The subscribers in the report are already connected with a competitor, and winning them back costs several times more than retaining them would have.
A retention call at the moment the request is filed is also too late. The decision is made, the point of no return has passed, and the only argument left to the operator is a discount. A discount at that moment reads as an admission of guilt and cuts into ARPU on the spot. Risk has to be worked earlier: while the subscriber is still complaining, not when they are already saying goodbye. A complaint is, in essence, the last form of loyalty.
A live view of risk across the base is the opposite of a monthly report: the number changes on the day of the event, not on the day of the presentation. For the team that is a different rhythm. The week starts with a queue of risks, not with a post-mortem of losses that already happened.
How the platform reads calls, tickets, and billing
The platform connects via API to systems the operator already has: billing, ticketing, CRM, telephony. Call recordings are transcribed – Kazakh and Russian are recognized at a native-speaker level, including mixed speech. Tickets are classified by problem type and linked into chains: three "low speed" requests from one address are one story, not three lines. Billing adds the momentum of traffic and payments. From all of this, a risk score is assembled for each subscriber, and it is recalculated as events happen, not once a month.
The event is what triggers the process. Risk crossed the threshold – a task is created, the history is assembled, an owner is assigned. It is not a person remembering the subscriber – the signal finds the person on its own.
Thresholds do not have to be the same for everyone. At equal risk, the platform moves those whose loss is more costly up the queue: high ARPU, long history, a corporate contract. The rules are set by the operator itself – and changed without rewriting the system.
Two scenarios: a business entity and home internet
A scenario from one of the prototypes, anonymized. A corporate customer: an internet channel to the office and fifty SIM cards. Over a month – two tickets about channel degradation, both closed formally, "work carried out." Then a call from the accountant asking about the remaining contract balance and the cancellation procedure. In parallel, billing shows traffic down by a third: part of the office has already moved to a backup provider. Individually, no one would have connected these events – the tickets are with tech support, the call is with the call center, the traffic is with the analysts. The platform brings them together into one signal: risk high, cause channel quality, history attached. The account manager gets a task in CRM with a timeline and a recommendation, not a note saying "call them, something's off."
The retail version of the same. A home internet subscriber, three "speed drops in the evenings" tickets over two weeks, and in the third conversation a competitor's name comes up. The request goes to the technicians with raised priority, the retention team gets the subscriber into their pipeline – before the cancellation, not after.
In both scenarios, time is what decides. Between the first signal and the request there are usually three to eight weeks – a window in which retention is cheap: a conversation and a fix instead of a discount and a free set-top box.
| Signal | Where it lives | What the platform does |
|---|---|---|
| Repeat tickets about one problem | ticketing system | links into a chain, raises the risk score |
| Irritation, competitor mentioned | call recordings, chats | transcription, sentiment, trigger phrases |
| Question about cancellation terms | calls, chats | immediate signal to the retention team |
| Drop in traffic and payments | billing | per-subscriber momentum, threshold is an event |
| Broken callback promise | CRM, tickets | escalation before the deadline expires |
What does one percent of churn cost?
Lost revenue per year ≈ subscribers lost per month × ARPU × 12
A base of 200,000 subscribers, ARPU of 4,000 tenge, churn of 1% a month – that is 2,000 subscribers and roughly 96 million tenge in annual revenue, lost anew every month. Cutting churn by 0.3 percentage points preserves about 600 subscribers a month – nearly 29 million tenge on an annual basis. Run the numbers for your own base before any talk of rollout: the calculation takes ten minutes and immediately sets the scale.
To this you should also add the cost of acquisition. A new subscriber costs a connection, equipment, and marketing – retaining an existing one is almost always cheaper, it is just that the expense is not called out as a separate budget line.
What changes for the retention team
Instead of dialing down an alphabetical list – a queue sorted by the subscriber's risk and value. Instead of a "talk to the customer" task – context: what hurt, what was promised, what changed in usage. Instead of arguments over why a subscriber made the list – an action log: every step the platform took is recorded, from signal to task, and it can be checked.
The discount stops being the only tool. When the cause is known, the offer lands on it: a priority technician visit if quality is the pain, a plan change if the subscriber is paying for something they do not use, a channel upgrade if the business customer has grown. The success metric changes too: not "how many requests did we work" but "what share of at-risk subscribers did we talk to before the request."
The manager, meanwhile, sees a live picture across the base: how many subscribers are in the red zone, which causes lead, how the retained share is moving. Without exports and manual roll-ups by Monday.
Some signals are extinguished right at the first line – if routine requests are closed quickly and in the subscriber's language. How that works we covered in the article on AI in customer service.
Where an operator should start
A prototype comes together in about a week, free of charge. It needs exports from the past two or three months: call recordings, tickets, an anonymized slice of billing. After that – a check against history: we take subscribers who left and look at how many weeks before the request the platform would have seen the risk and by which signals. This is an honest test before any commitment: the number is visible before a contract is signed.
A production rollout runs from eight weeks, on a subscription model. Scenarios for telecom operators are gathered on the telecom solutions page, and you can arrange a demo through our contacts.
Frequently asked questions
Will we have to change our billing or CRM?
No. The platform is a layer on top of existing systems: it connects via API, and where a system only has a screen and no API, the agent works through the interface. Replacing billing is not required, either on the prototype or in production.
How accurate is the risk forecast?
It depends on the completeness of the data, so we do not name a percentage in advance but show it on the prototype: the scoring is run over your history, and it is clear what share of those who left it would have caught and with how much lead time. The decision to roll out is made after seeing that number.
Are Kazakh-language calls recognized?
Yes. Kazakh and Russian at a native-speaker level, including mixed speech, which is common in support conversations. Sentiment, topics, and trigger phrases are read equally in both languages.