Do you need to fix your data before you automate?

You've heard that AI needs clean data. Then you look at your CRM, with its duplicate companies and a notes field holding half the sales history, and at the spreadsheets finance keeps alongside the ERP, and you decide to wait until it's sorted. A year later it still isn't, and the work you wanted to hand over is still done by hand.

Our view is that you don't need to fix all of your data before you automate. You need the inputs to one chosen process to be reliable. That's a much smaller job, and usually one your own team can do.

What clean enough means for one process

Start from the process you plan to automate first. If you haven't picked one, which AI use case to fund first gives you a way to choose. Then check three things about that process and nothing else.

Where the work arrives

The system needs one or two known places to watch: a web form, a shared inbox, a folder, a status in your ticketing tool. If some orders also arrive by text message to a sales rep's phone, that route gets closed or replaced with a form before anything is built.

What it contains

List the fields the process needs to make its first decision. For routing new enquiries, that might be company, region, what they're asking for and roughly how big they are. If your form captures three of the four, add the fourth to the form. You don't need to go back and fill it in for every lead you've ever had.

Which system holds the record

When the system creates or updates something, it needs to know where the truth lives. If a customer's address is in the CRM, the ERP and a spreadsheet, name one of them as the record and treat the others as copies. That takes a meeting with the people who use them, and no migration.

Three kinds of mess, and which ones matter

Most data problems in a growing company fall into three kinds, and they matter differently to a first system.

• Missing: a field nobody captures, such as the purchase order number on a supplier invoice. This one matters, and the fix sits upstream: ask for it on the form, or in the template suppliers are sent. The system can flag invoices that arrive without it, which is often how the habit changes.
• Inconsistent: the same thing written five ways, such as UK, U.K., United Kingdom and GB. A system that reads documents copes with this far better than a fixed rule does, and where it can't, the team agrees a mapping once and the system applies it.
• Duplicated: two records for one customer. This matters only when the process writes back to the record. If it does, decide which record wins, usually the one with the most recent activity, and have the system flag the other for merging when it comes across it.

Old data, incomplete history and a reporting database that was never finished aren't on the list. None of them stop a system that handles new work from today onward.

Take lead routing. The CRM has two records for the same logistics company, because a rep created one from a business card and marketing imported another from an event list. For the first system, that duplicate matters at one moment: when a new enquiry from the company arrives and the system has to decide which record to attach it to. The team agrees a rule in a minute. Attach to the record with the most recent activity and flag the other for merging. The duplicates get merged one enquiry at a time, which is the order anyone would have got to them in anyway.

What to fix before you start

1. Close or redirect any route the work arrives by that the system can't see.
2. Add any field the decision depends on to the form or template.
3. Name the system of record for anything the process will create or update.
4. Decide who can change the mappings and rules once it's live.

Each of these is a small change made by whoever owns the form, the inbox or the CRM. Together they cost a fraction of a full clean-up, and they decide whether the system works. None of them needs a data scientist. AI without a data team covers who you do need.

What to leave until after

The whole-CRM clean-up, the historical import and the single source of truth for everything are real projects, and they can wait. The first system helps with them: every enquiry it handles creates a complete, consistent record, and every invoice it matches shows which suppliers send what. After a few months the newest part of your data is the cleanest part, and the backlog is smaller than it was.

There's one exception. If the process you've chosen reports on the past, such as a monthly margin report built from a year of orders, the history has to be readable. That's a reason to start with a process that handles new work, and to come back to reporting second.

A test you can run this afternoon

Pull the last twenty real cases of the work you want to automate: the last twenty enquiries, invoices or support requests. Give them to someone new who can see your systems but can't ask anyone. Could they take the next step from what's in front of them?

If the answer is yes for most of the twenty, you're ready, and the cases where it's no become your exception list. If it's no for most of them, the fix is still small: a form, a template or a field, found by asking what the new person was missing.

Take a hypothetical finance controller who pulls the last twenty supplier invoices from the accounts payable inbox and gives them to a new starter with access to the accounting system and nothing else. Fourteen go through: the purchase order number is there, the amounts match, and the new starter could have queued each one for approval. Four have no purchase order number, and all four come from the same two suppliers, who were never asked for one. Two have amounts that differ from the order, and only the buyer knows why.

That afternoon tells the controller what to do. Fourteen out of twenty is enough to start. The two suppliers get a template that asks for the order number, and the system flags any invoice that arrives without one. The two amount differences become the exception path, sent to the buyer with the order and the invoice side by side. Nobody cleaned a database, and the process is ready to build.

What to do this week

1. Write down every route by which the chosen process's work arrives today.
2. List the fields its first decision needs and check them against the form or template.
3. Name the system of record for anything it will create or update.
4. Run the twenty-case test and keep the failures as your exception list.
5. Put the full clean-up on the calendar for after the first system has run for a quarter.

If you'd like a second pair of eyes on the twenty cases, that's a good use of a strategy engagement. We go through them with you and tell you whether the inputs are ready, what to fix first and what the exception path would look like.

Get the next article when it's published.