Subscriber intelligence: why a 360 profile does not generate revenue without an operating model

What usually goes wrong

At one regional telecom operator, 14 months and a serious budget were spent building a Subscriber 360. Data was assembled from billing, CRM, the app, the contact centre and the dealer portal. A golden record was produced. A dashboard was launched showing 84 attributes per subscriber — consumption, payments, contacts, devices, tariff history, signal degradation rate per cell.

Three months after launch nobody used the dashboard regularly. The business said “we do not have time to look, give us a list of customers to call”. Marketing asked “pull a segment with these conditions and export it”. The contact centre never even got access — IT was concerned about personal data.

The dashboard was archived. The project was logged as a success — “the infrastructure is ready, now the team has to learn how to use it”. The team did not learn.

This story repeats regularly for one reason. Subscriber 360 is not a product. Subscriber 360 is infrastructure for another product called the operating model. Without the second one, the first does not generate money.

What an operating model around data actually means

The operating model is not “who is responsible for the dashboard”. It is a connected set of rules that answer five questions.

What event triggers a response? Not “we have customer data”, but “when the customer state changes, what should happen”. A package expiry. A 50% drop in traffic over a week. A third complaint in a month. A roaming trip. A device change. Each of these is a potential trigger.

Who owns the response? Not “marketing works with the data” — that is too general. Each event type needs a concrete owner with the authority to make response decisions. If the event is “tariff expiring” — that is the retention manager. “Third complaint in a month” — head of customer care.

In which channel does the response happen? Push in the app? SMS? Phone call? Email? A message via the dealer? Each channel has its own cost, speed and conversion. The response should have a channel assignment by rules, not “today let’s try push, tomorrow SMS”.

At what speed? If the event happened at 14:00 and the response went out at 09:00 the next day, that is a different operation from 14:15. Speed influences conversion by multiples.

Who carries P&L for the result? This is the hardest question. If an event triggers conversion, whose KPI gains in the commercial structure? If retention worked — who gets credit? If nobody acted — who answers for the missed response?

Without answers to these five questions, Subscriber 360 is an object of contemplation rather than a business tool.

Why it does not happen on its own

A natural question follows: if the operating model matters that much, why does it not appear on its own when the team sees the dashboard? The answer is that the operating model is a management project, not a technology one, and it requires a different team and a different mindset.

A technology project can be closed by an IT team with a contractor. The operating model requires the commercial division, customer care, marketing, analytics and finance to agree on a single set of rules and a shared KPI. That is a negotiation process, not a deployment. It often gets postponed because “first we will launch, then we will figure out how to use it”.

This always ends with the project launching, no usage emerging, and a year later the team saying “the technology did not work”. In reality the technology worked, the management did not.

What goes into a realistic operating model

The minimum set of components looks like this.

Catalog of events. A list of 10-30 customer events that have commercial meaning. Not “all events”, but those selected on two criteria: they happen often and they have a meaningful response.

Decision rules per event. For each event — a table. Under what conditions which offer is shown to which customer, in which channel, at what frequency, who is excluded. These rules must be documented, not live in people’s heads.

Owner per decision. A specific person or role responsible for the quality of the rules. Not “the team”, a name. This role has the authority to change rules and sees the economic results of those decisions.

Suppression rules. Rules of what NOT to do. Do not show the offer if the customer has complained in the last 7 days. Do not call at night. Do not make a second contact within 48 hours. Without suppression rules even good rules turn into spam.

Frequency caps. How many times per day, week, month one customer can be contacted. Without these limits the system tires the customer fast.

Audit log. A record of who took what decision and why. Required by law on personal data, useful for quality — to reconstruct why a specific customer received a specific offer.

Performance dashboard. Not a “general dashboard about all customers”. A management screen showing how many times each event happened, what percentage received a response, what percentage converted, what the per-event economics looks like. This is read every Monday by the committee.

Routine of decisions. A regular meeting where numbers are discussed, rules adjusted, decisions made on new events or shutdown of underperforming ones. Without this routine the system goes stale.

A concrete example: the “package 80% used” event

Take one event and look at what the operating model means in practice.

The event: the customer has used 80% of the mobile data package, with 2-3 days left in the billing cycle.

Without an operating model: data is collected. Marketing sometimes sends “your package is running out”. Sometimes does not. Sometimes sends to everyone instead of one segment. Conversion to additional package purchase at 2-4%.

With an operating model. Decision rule: if the customer is in category A (active digital, steady traffic), show “extend the package” in the app at price X at the moment 80% is exceeded. If in category B (intermittent traffic), send SMS with a different offer. If in category C (low spender), do nothing — the contact cost is higher than the value.

Suppression: if the customer has received a package offer in the last 7 days, do not show again. If they complained — do not show.

Frequency cap: no more than one push on this topic per month.

Owner: head of digital monetisation. They carry the KPI for conversion of this event.

Performance: the event is tracked separately on the dashboard. Visible: how many times it triggered in a week, the average additional purchase amount, the ROI against contact cost.

Conversion with this operating model in practice runs at 12-18% versus 2-4% without it. The difference is not in the data — the data is the same. The difference is in the discipline.

When not to build Subscriber 360

Not every operator is ready for this investment, and that is fine.

If master data about the customer, number, contract and device differs significantly between billing, CRM and the app, and reconciliation is done manually or weekly, Subscriber 360 will be built on sand. Data quality first — minimum 6-9 months of work.

If the commercial structure has no role that can carry P&L for the results of decisions on events, the project will live in IT and slowly die. The operating model requires a commercial owner with authority to change rules and to see the result in P&L.

If there is only one large communication channel with the customer (say only SMS), Subscriber 360 gives a limited effect because there is no per-channel variability. Channels first (push, app inbox, dealer touch), then 360.

If the rules for working with personal data have no explicit consent for marketing processing and personalisation, Subscriber 360 is built under regulatory risk. Consent management first.

If the budget covers only the build of 360 without 18-24 months of continuing rule and team setup, the project will close before showing results.

What “the dashboard is ready but nobody uses it” means

This is not a project failure. It is a diagnosis: the project built the infrastructure and did not build the operating model. The cure is not a re-do, it is forming a management routine.

A realistic recovery path — take one specific event (for example, package expiry), build a full operating-model cycle around it for 90 days (rules, owner, channel, audit, dashboard, weekly review), measure the result, then scale to the next event. It does not sound grand, but this is the path that leads to a working system.

How SamaraliSoft can help

Subscriber Intelligence & Churn War Room — not “we will build you another Subscriber 360”. Work on the operating model: pilot event selection, building a full rules-owner-channel-audit-review cycle, measurement of the result over 90 days, then scaling. If the operator already has a Subscriber 360 — diagnostic on why it does not work and a recovery plan. If not — a plan to build from scratch with the right separation between infrastructure and operating model.

Related reading

• /en/cases/telecom-subscriber-360/ — a real Subscriber 360 case at a regional operator
• /en/architecture/telecom-around-core-architecture/ — why the around-core layer matters more than billing replacement
• /en/insights/telecom-event-driven/ — events as the foundation of an operating model
• /en/insights/telecom-growth-after-connectivity/ — where the money sits in telecom beyond connectivity

Sources

• Digital Government Portal — state of digital infrastructure UZ
• UzDaily — telecom market 24,873 billion UZS, +18.3%
• Central Bank of Uzbekistan — payment systems statistics
• UzTelecom — user interface