How clean does our data need to be before AI is useful?
Less perfect than most people fear, but more connected than most companies have. You need records that can be joined by an identifier surviving across systems, enough history to establish what normal looks like, and consistent enough field usage that a category means the same thing twice. You do not need a warehouse, and waiting for clean data is how projects never start.
Joinability beats cleanliness
Messy text is something a model handles well. It can read a technician's shorthand note, an inconsistent service description, or a transcript full of interruptions. What it cannot do is invent a relationship that does not exist in the data.
So the question is not whether your notes are tidy. It is whether you can tell that this call, this customer and this invoice are the same story. Phone number, email, service address and a lead identifier carried through from the web form do most of that work.
Enough history matters for a second reason: anomaly detection needs a baseline. Without a year or so of records, the system cannot distinguish a genuine drop from an ordinary seasonal trough, and it will either cry wolf or stay silent when it should not.
The three things that actually block progress
- No shared key. Marketing data with no identifier that survives into the operational system means attribution collapses to guesswork.
- Free-text where a category belongs. If job type is typed by hand, the same service appears a dozen ways. A model can normalize it, but you should fix the source too or you will normalize forever.
- Short retention. If call recordings expire in thirty days or the CRM purges history, you cannot establish a baseline, and anomaly detection without a baseline is just noise.
Cleaning happens as a byproduct
One underrated effect of connecting systems is that it makes existing data problems visible for the first time. Duplicate customers surface because the join fails. Mis-tagged sources surface because the revenue does not follow the pattern. Abandoned custom fields surface because nobody can say what they mean.
That is uncomfortable in month one and valuable by month three. The exception report is often the most useful artifact of an early integration, and it is worth reading rather than suppressing.
A pragmatic sequence
Start with the data that is already structured and already valuable: calls, jobs, invoices, spend. Get those joined and reported before touching anything that requires a data project. Fix source-level problems only where they block a specific decision you have named.
This is the opposite of the warehouse-first instinct, and it is deliberate. A working revenue view built on three connected systems teaches you which data problems actually matter. A twelve-month data initiative teaches you nothing until it ends. The platform approach exists to shorten that first loop.
Topics: data quality · integration · readiness · joins
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.