Operators Clean Their Customer Records Every Year. What Nobody Has Found Is Where the Records Go Wrong.

A business account has disputed its bill for the third month running, and this time the complaint has reached the managing director.

The head of customer operations opens the account. The billing system shows the old plan. The care portal shows the new one, changed in March. The activation tool shows the new plan and an address the firm left two years ago.

Everyone in the room knows which screen to believe: the care portal, the one the team keeps up to date. Nobody can say why the other two disagree with it. Last year’s clean-up corrected this account. It is wrong again.

What We Found

For this article we went through the public record on customer records at telecom operators: one regulator’s published finding about an operator’s records, one news report of a fine after a move to a new billing system, and one survey of IT professionals on why old systems stay in place.

Four findings stand out.

In one regulator’s finding, the failure was in what the operator identified and recorded. On 1 December 2025 the UK regulator, Ofcom, fined Virgin Media “£23,800,000”. Its finding was that, while moving customers “from analogue to digital landlines”, the operator “failed properly to identify and record the status of telecare customers, resulting in significant gaps in the screening process”. Telecare is an alarm service that works over the phone line. The move itself was a change of network, which is not our kind of work, and we use the case for one point only: the regulator’s finding was about what the operator had identified and recorded. We did not examine why the status was not recorded, and we draw no cause from it.

Records can go wrong at a move, and the losses can run for months. In an older case, in October 2016 the UK regulator, Ofcom, fined Vodafone £3.7 million, finding that between December 2013 and April 2015 it gave 10,452 pay-as-you-go customers incorrect information that they would receive the services they paid for with top-ups, and that “the account balance information did not accurately reflect the true extent of the credit for which they had paid”. Press reports at the time said the operator linked the failures to a move to a new billing system; Ofcom’s notice gives no cause. Neither says anything about what went wrong inside that system, and we do not guess.

Old systems stay because they still work. In one survey of about 500 IT professionals in the US, across industries and company sizes, run by a firm that sells software services and not about telecom, half said that their current system still works was a reason for not modernising. More than four in ten named budget limits, and about a third named concerns about moving data.

Nobody in the public record traces a wrong record back to where it was made. We found no public account, from any operator, of which program, copy job or manual step turned a right record into a wrong one.

Our reading is that operators live with wrong records not because their staff are careless, but because a customer’s details pass through many applications built around the billing system, joined by small programs that copy details overnight, and nobody has written down what each one does to a record. A clean-up corrects the records and leaves the step that spoils them in place.

What Waits While Nobody Knows Where the Record Is Spoiled

The first cost is the clean-up that comes back: records are corrected, the screens and copy jobs that spoiled them are left alone, and within months the same fields disagree again.

The second cost is the credit with no cause. A billing error is put right and a credit posted, with “customer record incorrect” as the reason, and nobody can say why.

The third is the question nobody can answer: asked how a record came to be wrong, the firm can show only when it was corrected.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Deal With Wrong Customer Records, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Run another clean-up	The errors are old and few, and nothing in the systems has changed since	The same screens and copy jobs go on spoiling records
Buy a packaged data-quality tool	The firm wants to find and flag bad records across many tables, and has people to act on the flags	It works on the records in the tables, not on the screens and copy jobs that spoil them
Trace a wrong record to the step that spoils it, then rebuild that step	The same kinds of error keep coming back, and nobody can say where they start	It costs money before any record is corrected, and the trace may show more than one step at fault
Replace the customer systems entirely	The old systems are near their end, and the firm can fund a large programme	Years of work and one large move, with the records carried across as they are

Where You Are Now, and Where You Should Be

A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures taken from your own applications, each with a target.

For this issue, the benchmark would look like this.

Measure	Typical starting point	Where it should be	How it is checked
Places each key customer field is entered and copied between applications	Not known; each team knows its own screen	Every place listed, with the program, copy job or manual step that moves it	The map of the applications as they stand
Steps that spoil records	None named; each wrong record is handled as a one-off	Each recurring kind of error tied to a named rule or step	The specification and the risk register
Checks at the point of entry, in each rebuilt module	A field the firm relies on is optional, or takes any text	Every detail your people call compulsory is asked for and checked where it is entered	The rebuilt module, accepted against the specification
Old functions matched to new ones, where a module is rebuilt	Not recorded	Each function linked to its replacement	The traceability matrix

The starting points above are what the public record suggests and what we expect to find. In an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a telecom operator.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the customer records that keep going wrong. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is the applications and copy jobs your firm built or had built around its billing system, and the assessment traces a wrong customer record through them, and the manual steps your people describe, to the step that spoils it. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means only the part that lets wrong records in, such as an entry screen, a rule or a copy job, rebuilt with checks at the point of entry beside the old application. We never do a single cutover. Each module has a traceability matrix. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

This approach has limits. We do not clean, correct, merge, reconcile or migrate customer records; your own people do, or the firm that carries out a move. The records that are wrong today stay wrong until they are corrected. We do not work inside a packaged billing or customer product; where the rule at fault sits inside one, its own specialists deal with it. We do not work on the network or the systems that run it. Some errors begin with a detail typed wrongly or never given; no reading of code finds those. Our published terms on access cover code, not customer records. We give no legal or regulatory advice. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. We have no published case of this work for a telecom operator.

What changes for the business:

Role	What they gain
CEO	A wrong bill or a missing customer detail has a known cause and an owner, and stops being a mystery that returns at every review.
CTO or CIO	A traced path for each key customer field, from where it is entered to every place it is copied, showing the rule or step where it goes wrong.
CFO	A billing error has a cause that can be named, and not only a credit that is posted.
COO	Operations can tell which errors come from the programs and which from entry, and service agents can say which screen is right, and why.
Head of regulatory affairs	When someone asks how a record came to be wrong, there is a written answer that points to a rule.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
Ofcom fined Virgin Media £23,800,000 on 1 December 2025, finding it “failed properly to identify and record the status of telecare customers” during a move of landlines.	Our part is far narrower: we do not work on networks, nothing we do protects a customer, and we do not say what went wrong. For applications an operator built, we trace where customer details are entered, copied and left blank, and rebuild the step at fault.
In October 2016 Ofcom fined Vodafone £3.7 million over top-ups sold to 10,452 pay-as-you-go customers; press reports linked the failures to a move to a new billing system. An older case.	Our part is far narrower: we do not implement or move billing products, or migrate data. For applications an operator built, we trace a wrong record to the step that makes it, and rebuild that part.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We start by tracing one wrong record to the step that made it, because that is the answer every clean-up has been missing.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →