Identify and Record

1. At a Glance

Issue study · From the public record. None of the organisations described here was an IOanyT client, and IOanyT had no part in the events described. Everything about them comes from the public record.

Organisation type	Telecom operators whose customer records are held in several applications built around the billing system, joined by small programs that copy details between them
Size band	The operators in the record: two large UK operators. Our reader: a regional internet or broadband provider, a cable operator, a provider of connectivity to businesses, or another mid-size operator
Region	The cases: the UK. The rules: India
The decision at stake	Whether to pay for another clean-up of customer records, or to find and rebuild the step in the operator’s own applications that keeps spoiling them
The public outcome	In 2025 a regulator fined one operator £23,800,000, finding that it “failed properly to identify and record the status of telecare customers” while moving customers to digital landlines. In an older case, in October 2016, the regulator fined another operator £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
Why it matters to a mid-size operator	In India, TRAI’s Standards of Quality of Service regulations, 2024, in force from 1 October 2024, set benchmarks for billing complaints, adjustments and refunds for providers of access and broadband services and for internet providers with more than ten thousand subscribers, and ask them to “maintain complete and accurate records” of the data behind each report. An operator that cannot say where its records go wrong cannot say where a wrong bill came from

2. The Business Problem, in the Buyer’s Words

“We cleaned the customer records two years ago and again last year. Both times a team compared billing with the care portal, account by account, and both times the report said the job was done. The mismatches are back, in the same fields. My service team knows which screen to trust, and nobody can tell me why the others are wrong. Now a move to a new platform is on the table, and the proposal has a line about customer data that says the counts will be reconciled. I do not want to pay for a third clean-up, and I do not want to carry these records onto a new system without knowing what is wrong with them.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The operator is caught between a clean-up that does not last and a move that will carry the same records across.

3. What We Found

Method. 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, 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 public cases. These are the record’s own words. Neither operator was an IOanyT client.

Case	What the public record says
Virgin Media (UK), fined by Ofcom on 1 December 2025	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 fine was “£23,800,000”, for “serious systemic failures in Virgin Media’s migration process between August 2022 and December 2023”. The move was a change of network, which is not IOanyT’s kind of work. This study uses the case only for the regulator’s finding about records
Vodafone (UK), an older case from 2016	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

Why the old systems stay. In one survey of about five hundred IT professionals in the US, across industries and company sizes, run by a vendor and not about telecom, half gave the current system still working as a reason for not modernising, more than four in ten named budget limits and about a third named data migration concerns.

What Indian operators now work under. TRAI’s Standards of Quality of Service regulations, 2024, in force “with effect from 1st October 2024”, set customer-service benchmarks including “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”. 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 of 5 August 2026 proposes resolving billing complaints “within one week”; that is a proposal only, and TRAI had not notified it as of 14 October 2026. Separately, India’s Digital Personal Data Protection Rules, 2025, a cross-sector rule, apply to Data Fiduciaries in every sector. Most of their duties “shall come into force eighteen months after the date of publication” (13 November 2025), about 13 May 2027. They ask for safeguards including “appropriate logs, monitoring and review”, to “retain such logs and personal data for a period of one year”, and 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 names an old application; the link to old applications is our reading.

Our reading of why records go wrong, and stay wrong. These four are our reasoning from the record above. None is a finding of any source, and none is offered as the explanation of either named case.

1. The same detail is held in many applications, and copied between them by programs nobody has read. Each program has rules of its own: one shortens a field, one fills a blank with a default, one decides which copy wins.
2. Entry screens do not ask for what the firm relies on. A detail a policy calls compulsory is optional on the form, or goes into a free-text notes box.
3. A clean-up corrects records and leaves the rules in place. The same screens and jobs go on producing the same errors.
4. A move is planned as carrying, not as checking. Record counts are compared. Blanks, defaults and unknown codes go across.

Illustration, not a real case. A regional broadband provider keeps a customer’s installation address in its order form, its activation tool and its billing system. The activation tool was written years ago with room for forty characters. Each night a job copies the address from activation to billing. Long addresses arrive in billing cut short, and are corrected by hand; the next night the job copies the short address back. Nobody typed anything wrong.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
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	Right once the cause has gone; before that, it is paid for again
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	Useful for finding bad records; it does not name the step that makes 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	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	Our recommendation
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	We would advise against this as an answer to wrong records alone, before the step that spoils them is known

5. Our Recommendation, and the Decision It Asks of the Board

Trace a wrong customer record through the operator’s own applications, copy jobs and manual steps to the rule or step that spoils it, and write down, for each key customer field, where it is entered, where it is copied and where it is blank by design. Then rebuild the part that lets wrong records in, one module at a time, with checks at the point of entry that the operator’s own service and regulatory people agree, while the old application keeps running. Each module is checked function by function against the old one. The operator’s own people, or the firm that carries out any move, then correct the records once, after the cause has gone. IOanyT does not clean, correct, merge, reconcile or migrate the records.

6. Benchmark: Where You Are Now, and Where You Should Be

These are targets, not results. In an engagement the starting points are replaced by the firm’s own figures, taken in the first review.

Measure	Typical starting point	Where it should be	How it is checked
Places each key customer field is copied between applications	Not mapped	Every place mapped, 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 recurring kind of error tied to a named rule or step, with an owner	The specification and the risk register
Fields blank by design, or filled by default	Found at a move, or after it	Each key field marked as compulsory, optional or defaulted, from the code that fills it	The specification
Checks at the point of entry, in each rebuilt module	A detail the firm relies on is optional, or takes any text	Every detail the firm’s people call compulsory is checked where it is entered	The rebuilt module, accepted against the specification
Old functions matched to new ones, where rebuilt	Not recorded	Each function linked to its replacement	The traceability matrix
The same accounts corrected again	Not counted	Counted from the firm’s own records, and falling for each kind of error whose step has been rebuilt	The firm’s own service records

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about the customer records that keep going wrong and the applications that hold them. 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 study 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.
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. We never do a single cutover. A traceability matrix links every old function to its replacement. 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.

8. What the Client Would Own

• The map and the specification: what each of the operator’s own applications and copy jobs does with a customer record, and, for each key field, where it is entered, copied and blank by design, confirmed by the operator’s own people.
• The risk register: the steps that spoil records, listed before any price is set.
• The traceability matrix: for every module IOanyT rebuilds, every old function linked to its replacement.
• The code: the rebuilt modules are the client’s. No runtime or platform fee.
• The filled-in benchmark: each measure, where it started and where it stands.

9. What This Approach Does Not Cover

• IOanyT does not clean, correct, merge, reconcile or migrate customer records. The operator’s own people do, or the firm that carries out a move. The records that are wrong today stay wrong until they are corrected.
• IOanyT has no data-quality product and no data migration service, and does not carry out a move to a new platform.
• IOanyT does not work inside a packaged billing or customer product, and does not implement, configure, upgrade or move one. Where the rule at fault sits inside one, its own specialists deal with it.
• IOanyT does not work on the network or the systems that run it, and nothing it does keeps a service working for any customer or protects anyone.
• A detail that no program ever asked for cannot be found by reading programs. Some errors begin with a detail typed wrongly or never given; software does not cause all of these and does not solve all of them.
• IOanyT does not keep the old applications running while a part is rebuilt.
• IOanyT’s published terms on access cover code, not customer records.
• IOanyT gives no legal or regulatory advice. What TRAI’s regulations or India’s data protection rules ask of a particular operator is for its own advisers; this study does not say, does not say that any work makes an operator compliant, and promises no outcome with a regulator.
• This study does not say that IOanyT has done this work for a telecom operator. IOanyT has no published case of it.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

10. Sources

Source	Used for
Ofcom, 1 December 2025	Virgin Media: the finding about records, the period and the fine
Ofcom enforcement bulletin, case CW/01160, 26 October 2016	Vodafone: the finding, the customers, the period and the penalty
Euronews, 26 October 2016	The cause the operator gave, as reported at the time
A vendor’s survey of US IT professionals, 2025	Why old systems stay
TRAI, Standards of Quality of Service regulations, 2024 (consolidated)	Customer-service benchmarks, records, scope and exemption
TRAI consultation paper, 5 August 2026	The proposed one-week rule for billing complaints
Digital Personal Data Protection Rules, 2025, Gazette of India, 13 November 2025	Commencement, safeguards, logs and breach reporting

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, so that the next clean-up is paid for once.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →