Skip to content

AI Readiness Starts with Data Quality: A Checklist for Telecoms and ICT Businesses

Telecoms and ICT businesses hold more data than almost any other sector, yet most AI projects stall on its quality. A practical checklist for knowing whether your data is ready before you invest in the model.

Kudakwashe Verah 6 min read

Telecoms and ICT businesses are under pressure to “do something with AI”: predict churn, automate service desks, anticipate network faults, personalise offers. They also hold more data than almost any other sector — every call, session, ticket, device and invoice leaves a record. It is tempting to conclude that the data is the easy part.

It rarely is. Gartner predicts that through 2026, organisations will abandon 60% of AI projects that are not supported by AI-ready data, and that 63% of organisations either do not have, or are unsure whether they have, the right data management practices for AI.1 In the sector itself, Analysys Mason’s 2026 index of 50 Tier 1 operators found half of them were still AI laggards, and identified preparing and curating data for AI models as the weakest area overall.2 Having data is largely solved. Having data a model can trust is not.

This article sets out why telecoms data is harder to make AI-ready than it looks, what “ready” actually means, and a checklist that can be used to assess readiness before any money is spent on a model.

Why telecoms data is harder than it looks

It is spread across many systems. Customer, product, billing, usage, network inventory, alarms, service tickets and field work typically live in separate BSS and OSS platforms, often added at different times or inherited through acquisitions. Each has its own identifiers, and few share a reliable common key. Analysys Mason notes that siloed operations leave central data environments isolated, which existing architectures struggle to bridge.3

The same thing has many names. One customer can appear under an account number in billing, a subscriber ID in the network, an email address in the CRM and a company registration number in the enterprise contract. Unless those are linked deliberately, a churn model sees four customers where there is one.

Inventory drifts from reality. Network and asset inventories are updated by people in the field. Over time, records describe equipment that has been moved, replaced or decommissioned. A fault-prediction model trained on that inventory learns the records, not the network.

History is rewritten by change. Product catalogues, tariff structures and ticket categories change regularly. A model that needs three years of history needs that history to be comparable — or at least clearly mapped across each change.

Much of the useful data is free text. Service tickets, technician notes and complaints carry the richest information and the least structure. Their categories are often chosen inconsistently by different agents, which is exactly the label a classification model would learn from.

The rules are strict. In South Africa, POPIA requires a responsible party to take reasonable steps to keep personal information complete, accurate, not misleading and updated where necessary, and to process it only for a specific, defined purpose.4 Subscriber records also carry RICA registration obligations. Using customer data to train a model is a new purpose that needs to be assessed, not assumed.

Customer,site andasset keyCustomer & RICACRMBilling & productsBSSUsage recordsCDR / xDRNetwork inventoryOSSAlarms & performanceNMSService ticketsITSM · free textField & assetsworkforce · GIS
Typical telecoms data domains and how reliably each links to one customer, site or asset. AI use cases that span several domains — churn, fault prediction, ticket routing — depend on those links. Illustrative.

What “AI-ready” means in practice

Gartner’s definition is a useful test: AI-ready data must be representative of the use case, including the patterns, errors and outliers the model will meet in practice.1 That means readiness is always judged for a specific use case, never for “the data” in general. Data that is perfectly adequate for monthly reporting can be unusable for a model that needs daily, customer-level history.

For a given use case, data is ready when it is:

  • Available — the required sources can be accessed, legally and technically.
  • Accurate and complete — key fields are populated and correct, and the error rate is known.
  • Connected — records about the same customer, site or asset can be joined reliably across systems.
  • Consistent over time — history is comparable across product, tariff and category changes.
  • Governed — owners, definitions, permitted purposes and retention are documented.
  • Monitored — quality is measured continuously, so the model’s inputs do not silently degrade.
Available1Accurate &complete2Connected3Consistent overtime4Governed5Monitored6Model-ready
Readiness is cumulative and judged for one use case at a time. Most telecoms data is available; far less of it is connected, consistent over time, governed and monitored.

The checklist

Work through these questions for one named use case at a time — for example, “predict which business customers are likely to cancel in the next 90 days”.

1. Use case and ownership

  • Is the decision the model will support written down, with the business owner who will act on its output?
  • Is there an agreed measure of success, and a baseline for it today?

2. Identity and linkage

  • Is there a reliable key that links a customer (or site, or asset) across billing, CRM, network and service systems?
  • Are duplicate and merged records identified and resolved, with the rules documented?

3. Accuracy and completeness

  • Has each field the model needs been profiled for missing, invalid and out-of-range values?
  • Are the most important fields — account status, product, location, contract dates — checked against a trusted source?

4. History and labels

  • Is there enough consistent history to cover seasonality and the event being predicted?
  • Are labels (for example “churned”, “fault”, “ticket category”) defined the same way across the whole period and applied consistently?

5. Governance and compliance

  • Is the use of personal information for this purpose assessed against POPIA, including purpose, minimisation and retention?
  • Does each data source have a named owner who is responsible for fixing problems at source?

6. Pipelines and monitoring

  • Can the required data be refreshed automatically at the frequency the use case needs?
  • Are quality checks run on every refresh, with alerts when key measures fall below a threshold?

Score your readiness

The quick self-assessment below uses the same six areas. It is a conversation starter, not an audit: use it to see where the gaps are before deciding where to invest.

AI data-readiness check — one use case

Answer for a single, named use case. Nothing you select is stored or sent.

  1. 1. Use case and ownership

    0 / 4
    The decision the model will support is written down, with a business owner who will act on it.
    There is an agreed success measure and a baseline for it today.

  2. 2. Identity and linkage

    0 / 4
    A reliable key links each customer, site or asset across billing, CRM, network and service systems.
    Duplicate and merged records are identified and resolved by documented rules.

  3. 3. Accuracy and completeness

    0 / 4
    Every field the use case needs has been profiled for missing, invalid and out-of-range values.
    Critical fields are checked against a trusted source on a regular basis.

  4. 4. History and labels

    0 / 4
    There is enough consistent history to cover seasonality and the event being predicted.
    Labels such as “churned”, “fault” or “ticket category” mean the same thing across the whole period.

  5. 5. Governance and compliance

    0 / 4
    Using personal information for this purpose has been assessed against POPIA (purpose, minimisation, retention).
    Each data source has a named owner responsible for fixing problems at source.

  6. 6. Pipelines and monitoring

    0 / 4
    The data refreshes automatically at the frequency the use case needs.
    Quality checks run on every refresh, with alerts when key measures fall below a threshold.

Your result appears here as you answer.

Where to start

The most reliable route to AI value in telecoms is narrow and deliberate:

  1. Pick one use case with a clear decision, owner and baseline — churn, ticket routing or fault prediction are common starting points.
  2. Profile only the data that use case needs. Measure completeness, accuracy, linkage and history for those sources, and publish the results.
  3. Fix the biggest gaps at source, not in a one-off clean-up. Assign each fix to a data owner and track it like any other operational issue.
  4. Build quality monitoring before the model. A small data-quality dashboard for the use case keeps the inputs honest and shows progress to sponsors.
  5. Run a time-boxed pilot against the agreed baseline, and decide on scale only once the data has held up in practice.

Each step produces value even if the model never goes live: cleaner customer records, a trusted inventory and better reporting all pay back on their own.

Closing thought

In telecoms and ICT, AI is rarely held back by a shortage of data or of algorithms. It is held back by data that is spread out, inconsistently defined and not owned. Starting with an honest assessment of data quality — one use case at a time — is slower in the first month and much faster in the first year.

Footnotes

  1. Gartner, “Lack of AI-Ready Data Puts AI Projects at Risk”, press release, 26 February 2025. gartner.com. ↩ ↩2

  2. G. Yigit, J. Attwood and C. Gabriel, Telco AI Readiness Index: 2026 results, Analysys Mason, July 2026 (survey of 50 Tier 1 operators, March–May 2026). PDF. ↩

  3. A. Okeleke, “Telecoms operators push ahead with building data foundations for AI, but much progress is still needed”, Analysys Mason, 13 March 2026. analysysmason.com. ↩

  4. Protection of Personal Information Act 4 of 2013, sections 13 and 16; summary by Schindlers Attorneys. ↩