Master Data: The Reason Automation Projects Fail

When an automation project fails in a small or mid-sized business, it is almost never the technology. The interfaces exist, the models work, the workflow runs. It just runs on data that does not line up.

The sentence that ends these projects is rarely "that is not technically possible". It is usually: "so which field is the right one?"

The pattern is always the same

A customer sits in the CRM as "Müller GmbH", in accounting as "Mueller GmbH" and in the quoting tool as "Müller Gmbh". To a human that is one customer. To any automation it is three.

The same applies to services, item numbers, status values, cost centres. As soon as a workflow connects those fields, what never bothered anybody becomes visible — because until then a human sat in between and quietly reconciled it.

Automation does not create the problem. It exposes it.

Why this is familiar from analytics

Anyone who has cleaned up a tracking setup knows the mechanics. In GA4, Newsletter is not newsletter, an event with a reserved name is silently discarded, and a parameter over the character limit disappears without an error. The reports still look complete.

That is exactly why we built the GA4 event naming validator — it checks names against fixed rules before they go live. There is no off-the-shelf equivalent for master data, but the discipline transfers: agree the rule first, then record. Record first and clean up later, and you clean up forever.

The four fields to settle first

The company name. One binding spelling, one leading source. Everything else follows it.

The status. What does "open" mean? Quote sent, quote accepted, job started? A list of permitted values, not a free-text field.

The service. Whether a job is called "plumbing", "bathroom", "bathroom refit" or "SAN-04" does not matter — as long as there is exactly one variant.

The contact. A person with an email address, not info@. That decides later whether an automatic message arrives at all.

Four fields sounds small. It is still several days of work, because it forces decisions nobody previously had to make.

The side effect is bigger than the project

Businesses that do this cleanup almost always report the same thing: the benefit arrived before the first automation existed. Reports became usable, internal questions rarer, onboarding of new staff faster.

That is not an argument against automation. It is an argument for treating the cleanup not as tedious preparatory work but as the part of the project with the most certain return. It pays off even if the automation is never built.

Frequently asked questions

Can't we clean this up automatically?

Partly. Duplicates and spelling variants can be merged by machine. The decision about which variant counts and which status values should exist is one only you can make — and that is the laborious part.

How do we start without halting everything?

With one field and one system. The field that appears in the automation you are planning. Everything else stays as it is until it is needed.

Who should do it?

One person with authority to decide, not a committee. As soon as two people may define what "open" means, there are two meanings again.

Is it worth it with twenty customers?

Then it is an hour of work instead of a week — so yes, especially then. Effort grows with the data set, and so does the benefit.

What you can do today

1. Take the process you want to automate next and write down which fields it reads and writes.
2. For each of those fields, pull the values actually present in the system — not the permitted ones, the real ones.
3. Mark every field with more than one spelling. That is your task list.
4. For each of them define one valid variant, in writing, naming the person who decided.
5. Only then build the workflow.

If it turns out the data is spread across several systems and nobody knows which one leads, that is a project of its own. How we sort that out is described under AI & automation — or in a first call.