Our data is a mess. Can we automate anything?

Almost everyone says this, and almost everyone is right. It is rarely the reason not to start. It is usually the reason the first week of work looks different from what people expect.

Why it matters more for automation than for people

A person handling your data does a lot of quiet repair work. They see two records for the same client, know which one is current, and use that one. They notice a job marked complete that obviously is not. None of that is written down anywhere, which is exactly why it disappears the moment the process is automated.

Software has no such judgement. If your CRM says one thing and your finance system says another, the automation will pick whichever one it was pointed at and act on it every time, at volume, without flagging that anything looked odd. Bad data does not break an automation. It makes it confidently wrong, which is harder to spot.

What “a mess” usually turns out to mean

In practice it is almost always one of four things, and they have different fixes:

• The same thing exists in several places. Customers in the CRM, in the accounting package, and in a spreadsheet, with no shared reference between them.
• There is no stable identifier. Records are matched on company name, so “Smith & Co”, “Smith and Co Ltd” and “smith co” are three different clients.
• The real information lives in free text. Status, next action and the actual agreement are buried in a notes field or an email thread.
• Nobody has said which system wins. Two systems disagree and there is no rule about which one is right, so everyone picks the number they trust.

Only the first two are really data problems. The other two are decisions nobody has made yet.

How much has to be fixed first

Less than people fear. You do not need a tidy database before you can automate anything. You need the specific data the first automation touches to be reliable, and a decision about which system is the definitive one for that data.

That is usually a few days of mapping and a conversation, not a migration project. We tend to start narrow on purpose: one process, the data it depends on, cleaned properly. The second automation is faster because that groundwork is already in place, and the third is faster again.

When cleaning up is not the answer

Sometimes the systems themselves are the problem. If the definitive record genuinely lives in a spreadsheet that one person maintains, connecting things together just spreads the fragility further. At that point the honest recommendation is to build something that holds the data properly first, then automate on top of it. That costs more up front and it pays back further out.

Worth doing before you speak to anyone

Pick one process that annoys you. Write down every system and document it touches, and where the definitive version of each piece of information lives. If you cannot answer that last part for something, you have found the thing to fix first, and you have done it in an afternoon rather than paying someone else to discover it.