Nearly every SMB I talk to has the same reason for not starting: our data isn’t ready. It’s scattered across tools, half of it is in spreadsheets, the CRM is out of date, and surely we have to fix all that before AI can do anything useful.
It sounds responsible. It’s usually a stall — and an expensive one, because “get the data right first” has no finish line. There’s always another table to clean, another source to reconcile, and a year later you’ve spent real money tidying data and shipped nothing that uses it.
You don’t need all your data to be ready. You need the slice one project touches to be good enough.
Perfect data is a trap
The instinct to centralise everything first — one warehouse, one clean source of truth — is a big-company instinct applied to a small-company problem. It’s a multi-quarter project with its own budget and its own way of quietly failing, and it delivers zero value until the very end, if it lands at all.
The trap is that it feels like progress. You’re busy, you’re spending, there are meetings. But nobody’s life got easier, because a clean dataset with nothing built on it is just a tidier version of not starting.
The first project tells you which data matters
Here’s the thing the “fix it all first” plan misses: you don’t know which data matters until you try to use some of it. Most of what you’d spend a year cleaning, no project will ever touch.
Pick one job worth doing — a report that eats every Monday, a question answered forty times a week — and you immediately know which five fields, from which two systems, actually need to be right. That’s a weekend of cleanup, not a year. The project scopes the data problem down to something you can finish, and everything else can stay messy a while longer without costing you anything.
Messy is normal, and workable
Modern systems are far more forgiving of mess than the objection assumes. Inconsistent formatting, the odd blank field, two spellings of the same company — that’s the texture of every real business’s data, and a well-built pipeline expects it. You clean what the work depends on and leave the rest.
And a funny thing happens once something is running on the data: the gaps announce themselves. Instead of guessing what’s wrong in the abstract, you see exactly which records break the job, and you fix those. Using the data is the fastest way to find out what’s actually wrong with it — the same shape of feedback loop I described in the same question, forty times a week.
When the objection is real
I’ll be honest about when “the data isn’t ready” is a genuine stop, not a stall. Two cases.
When the input is a screenshot. If the numbers you need only exist on paper, or as an image someone eyeballs and retypes, then yes — the first project is getting that into a system, not automating on top of nothing. Automate the collecting before the assembling.
When wrong data does real harm. If a bad record means a wrong dosage, a mispriced contract, or a compliance breach — something with teeth — then accuracy is the product and you earn the right to automate by getting it right first. That’s not most jobs. Most jobs are reports and routine answers, where a wrong figure is an annoyance you catch in review, not a lawsuit.
Everywhere else, the ready-data plan is procrastination in a suit. Start with one project, let it tell you which data to fix, and clean forward from there. If you want a structured way to pick that first project, our readiness scorecard is built for exactly this, and there’s more on finding the highest-value place to begin in the two-week AI audit. The next thing to get honest about isn’t your data — it’s the bill, which is where what AI should cost an SMB picks up.