Getting Your Data Ready for AI: The Unglamorous Prerequisite

Every AI pitch you will hear this year contains a quiet assumption: that your business data is sitting somewhere tidy, labelled, and ready to be reasoned about. Yours is not. Yours is in four systems that disagree with each other, six spreadsheets of varying honesty, and an inbox. This is not a criticism; it is the normal condition of a company that grew by serving customers instead of by curating databases. But it is the actual starting point, and the pitches skip it because the unglamorous part is not what sells.

So this is the article about the unglamorous part: what "messy data" concretely means, why AI makes inconsistency worse rather than fixing it for you, and the order of operations that gets a normal SMB from here to there without the phrase "data warehouse" appearing in a proposal.

What messy actually looks like

Forget abstractions like "data quality". Messy has faces, and you will recognise them. The same customer exists three times, as "Smith Ltd", "Smith Limited" and "J. Smith", each with part of the order history. A field that should be a category is free text, so the same machine appears as "Press 2", "press2" and "the big Heidelberg". Dates arrive in two formats depending on who typed them. One spreadsheet is load-bearing for the whole quoting process and fully understood by exactly one person, who built it in 2019 and has strong feelings about its merged cells. Quantities live in cells that say "12 boxes (approx)". Every business we have ever looked inside has some version of this list, including, in places, ours.

None of it stopped you running the company, which is exactly why it never got fixed. A human reading "12 boxes (approx)" knows what it means. The trouble starts when you want software to read it instead.

Why the model will not clean up after you

It is tempting to hope that AI is the fix for messy data, since the models are famously good at reading messy things. They are, and that is the trap. A model handed inconsistent inputs does not reliably stop and file a complaint; it produces a plausible answer anyway. Ask a system to total what Smith owes you while Smith exists three times, and you will get a number. It will look confident. It may quietly cover one Smith out of three, and nothing in the answer will say so, because plausibility is precisely what these models are optimised to produce. We made this argument from the buying side in the API wrapper piece and from the document side in the OCR piece, and it lands the same way here: the machine must be able to say "I am not sure", and inconsistent master data quietly undermines its ability to know that it should.

So data readiness is not a compliance exercise. It is the difference between an AI feature that saves your team time and one that generates confident nonsense at scale, which your team then spends time distrusting.

The order of operations that actually works

The good news is that the enterprise version of this project, the year-long data programme with a steering committee, is not what you need. What works at SMB scale is narrower and much cheaper, and it runs in a specific order.

Start from one use case, not from "our data". You are not making your data ready for AI in general; you are making specific fields trustworthy for one job, invoice matching, quote generation, demand estimates, whichever single process you picked, and the honest way to pick it is the same one we described in where AI actually pays for itself. The use case tells you which fields matter, and suddenly the mess shrinks: most of your data can stay messy, because most of it is not involved.

Then fix forward before you clean backward. Cleaning history is expensive archaeology; capturing new records consistently is a habit change. Agree what the fields are, make the system enforce them where it can (a dropdown where there was free text costs nothing and ends an entire category of mess), and from that day the data improves on its own. Clean backwards only as far as the use case needs, which is often months, not the decade you dreaded.

Then give every fact one home. Most duplication is not carelessness; it is the same fact living in two systems with no plumbing between them, so people retype it and versions drift. Deciding that the customer record lives in one place, and everything else reads from it, is the decision that buys you the most in this whole exercise, and it is not an AI decision at all. It is the integration problem, and we wrote the plain guide to that plumbing on Monday precisely because so much of a typical "AI readiness" project turns out to be it.

And keep a human in the loop while trust builds. The first weeks of any automated flow are for finding the mess you did not know about, and the review queue is where it surfaces politely instead of expensively.

The honest endings

Two of them, per house rules. First: if your data already lives structured in one well-kept system, you may not have a readiness problem at all, and you should be suspicious of anyone selling you a preparation project; the question for you is only whether the use case itself pays, and sometimes the answer is that rules beat models and you need no AI whatsoever. Second, the reverse: even if you never buy a single AI feature, the sequence above pays for itself in the boring currency of fewer wrong invoices, faster quotes, and reports you do not have to argue with. Data readiness is just operational hygiene wearing a fashionable coat, which is the most reassuring thing we can say about it.

If you want to know where your own gap is, that is literally what our audit does: €1,200, fixed, we map one process end to end, data state included, and you get a precise plan and a fixed quote for your exact workflow, credited in full toward the build if you go ahead. Or start smaller: tell us which process you would automate first and we will tell you, on a free call, whether your data is ready for it and whether the honest answer is that you do not need us yet.