Why does the objection sound reasonable — and where is the sleight of hand?
The concern is fair at its core. Automation built on dirty data really does amplify the mess: the lead assignment rule works flawlessly and assigns duplicates, the report builds instantly and counts one customer as three. This is not a hypothetical risk, and that's exactly why “data first” is the right instinct.
The instinct breaks at scale. “An orderly CRM” is a state you never finally reach, not a task with boundaries: while you clean up three years of history, your reps keep creating new records by the old rules. A project with no completion criterion doesn't get completed; people just get tired of it. After a year of this “preparation phase,” the company has the same database, the same objections and a year less time.
The way out is not to give up on data quality. It's to stop measuring readiness by the state of the whole database and start measuring it against a specific scenario.
Which three different things get called “no data”?
Three different diagnoses hide behind one phrase, and each is treated differently:
- There really is no data: the event isn't recorded anywhere. Nobody asks why the customer said no, the lead source isn't written down, repeat inquiries aren't linked to the first one. The gap isn't in the database; it's in the process.
- The data exists but it's dirty: duplicates, different spellings of the same company, empty required fields, “other” in every second record. The information is there, but you can't trust it.
- The data exists and is clean, but it sits in an unusable structure. Nothing is lost; it's just recorded in a way that only a person who remembers the context can read.
The third case is the most common and the hardest to recognize — it's regularly reported as the first. “We don't have the data for this report” almost always means the data is there, just in a form you can't get it out of. The first case calls for starting to collect, the second for cleaning, the third for restructuring, and only the second has anything at all to do with the size of the database.
Which diagnosis is the most common?
Auspex has a telling example of its own, in its own CRM. In June 2026 the company reorganized the lead pipeline on its Bitrix24 portal: 31,450 leads, 23 stages.
What made the pipeline unusable was neither the number of records nor how dirty they were. Three independent dimensions had been dumped onto a single axis, “lead stage”: process stage, lead type and close reason. That's why there were 23 stages — the dimensions multiplied. Meanwhile, only about 330 leads were actually active, that is, one percent.
Not a single bit of information was missing. Everything was on record: what stage a lead was at, what kind of lead it was and why it had been closed. Getting those three answers separately was impossible, because they lived in one field.
The fix was not to collect more data but to pull the axes apart: the stage now covers only the process, while lead type and close reason moved into separate fields. There are now 9 stages instead of 23. The migration moved 18,799 leads without errors, and 453 duplicates were deleted later. The remaining records — an archive from years back and duplicates — stayed in the old structure and didn't move into the new pipeline.
After a rebuild like this, something appears that wasn't there before: the ability to ask the database a question. Before the reorganization, “how many leads did we lose on price in a quarter” had no answer — not because the data was absent, but because close reason didn't exist as a separate value.
Why does data go bad upstream?
The most thoroughly researched description of this mechanism is the paper by Sambasivan and co-authors, “Everyone wants to do the model work, not the data work,” presented at the CHI 2021 conference (Google Research). The authors interviewed 53 AI practitioners in India, East and West African countries and the USA and described a phenomenon they called data cascades: compounding events causing negative, downstream effects from data issues. By their figures, the prevalence of such cascades is 92%, and they characterize them by four traits: pervasive, invisible, delayed, but often avoidable.
The study covers high-stakes domains — medicine, wildlife conservation, lending — and it would be wrong to carry its conclusions over to a small company's CRM as proven. But the mechanism as the authors formulate it doesn't depend on the industry: the problem arises upstream, shows up with a delay and far from where it originated, and gets noticed only once something that relies on it has already been built.
The practical takeaway is in the last word: avoidable. Cascades are not an inevitable price of working with data; they are a consequence of the collection stage not getting attention. This is an argument not for a general cleanup but for repairing the place where data is born.
How much data does the first scenario actually need?
The check takes half an hour and needs neither an audit nor a contractor. Take the scenario you want to launch first and write down the fields it reads from and writes to.
- Instant reply to an inbound lead: inquiry channel, contact, creation time, owner. Four fields.
- Automatic meeting reminder: date and time, contact, confirmation status. Three fields.
- Stalled deal monitoring: stage, date of the last stage change, amount, owner. Four fields.
- Loss reasons report: close reason as a separate field with a closed list of values. One field, and usually the one that's missing.
This list is your scope of data work. It's three to five fields put in order within the slice the scenario touches, not a whole database of ten thousand records. The rest of the database can stay dirty for now, and that is sequencing, not negligence: its turn comes when a scenario that needs it appears.
The side effect of this exercise is more useful than the automation itself. It often turns out that three of the four required fields are filled in reliably, while the fourth is never filled in, because it was introduced two years ago and nobody was told why. That is a process problem, not a data problem, and it costs one conversation.
Why is the capture point cheaper than retrospective cleanup?
Retrospective data recovery is sometimes not just expensive but impossible — and that is the strongest argument for repairing the capture point.
That same Auspex migration needed a precaution that is easy to miss at first glance. In Bitrix24 the MOVED_TIME field stores the date of the last stage change, and a bulk move of leads would have overwritten it with the migration date — meaning the history of “when the lead actually got stuck” would have vanished for good, in all 18,799 records at once. There would have been nothing to repair it with after the operation: the value isn't damaged, it has ceased to exist. So the original date was saved in advance, in a separate field, before the move.
Cleanup works only with what has survived. The capture point determines whether anything survives at all. The changes to it are usually small and boring:
- a required close reason with a closed list of values instead of free text;
- deduplication by phone and email when the record is created, not when the report is run;
- normalizing the format of phone numbers and company names right at entry;
- a separate field for the legal form, so that “Romashka LLC” and “Romashka” aren't counted as two customers;
- auto-filling what the system already knows from the communication history.
None of these items looks like an AI project. They determine whether, six months from now, there will be anything to build one on.
What does the first month look like while the data is still dirty?
The scenario launches on its slice and runs while the rest of the database stays in the state it was in. In parallel, something appears that didn't exist before launch: feedback on data quality in a specific place. Within a few weeks, the corrected close reason field shows that half the values in the reference list are never used, while the one the reps need isn't on it.
It's worth measuring narrowly, within that same slice:
- the share of records in the scenario's slice with all fields filled in;
- the number of duplicates in that same slice, not in the whole database;
- the time it takes to prepare a report that used to be assembled by hand;
- the share of “other” values in the reference lists the scenario reads.
There is nothing to base a promise of a specific effect multiplier on: it depends on the state of the database and the flow of operations, which are unknown before an audit. The numbers that appear in proposals and payback calculations are a forecast from a specific company's input data, not a measured result.
When is the objection fair?
There are cases where “data first” is the right answer, and naming them honestly matters more than selling a pilot:
- The scenario reads the whole database rather than a slice: a mass mailing, reactivation of dormant contacts, reporting across the entire history. Here the quality of every record affects the result, and duplicates mean a customer gets two emails.
- The decision is made automatically and is irreversible: a charge, a payment, a change to contract terms. The cost of a wrong record is not measured in inconvenience.
- The error is visible to the customer. A duplicate in the database means a second call to the same person on the same day.
In these cases, the sequence described in “The business that updates itself” applies: normalized reference lists, then checks at entry, then changes proposed by AI and confirmed by a human. There, order matters more than speed, and skipping steps is not worth it.
The difference between that article and this one is the question each answers. That one is about the order in which the data layer matures. This one is about how much work it takes to make the first step. Both come down to the same thing: data work is unavoidable, but its boundaries are set by the scenario, not by the size of the database.
What's the next step?
Auspex is a CRM implementation and business process automation company for SMBs. A conversation about automation starts with two questions, not with choosing a tool or with the size of your database: which scenario do you want to launch first, and which five fields does it read? The answers usually show that there is more data to start with than it seemed, and less work. An add-on layer of AI agents for support or lead qualification makes sense once this layer is in place; that line of work is handled by Grow2.ai, our AI division.