Your data is not ready, and that is normal
Every business finds its data messier than expected once AI starts. Why that is the rule, which projects need clean data and which do not, and where to begin.
Our position, stated plainly
What “not ready” actually looks like
| Symptom | Where it comes from | Which projects it blocks |
|---|---|---|
| Data lives in inboxes and personal spreadsheets | Years of people getting work done with the tools they had | Anything that needs to read the history |
| The same customer exists three times | Different systems, different spellings, no shared identifier | Recommendations, reporting, anything per customer |
| Fields mean different things to different people | Nobody wrote the definition down | Analytics, forecasting |
| History is incomplete or stops in 2022 | A migration, a departure, a tool that was cancelled | Anything that learns from trends |
| Documents exist in several versions | Drafts next to finals, nobody archived | Assistants that answer from documents |
None of this is a failing. It is what data looks like in a business that grew by serving customers rather than by building databases.
Projects that work today
- Email triage and drafting. Reads each message as it arrives; needs your current policies, not your history.
- Document and invoice extraction. Reads the document in front of it; produces clean structured records as output.
- Meeting and document summarising. Works on the item, not the archive.
- Assistants answering from current documents. Needs one clean version of each document, which is a small clean-up with an obvious owner.
Every one of these produces structured, consistent data as a by-product. Six months of extracted invoices is the clean purchasing history that a forecasting project needs. That is how data gets ready: as a side effect of useful work, not as a prerequisite for it.
Projects that must wait, and how to scope the wait
Forecasting, recommendations, churn models, trusted dashboards: these learn from or reason over history, and messy history produces confident wrong answers. For these, scope the data step honestly: which sources, which fields, what definitions, who owns each, how far back matters. Attach that step to the project so it has a purpose and a deadline, and expect it to be most of the effort.
What this means for you
Stop waiting for the data to be ready. Pick a project that reads fresh text, build it, and let it produce the clean records. Keep a data map, scope the data step honestly for the projects that truly need history, and revisit as the by-products accumulate. Messy data is the starting condition of every business we have worked with, and the ones that made progress were the ones that did not let it stop the first project.
Frequently asked questions
Should we do a data clean-up project before any AI?
Not as a standalone project with no consumer; those stall because nobody can see the point. Attach the clean-up to the first project that needs it, scope only the data that project touches, and let the second project extend it. Data gets clean one use at a time.
Which projects work with messy data?
Anything that reads new text as it arrives: sorting email, extracting invoice fields, drafting replies from current policies, summarising documents. The model reads the item in front of it; it does not need the history to be tidy. Those are usually the best first projects for that reason.
Which projects really need clean data?
Anything that learns from your history or reasons over it: demand forecasting, recommendations, churn prediction, dashboards that must be trusted. Garbage in produces confident garbage out, and the confidence is the dangerous part.