Cleaned, and Wrong Again. Four Ways to Make Customer Records Stay Right, Weighed.
Indian operators now report how fast they resolve billing complaints and keep the records behind those reports. Here is what that means for an operator whose customer records keep going wrong after every clean-up, the four ways forward, weighed, and the one we would recommend.
The clean-up project closed in February. For four months a team had compared the billing system with the care portal, account by account, and corrected what did not match. The closing report was signed.
It is now September. The head of IT runs the same comparison again, out of curiosity. The mismatches are back. They are in the same fields as before.
The finance head has one question. Will this have to be done again before next year’s move to the new platform?
The paradox: The operator paid to make its records right, and left in place everything that makes them wrong.
What We Found
For this article we went through the public record on customer records that do not stay right: one news report of a fine after a move to a new billing system, one survey of IT professionals on why old systems stay, and the rules that operators in India now work under on complaints, records and personal data.
Two findings stand out. The rules are set out in the next section.
A fault in customer records can run for many 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, or why it lasted so long, and we do not guess. We take one narrow point: a fault in how records are handled can go on for months.
The cause is left in place because the system still runs. In one survey of about five hundred IT professionals in the US, across industries and company sizes, run by a firm that sells software services and not about telecom, half gave the current system still working as a reason for not modernising, and more than four in ten named budget limits. An entry screen that lets a blank through does still work.
Our reading is that clean-ups do not last because they correct what is in the tables and leave the entry screens, rules and copy jobs that fill them as they were. Cleaning is a project with a closing date; spoiling is continuous.
What our review does not show: We found no figure for how quickly cleaned records drift, what a clean-up costs, or what a wrong bill costs to put right. The survey is cross-sector, from the US, and was run by a vendor. We found no case of an Indian operator penalised under the rules below for wrong customer records, and the link from those rules to old applications is our reading. The opening scene is imagined.
What an Operator Cannot Show While Its Records Keep Going Wrong
In India, TRAI’s Standards of Quality of Service regulations of 2024 have been in force “with effect from 1st October 2024”. Their customer-service benchmarks include “Resolution of billing/ charging complaints within four weeks” (for 100% of complaints), adjustment to the customer’s account “within one week from the date of resolution”, “Termination/ closure of service within seven working days of receipt of customer’s request” and “Refund of deposits within 45 days of closure of service”. Providers “shall maintain complete and accurate records of raw or primary and processed data” on these benchmarks “in electronic form”, preserved “for at least one year after reporting the performance”, and were to “create or upgrade their system within six months of notification of these regulations” for collecting that data and its “online submission to the Authority”. The regulations apply to providers of access and broadband services and to internet service providers, but not to “an Internet Service Provider whose total number of subscribers as on last day of the preceding financial year does not exceed ten thousand”. A consultation paper of 5 August 2026 proposes resolving billing complaints “within one week”; that is a proposal, not a rule, and TRAI had not notified it as of 14 October 2026.
India’s Digital Personal Data Protection Rules, 2025, published on 13 November 2025, are not a telecom rule. They apply to Data Fiduciaries in every sector. Most of their duties (“Rules 3, 5 to 16, 22 and 23”) “shall come into force eighteen months after the date of publication”, which is about 13 May 2027. Rule 6 asks for safeguards including “encryption, obfuscation, masking” and “appropriate logs, monitoring and review”, and to “retain such logs and personal data for a period of one year”. Rule 7 asks for a report to the Board “within seventy-two hours of becoming aware of the breach”, or “within such longer period as the Board may allow”.
None of these rules names an old application or says how a customer record must be kept inside one. Our reading is that an operator whose applications pass a customer’s details through several copies, by rules nobody has written down, will find it harder to show where a wrong bill came from, and that every copy is one more place where personal data sits. What any rule asks of your firm is a question for your own advisers.
The gap we see: an operator that has found the step that spoils its records, and rebuilt it with checks at the point of entry, can put a cause beside a billing complaint and say where each copy of a customer’s details is made. One that runs another clean-up can show neither. The opportunity is to correct the records once, after the cause has gone.
This is our reading of the evidence. It is not a measured market figure, and it is not legal advice.
Four Ways to Make Customer Records Stay Right, 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, and the clean-up is approved again next year |
| 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 with checks at the point of entry | The same kinds of error keep coming back, in the same fields, after every clean-up | It costs money before any record is corrected; the trace may show more than one step at fault; a check that is too strict will be worked around |
| 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 |
Our recommendation: trace the wrong records to the step that spoils them first, and rebuild that part, one module at a time, with checks at the point of entry that your own service and regulatory people agree. Then correct the records once. A clean-up is worth paying for once the cause has gone. We do not run the clean-up: we do not clean, correct, merge, reconcile or migrate records, and we have no data-quality product. We do not work inside a packaged billing or customer product, and we do not work on the network.
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 |
|---|---|---|---|
| Recurring billing complaints with a named cause | None; “customer record incorrect” | Each recurring kind tied to the step that spoils the record | Your complaint records and the risk register |
| Checks at the point of entry, in each rebuilt module | A detail the firm relies on is optional, or takes any text | Every detail your people call compulsory is checked where it is entered; a record that fails is set aside for a person | The rebuilt module, accepted against the specification |
| The same accounts corrected again | Not counted | Counted from your own records, and falling for each kind of error whose step has been rebuilt | Your own service records, reported at every review |
| Clean-ups of the same records | One every year or so | One, after the step at fault is rebuilt | Your own project records |
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
- We listen: a free Reliability Review. A first conversation about the records that come back wrong after every clean-up. 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.
- 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.
- 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.
- If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means the entry screen, rule or copy job that lets wrong records in, 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.
- 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 a price. A rebuild costs more than one more clean-up, and the records that are wrong today stay wrong until your own people correct them; we do not clean, correct, merge, reconcile or migrate records. A check that is too strict gets worked around, so the checks are agreed with the people who use the screen. Where the rule at fault sits inside a packaged billing or customer product, its own specialists deal with it; we do not work inside one. We do not work on the network, and we do not keep the old applications running. Our published terms on access cover code, not customer records. We give no legal advice and do not say what any rule requires of your firm or that any work makes it compliant. 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 clean-up, once paid for, stops being something the firm does again every year. |
| CTO or CIO | The rule that spoiled the record is replaced, module by module, and an incomplete entry is refused or set aside where it is made. |
| CFO | Correcting records stops being a cost that returns every year with no end in sight. |
| COO | Agents and field staff are asked for the detail that matters while they can still get it, and the same account is not corrected twice. |
| Head of regulatory affairs | A detail the firm must be able to rely on is made compulsory in the system, and not only in a policy document. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| 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 find the step that keeps producing wrong records and rebuild it. |
| TRAI’s Standards of Quality of Service regulations, 2024, in force from 1 October 2024, set benchmarks for billing complaints, adjustments and refunds, with records behind each report. | We give no regulatory advice and do not say what they ask of your firm. For applications an operator built, we trace where records go wrong and rebuild the step at fault. |
| India’s Digital Personal Data Protection Rules, 2025, published on 13 November 2025, ask Data Fiduciaries for safeguards and logs, with most duties from about 13 May 2027. | The same limit applies. The assessment’s map shows where each copy of a customer’s details is made; your advisers decide what the rules ask. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We rebuild the one part that keeps spoiling the records, so that the next clean-up is the last one.
Sources
In this issue
Customer data wrong or incomplete
Research note 1
Operators Clean Their Customer Records Every Year. What Nobody Has Found Is Where the Records Go Wrong.
Operators clean customer records every year, yet the errors return. What the public record shows, why clean-ups do not last, and four ways forward.
Research note 3
Ready to Move Is Not the Same as Known. Where Your Customer Records Are Now, and Where They Should Be.
Before a move to a new system, customer data is declared ready because counts match. The benchmark we would set so an operator knows where its records stand.
Issue study
Identify and Record
Customer records operators cannot rely on: a regulator's finding, a fine after a billing move, the record rules Indian operators face, the options.
More from Telecom
Safety of life services depend on the old network
Operators Can Count the Accounts They Marked. What Nobody Can Count Is Who Was Never Asked.
Known security fixes never applied
Applied, and Checked by Your Own Team. Four Ways to Deal With Security Fixes That Keep Waiting, Weighed.
Too risky to move off old systems