Nobody wants to pay for data work, and everybody pays for it

Three systems, three answers

The CRM has a customer, the billing system has an account and the support desk has a contact. They mostly refer to the same people, and nobody can say precisely where they do not. Every report built across the three carries a footnote, and the footnote is where the arguments live.

This is the normal condition of a company that has been trading for a while. It is not a failure of tidiness. It is what happens when three tools are bought at three different times to solve three different problems.

Automation inherits it all

A model fitted to those records learns the disagreement along with everything else. An automation that acts on them is worse: it takes an ambiguity that used to be resolved by a person, case by case, and applies one resolution of it at volume with nobody watching.

Automating on top of records that contradict each other does not remove the contradiction. It gives it authority and a schedule.

The disagreement was survivable while a person resolved it. It stops being survivable the moment it is applied a thousand times a day.

Name the system of record

For every field that matters, one system is allowed to be right and the others hold copies. That sentence is cheap to write and expensive to agree, because it is a decision about which team is authoritative rather than about which database is better.

Identity is the hard part

Most of the difficulty collapses into one question: when are two records the same thing. Company names arrive with and without the suffix, addresses are entered four ways, and the email that ties them together is a personal one on half the rows.

key = normalise(name, domain)
merge(records, key)

A deterministic key, written down once and applied everywhere, is worth more than a similarity model nobody can explain on the day it is wrong.

History, not just now

Operational systems overwrite. They hold what is true today, and the field that mattered — what the status was when the order shipped — was replaced the next time somebody edited the row. Anything that needs to learn from the past needs the past to have been kept on purpose.

Make the disagreement visible

The useful early deliverable is not a warehouse. It is a small set of checks that run daily and report where the systems disagree, in counts a manager recognises. Airflow or a scheduled job and one table is enough to start.

How much is enough

Enough is the fields the automation touches, and no more. A foundation project scoped to everything the company holds will not finish, and it will discredit the idea for years afterwards.

The order that works

In practice the sequence is short, and it is always the same one:

1. pick the one process worth automating
2. name a system of record per field
3. fix the key that joins the records
4. report the disagreements daily

Then build the automation, on ground that will hold it.