When two systems tell the same customer different things

How does one customer end up with conflicting answers?

Start with where the fact lives. A customer's plan, address or status is almost never stored once. Billing needs it to charge, the messaging tool to pick a template, the support tool to greet the caller and the account page to show it. Each keeps its own copy, and each copy changes on a different trigger: billing when a payment clears, messaging when a campaign is built, support when an agent saves a note. None of these systems is broken. The disagreement sits in the gaps between triggers, and nobody is answerable for a gap. Exhibit 1 follows one plan change through the systems that hold it.

The route a change takes matters too. Event feeds and scheduled syncs are both normal, and neither delivers at the instant of the change. Stripe's webhook documentation says events may not arrive in the order they were generated, that Stripe retries a failed delivery for a limited period, and that the same event can arrive more than once, so a receiver should log the event IDs it has processed. Shopify's guidance says ordering isn't promised either, adds that delivery can't always be relied on, and tells an app not to depend on webhooks alone. A copy fed this way is right eventually, and a customer can't see eventually.

Meaning drifts as well. Active in billing means the invoice is paid; active in support means the account is open. A sync that maps one onto the other has made a decision, and we rarely find it recorded anywhere. Then there's plain time. A copy that was right when it was taken is wrong an hour later and looks exactly as trustworthy.

What does the customer actually hear?

Here's a composite from hospitality, not any one client. A guest moves an arrival date on the booking site. The site accepts the change and shows the new date. The confirmation email, assembled by a messaging tool from an earlier copy of the reservation, still carries the old one. The property's own system picks the change up on its next sync, so for some hours the front desk holds the old date as well. The guest now has contradictory written statements from one company and no way to tell which will be honored. They call. The agent opens the nearest screen, and if it's the stale one, confirms the wrong date with complete confidence. Now the error has been spoken, and a spoken error is harder to retract than a screen.

The guest never experiences a synchronization delay. What they meet is a company that doesn't seem to know its own mind about their booking. The lost minute on the phone is the small cost. The large one is that every later message from you gets read with doubt, including the ones that are correct.

What do staff do when two records disagree?

Sit beside an agent for an afternoon and you can watch the rules form. Billing is right about money. The customer record is right about contact details. The support tool runs behind on Mondays. Nobody wrote any of it down. It passes from one person to the next, and new starters learn it by being wrong in front of a customer. Colleagues on one team can hold different rules and give different answers to the same question.

The other habit is repair in place. The agent sees a wrong address, corrects it on the screen and tells the customer it's fixed. The system that owns the address still holds the old one, and its next sync overwrites the correction. The customer hears that it's fixed, watches it revert, and hears that it's fixed again.

Both habits make sense for the person using them. Together they turn a data problem into a training problem and a trust problem, and they bury the evidence. If every disagreement is absorbed at the desk, nobody counts how often the copies part, and nobody is asked to close the gap.

Who owns the difference between systems?

Each system has an owner who watches it, and each owner's dashboard is green. The disagreement exists only between systems, where no dashboard looks. The one person who sees both copies side by side is the customer.

The UK Government Data Quality Framework, published by the Cabinet Office on 3 December 2020, has words for this. It defines consistency as the degree to which values don't contradict other values representing the same entity, and adds that data is consistent if it doesn't contradict data in another data set. It says data is timely if the time lag between collection and availability is appropriate for the intended use. Its school example sets an agreed limit on how long a changed emergency contact may take to reach the student database, and treats a longer wait as a breach of the rule. The lesson for a business is that a lag is acceptable only if somebody chose it. In an estate that grew by adding tools, nobody did, so the lag is whatever the sync happens to produce.

The framework's foreword adds that where quality problems are found, the symptoms are often treated instead of the cause. An agent typing a correction into the screen in front of them is that sentence at work: a symptom treated at a copy while the source stays as it was.

Name one source for each fact

Decide it fact by fact. The source for a fact is the system where it's created or changed. Every other system either reads from it or says on its screen that it holds a copy. A short register is enough to start: the fact, its source, the systems that read it, and how stale a reader may be, in whatever unit the business cares about, whether minutes or days.

These working rules follow from the register. Build messages to customers at the moment of sending, by reading the source, and never from a copy stored when the campaign was assembled. Make screens that show a copy say where it came from and when it was last confirmed, so a stale value looks stale. Correct at the source and nowhere else, which means every customer-facing person needs a route to the source's owner and not only a form. And compare the copies on a schedule, record by record, for the facts customers hear differently, sending every difference to the source's owner. None of this needs a new platform to begin. A query in each system and a script that matches on identifier will show where the work is.

Exhibit 2 shows the call a customer-facing person should be able to make in seconds once a register exists, and what happens when it doesn't.

How will you know it's working?

Don't expect the systems never to differ. They will, for the length of the gap. What you're after is that when they differ, the person answering knows which system to believe and can say why, the customer hears a single answer, and the difference is recorded where someone can close it. You can check this without a project. Ask the people who answer customers to name the screen they trust for a plan, an address and a status. If they all name the same screen, the register is working. If they name different ones, you've found the first fact to settle.