Do you need to fix your data before you automate anything?

You've been told AI needs clean data. Then you look at your CRM, with its duplicate companies and the notes field that holds half the sales history, 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 being done by hand.

The advice is half right. A system that reads your invoices does need the invoices to arrive somewhere it can see them. It does not need your contact list to be perfect first. The difference between those two is the difference between starting this quarter and never starting.

What clean enough means for one process

Pick the process you plan to automate first. If you haven't yet, What should you automate first? gives you a way to choose. Then check three things about that process alone.

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 project tool. If new enquiries also arrive by text message to the owner's phone, that route either gets closed or gets a form, before anything is built.

What it contains

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

Which system is 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 accounting system and a spreadsheet, you name one of them as the record and the others as copies. That decision takes a meeting, not a migration.

The three kinds of mess, and which ones matter

Most data problems in a growing business are one of three kinds. They are not equally serious for a first system.

• Missing. A field nobody captures, such as the purchase order number on a supplier invoice. This one matters, and the fix is upstream: ask for it on the form, or in the email template suppliers are sent. The system can also flag the ones that arrive without it, which is often how the habit changes.
• Inconsistent. The same thing written five ways: UK, U.K., United Kingdom, England. A system that reads documents handles this better than a rule ever did, and where it can't, the team agrees a mapping once and the system applies it from then on.
• 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 let the system merge or flag the rest as it meets them.

Notice what isn't on the list. Old data, incomplete history, a reporting warehouse that was never finished. None of those stop a system that handles new work from today onward.

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

What to fix before you start

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

That's usually a week of small changes, most of them made by the people who own the form, the inbox and the CRM. It is a fraction of what a full cleanup would cost, and it is the part that decides whether the system works.

What to leave until after

The whole-CRM cleanup, the historical import and the single source of truth for everything are real projects and they can wait. The first system helps with them more than it needs them: every enquiry it handles creates a complete, consistent record, and every invoice it matches tells you which suppliers send you what. Within a quarter the newest part of your data is the cleanest part, and the backlog is a smaller job than it was.

There is one exception. If the process you've chosen reports on the past, such as a weekly margin report built from a year of orders, the history has to be in a state the system can read. That's a reason to start with a process that handles new work instead, and come back to reporting second. Operational Efficiency covers both.

A quick test for readiness

Pull the last twenty real cases of the thing you want to automate: the last twenty enquiries, invoices or support requests. Give them to someone new, with no access to anyone's memory. Could they do the next step from what's in front of them?

If the answer is yes for most of the twenty, you're ready. The ones where it's no are your exception list, and they tell you where a person will need to step in. If the answer is no for most of them, the fix is still not a data project. It is a form, a template or a field, found by asking what the new person was missing.

Here's how that looks in practice. An operations lead pulls the last twenty supplier invoices from the shared inbox and hands them to a new starter who has access to the accounting system and nothing else. Fourteen go through: the purchase order number is on the invoice, the amounts match, and the new starter could have queued each one for approval without asking anyone. Four have no purchase order number at all, and all four are from the same two suppliers, who were never asked to include one. Two are for amounts that differ from the order, and the only way to know why is to ask the buyer, who remembers a phone call about a substitution.

That afternoon tells you everything you need. The inputs are ready for fourteen out of twenty, which is enough to start. The two suppliers get an email template that asks for the order number, and the system flags any invoice that arrives without one. The amount differences are the exception path: they go to the buyer with the order and the invoice side by side. Nobody cleaned a database. The process is ready to be built.

What to do this week

1. Write down where the chosen process's work arrives today, every route.
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. Park the full cleanup with a note: revisit once the first system has run for a quarter.

If you'd like someone to look at the twenty cases with you, that's a good use of a first call. Bring them, and we'll tell you whether the inputs are ready and what the exception path would look like.