Inside the Build: One Source of Truth for Every Customer Record

Here is how we built one source of truth for every customer record for a business where customer details lived in three separate places: the CRM, the invoicing tool, and a support platform. An address change had to be made three times by hand, and whichever system got missed became the one someone eventually quoted or billed from, usually discovered on a call with an annoyed client rather than beforehand.

This is one of the case studies on the case studies page. What the three systems looked like before, what got built, and how conflicts get handled instead of silently overwritten.

Why Three Systems Ended Up With Three Versions of the Truth

Nobody set out to create three versions of the same customer. Each system was built to do its own job well, and each one happened to store its own copy of the customer’s details as a side effect. Over time, small updates in one place and not the others quietly pulled the three records apart, until nobody could say with confidence which one was actually current.

How One Source of Truth for Every Customer Record Actually Works

The fix is a synchronisation layer with a defined source of truth assigned per field, not just per system. A change made in the right place propagates to the others automatically through webhooks. When two systems disagree, the conflict gets logged for a person to look at rather than one value silently overwriting the other, since a silent overwrite can just as easily destroy the correct value as the wrong one.

Why Logging Conflicts Beats Auto-Resolving Them

An automatic sync that always picks a winner sounds convenient until it picks wrong, and by then the original, correct value is already gone with no trail back to it. Logging the conflict instead means the system stays honest about what it does not know, and a person makes the one call the automation genuinely should not make on its own.

Why This Is the Same Discipline as Trustworthy Ad Reporting

Treating one field’s value as authoritative and propagating it outward, rather than letting each system keep its own copy, is the same idea behind how we reconcile ad spend with the CRM elsewhere on this site. Both problems are really the same problem: multiple systems each keeping their own version of a fact that should only have one version, using something like a defined system of record rather than an ad hoc sync script to keep it that way.

Why Webhooks Instead of a Scheduled Batch Sync

A sync that only runs once an hour or once a day means every other system stays out of date for part of that window by definition. Reacting to a change as it happens, through webhooks, keeps the gap between a real update and the other systems knowing about it down to moments rather than however long the batch interval happens to be. The nightly check still exists underneath that, as a safety net for anything a webhook missed, but it is a backstop, not the primary mechanism. A business running on a scheduled batch alone would still have a window every day where a customer’s record was correct in one system and stale everywhere else, which is exactly the gap this was built to close.

What a Nightly Check Actually Catches

Staff update a customer’s details once now, and the other systems follow within moments instead of requiring three separate updates. The nightly check exists for the rare case something still drifts, surfacing it as a visible report instead of letting it surprise someone mid-call with a client.