Master data in telecom: subscriber, number, device, contract, address — five sources of discrepancy
When master data is bad, every analysis and every operation suffers. In a typical telecom five key entities — subscriber, number, device, contract, address — each has its own problem.
Discuss Your ChallengeWhat master data means in a telecom context
Master data is data on the key entities of the business that must be consistent across all systems. In telecom the main ones are:
Subscriber. One person or organisation. Has an ID, documents, contacts, attributes.
Number. A specific phone number. Has a status (active, blocked, new, MNP-ed), historical association with subscribers, current owner.
Device. The SIM card or smartphone. Has IMSI, IMEI, association with the number and the subscriber.
Contract. The legal contract. Has the tariff, validity period, options, links to subscriber and numbers.
Address. The customer’s physical location. Used for billing, service delivery, regional analytics.
Each of these has a master record that should be the source of truth for every other system.
Where discrepancies usually appear
In most operators master data is spread across several systems and is not synchronised.
Subscriber. The same person can be registered in CRM as client #12345, in billing as customer #67890, in the dealer system as subscriber #11111. The three IDs are not linked. Answering “how many services does this person have” requires manual matching by name, document, phone.
Number. When the number changes owner (sold to another, returned to the pool, MNP-ed), different systems update the status with different lag. One says “free”, another “active with previous owner”, a third “unavailable”.
Device. A SIM may be active in billing data and deactivated in network data. An IMEI may be associated with one number per the SIM activation system and another per the network usage system. These discrepancies become serious in anti-fraud, where device identity is critical.
Contract. One customer can have active contracts in several systems out of sync — postpaid contract in the main biller, partner service in partner billing, dealer commitment in the dealer system. The full picture does not reconcile.
Address. The customer’s address in CRM, billing, the dealer system, and mailing list is often different. Which is the actual one? Depends on whom you ask.
Why master data is usually bad
Several structural reasons.
History. Systems accumulated as the business grew. Each new system added its own copy of customer data. Migration of old data was usually incomplete.
Mergers and acquisitions. If the operator pre-existed under a previous name or merged with another company, data is on different “historical” platforms.
Vendor systems. Different vendors use their own internal IDs, and cross-vendor mapping is often missing.
No master data function. Master data has no dedicated owner — it is “everyone’s and nobody’s”. IT runs uptime, business runs its own data inside its own system, nobody runs consistency.
The cost-of-fix excuse. “These are historical data, the fix takes 2 years, we have other priorities.” So master data stays in poor shape for years.
Regulatory pressure without enforcement. The regulator may require customer data quality, but without strict audit there are no immediate consequences.
What changes once master data is fixed
Analytics becomes reliable. When “active customer count” means one specific number, all downstream teams work on the same picture.
Anti-fraud works. SIM swap detection, device change tracking, multi-account fraud detection all require consistent master data.
Customer experience is better. The customer calls the contact centre and the agent sees the full history. They walk into the office and the dealer sees the existing relationship. Creates the impression of a company that “knows who I am”.
Cross-sell is efficient. When the operator knows the customer already has products A, B, C, it can target additional product D, not flood with generic offers.
Compliance. Regulatory requirements (KYC, data privacy, anti-fraud) need a consistent customer view. Without it — constant risk of a regulatory issue.
What is needed to fix master data
A master data function. Not “IT”, not “business” — a separate function with authority over consistency and quality. Often called Data Governance or Master Data Management.
Master data architecture. Logically — single source of truth per entity. Technically can be hybrid (virtual through federation or physical through an MDM platform).
A cleanup project. Initial cleanup of existing discrepancies — 12-24 months of work depending on operator size. Not glamorous, but necessary.
Integration discipline. Every new system at the operator must pass through master data architecture. Project teams resist (faster to ignore).
Ongoing data quality monitoring. Quality metrics, escalation paths, regular reviews. Without these, quality drift returns within 6-12 months.
A realistic roadmap
Months 1-6. Foundation. Master data function established. Initial quality assessment by entity. Identification of top-3-5 priority issues.
Months 7-15. Cleanup and architecture. Cleanup of priority entities. Build of an MDM platform or federation layer. Integration with major source systems.
Months 16-24. Sustainable operations. Ongoing monitoring. Integration discipline. Regular cleanup processes. Most data flows pass through master.
By two years in, master data is in an acceptable state. Not perfect, but reliable enough for business operations.
What often goes wrong
Big-bang MDM project. Trying to fix everything at once with a new platform. Cost overruns, timeline blow up, business value does not materialise early. A phased approach is significantly more sustainable.
MDM platform vendor lock-in. The vendor controlling master data positions itself as indispensable. Within 5-7 years migration becomes expensive.
Cleanup without ongoing discipline. Initial cleanup done, 12 months later quality has drifted back. Without operational discipline cleanup is a recurring cost.
No business engagement. Master data treated as an IT initiative. Business teams not engaged in definitions, do not accept disciplines. Project happens “around them”.
Definitions without business consensus. Technical teams decide what an “active client” is, not business. Twelve months later business challenges the definition and the project starts over.
When master data fix is not a priority
If operations work “good enough” with current data quality and there is no regulatory pressure, the investment can be deferred.
If the organisation is in an acute phase of major restructuring (merger, ownership change), master data fix will be blocked by organisational churn.
If the budget is constrained — master data fix is not a quick win, it requires sustained investment of 18-24 months.
If C-level is not committed to data governance discipline beyond technology, the fix does not sustain.
If IT capacity is overloaded with other transformation projects, adding master data overburdens.
Discussion points for the committee
What 3-5 “data discrepancy” issues do teams keep running into? That is the priority list.
Who owns master data today? If distributed — that is the problem.
What is the regulatory exposure of current data quality? If there is risk — that is a motivator.
What 18-24 month investment commit is needed and is it there?
Is the organisation ready for master data as a permanent function, not just a project?
How SamaraliSoft can help
Master Data Management Programme — assessment of current quality state across the 5 entities, design of the target architecture (centralised MDM or federated approach), establishment of a master data function, prioritised cleanup over 12-18 months, and establishment of ongoing discipline and monitoring.
Related reading
- /en/architecture/telecom-around-core-architecture/ — layer around the core
- /en/insights/telecom-data-contracts/ — data contracts
- /en/insights/telecom-event-driven/ — event-driven foundation
- /en/insights/telecom-revenue-assurance/ — revenue assurance
Sources
What else is worth exploring
Topics from the same area we usually explore together
CRM
Not an off-the-shelf CRM, but a properly built customer management contour — from first contact to loyalty.
→SolutionBI
Analytics is not pretty charts on the wall. It's the answer to 'why?' before the problem becomes a loss.
→SolutionContact Center
The contact center is not a phone station — it's the point where a client decides: stay with you or leave. The question is how it's built…
→SolutionIntegrations
Integrations are invisible but critical. When they work — systems talk. When they don't — data is lost and people copy from window to…
→I do not just write about this. I can come in, examine your situation and design a solution for your specific landscape.
Discuss applying this →Ready to discuss your challenge?
Tell me what's not working or what needs to be built. First conversation — no obligations.
Usually respond within a few hours