Choosing honesty over false confidence in customer data

Context

The customer-service platform described in the first case depended on customer data from seven ERP systems. Three supplied daily CSV exports, three fed a data lake that could not write corrections back to the source, and one was available through a staged database. None updated in real time.

A separate team was building a matching engine to determine which accounts and products belonged to the same person. That service supported two products: our customer-service platform and the company’s self-service platform. It had its own QA staff and a dedicated test manager.

The presenting problem

The technical question sounded contained: how could an application find related customer accounts and products without every consuming team having to solve the matching problem for itself?

The first architecture used the Danish national personal identification number, CPR, as the primary key. Older accounts often had no CPR number, however, and some of the recorded numbers could not be verified. The fallback combined names, addresses, telephone numbers, and email addresses.

The underlying problem

Customer-service change managers had already warned us that trustworthiness mattered. They had seen earlier tools lose credibility after showing incorrect information. Once that happened, adding more features would not make staff trust the product again.

The matching engine’s first version caused a data leak. It was withdrawn for six months while the logic was reworked and compliance reviewed it. During that period, QA found an edge case in which a son named after his father, living on the same farm and sharing the same landline, would have been matched to his father’s account by the old fallback logic. It showed why a plausible-looking match could be more dangerous than an obvious gap.

The problem was therefore not only how to match more records. It was how to keep uncertain data from being presented as established fact, and how to make the customer-service platform useful when the matching service was unavailable or wrong.

What I did

I did not own the matching algorithm. My team supported the matching-engine team with QA and passed on reports of missing or incorrect data from customer service. The matching team, its test manager, and compliance owned the work required to make the service available again.

My responsibility was the behaviour of the customer-service platform when matching failed. I argued against making the application dependent on one new and unproven service. We built a separate address view that could present the raw ERP records whether or not the matching engine was available.

An unmatched customer account remained visible as its own record. Accounts appeared together in one box only when the matching engine linked them. This created two explicit tiers: raw source data and matched data. Staff could still find relevant accounts, see where information was missing, and arrange for corrections in the underlying systems without being told that an uncertain match was reliable.

What changed

The customer-service platform remained usable throughout the matching engine’s six-month withdrawal. When matching returned, it improved the view without becoming the only way into the data.

Back-office departments in the digital product area said the platform was essential when they reviewed migration cases. They used it to identify customers involved in a migration, then checked whether source records were missing information such as contact details. The platform did not silently clean those records; it made the gaps visible enough for staff to act on them.

Evidence

The initial leak and the six-month withdrawal were direct evidence that fallback matching could not be treated as a harmless approximation. The father-and-son case found by QA demonstrated a specific failure in the old logic before it could reappear after the compliance review.

The digital back-office teams’ continued use of the raw-data view during migrations showed that the product retained value without the matching engine. Reports from customer service also gave the matching team downstream evidence of missing and incorrect records.

Limits

Showing raw records separately did not make them correct. Staff still had to investigate uncertain cases and update the source systems. Because our data collection ran once every 24 hours, a correction would not appear in the platform until after the next nightly update.

The matching engine also did not cover every ERP system for most of the work. The mobile ERP was integrated only around the time I left, so many potential cross-product matches were unavailable before then.

The design reduced the consequences of an unreliable dependency; it did not solve identity quality across the company. That required the matching team, compliance, change managers, customer-facing staff, and changes to the source data.

What this demonstrates

A product can remain useful without pretending that incomplete data is certain. In this case, preserving the raw records and containing the matching service as one tier made failure visible without making the whole platform fail with it.