You cannot automate chaos. If your records are inconsistent, incomplete, or scattered across spreadsheets, automation will not fix the problem. It will scale it.
Most conversations about AI and automation start with what the technology can do. Draft emails. Generate reports. Triage leads. Sync systems. It is impressive, and most of it is real.
But there is a conversation that should happen first, and rarely does. It is about the data underneath.
Every automation is a set of instructions that acts on information. If the information is clean, consistent, and accessible, the automation works. If it is not, the automation still runs. It just produces confident, well-formatted nonsense. And it does it faster than any human ever could.
We call this problem "Data Debt."
What "Data Debt" looks like
"Data Debt" is not a technical concept. It is a practical one. It is the accumulation of shortcuts, inconsistencies, and workarounds in your business records that make them unreliable for anything beyond the person who created them.
It builds up quietly. A sales lead gets entered into the CRM with a first name but no company. Someone logs a phone number with spaces, someone else without. A project status field has twelve variations of "in progress" because nobody agreed on a standard. A critical supplier contact list lives in a spreadsheet on one person's desktop that has not been backed up since October.
None of these feel like problems in isolation. The person who created the record knows what they meant. The system still works, because a human is interpreting the data and filling in the gaps with context and memory.
The moment you try to automate a process that touches that data, the gaps become visible. An automated email goes to "J Smith" because the first name field was never completed. A report counts the same client twice because they appear as "Acme Ltd" in one system and "ACME Limited" in another. A lead gets missed because the triage workflow could not parse a phone number with brackets in it.
When an SME tells us their previous attempt at automation did not work, the culprit is almost always "Data Debt." The automation was fine. The data was not ready for it.
Why "Data Debt" compounds
Like financial debt, "Data Debt" has a compounding effect. The longer it goes unaddressed, the more expensive it becomes to fix.
In the early days of a business, it does not matter. You have a handful of clients, a couple of spreadsheets, and everyone knows everyone. The data is messy, but the team is small enough to compensate with institutional knowledge.
Then you grow. New staff join who do not have that institutional knowledge. They look at the CRM and see a contact with three phone numbers, two email addresses, and no indication of which is current. They look at the project tracker and see status labels that mean different things to different people. They adapt by creating their own systems. A personal spreadsheet here, a notebook there, a folder on their desktop with the "real" version of the client list.
Now you have the original mess plus a new layer of fragmentation. The data is not just inconsistent. It is siloed. And each silo has its own logic that only makes sense to the person who built it.
This is the point where most businesses start thinking about automation. The "Admin Tax" is high. The team is stretched. Someone suggests connecting the systems, syncing the data, automating the reporting. It sounds like the answer.
It is the answer. But not yet. Not until the foundation is solid.
The cost of building on bad data
Automation built on unreliable data does not save time. It redistributes it. Instead of spending hours on manual data entry, your team spends hours checking automated outputs, correcting errors, and explaining to clients why they received an email addressed to the wrong person.
Worse, it erodes trust. If the first automated report your leadership team sees contains numbers that do not match reality, the project is dead. Not because the automation failed, but because the data underneath it was never reliable enough to automate in the first place.
In a commercial environment, unreliable is as bad as broken. A report that is sometimes wrong is worse than no report at all, because at least with no report, everyone knows they are guessing.
This is why at newlens, data quality is the first conversation, not the last. Before we build any workflow, we look at the data it will depend on. If the foundation is not ready, we fix that first.
Three steps to data hygiene
You do not need a data science team to get your records into shape. You need discipline, some simple rules, and a willingness to spend a few weeks doing unglamorous work before the exciting stuff begins.
Centralisation. If data lives on a single person's desktop, it does not exist for the business. It exists for that person. When they are on holiday, off sick, or leave the company, the data goes with them.
The first step is getting your core business data into a shared, central system. That could be a CRM, a shared database, or even a well-structured shared drive. The tool matters less than the principle: if the business depends on it, the business should own it.
This does not mean banning spreadsheets. Spreadsheets are excellent for working through a problem or running a quick analysis. They are terrible as a system of record. The distinction is important. Use spreadsheets for thinking. Use a shared system for storing.
Standardisation. Centralisation gets the data into one place. Standardisation makes sure it means the same thing to everyone.
This is where most SMEs underinvest. It is not exciting work. It means agreeing on a set of rules: how lead sources are categorised, what project statuses are allowed, how company names are formatted, whether phone numbers include country codes.
These decisions feel trivial. They are not. Every inconsistency in your data is a potential failure point for any automation that touches it. A workflow that routes leads by source cannot function if "Website", "website", "Web", and "Online" all mean the same thing but are entered differently.
Write the rules down. Put them somewhere the team can find them. Enforce them at the point of entry, not after the fact. Cleaning data retrospectively is ten times more expensive than entering it correctly in the first place.
Validation. Standardisation tells people what the rules are. Validation makes sure the rules are followed.
Simple checks at the point of entry catch most problems before they become embedded. A required field that cannot be left blank. A dropdown instead of a free-text box for status fields. A format check on email addresses and phone numbers. A duplicate warning when a record looks like one that already exists.
None of this is sophisticated. Most CRM platforms and form builders support these checks out of the box. The investment is not in technology. It is in the ten minutes it takes to configure the rules and the discipline to keep them enforced.
A few seconds of validation at entry saves hours of cleanup later. More importantly, it means the data is reliable enough to automate against from day one.
What this looks like in practice
Consider a professional services firm with 15 staff, two offices, and about 500 active client records. They want to automate their monthly client reporting. Each month, someone pulls data from their project management tool, their finance system, and their CRM, then builds a report in a spreadsheet and emails it to the client.
The "Admin Tax" is obvious. The data exists in three places. The report takes two hours per client. The team is spending a full week each month on reporting alone.
The instinct is to start building the automation. Connect the three systems, pull the data automatically, generate the report, send the email. Technically, that is straightforward.
But when we look at the data, we find 500 client records with 47 variations of industry classification. Project status fields that use free text instead of a fixed list. Finance records where the client name does not exactly match the CRM record, so automated matching fails for 30% of clients.
If we build the automation now, it works for 70% of clients and produces errors for the rest. The team spends their time fixing the exceptions instead of building the reports. The net time saving is marginal, and the trust damage is significant.
Instead, we fix the data first. Standardise the industry classifications. Lock the status fields to a defined list. Reconcile the client names across systems. It takes two to three weeks of focused effort.
Then we build the automation. It works for all 500 clients. The reporting week drops from five days to half a day of review. The data is clean enough that next month's automation runs without intervention.
That is the difference "Data Debt" makes. Not whether automation is possible, but whether it is reliable.
No black boxes
At newlens, we do not build systems you cannot see inside. Every workflow we create is documented, transparent, and built on infrastructure you own. If you want to change it, extend it, or take it in-house, you can.
But more importantly, we do not build on foundations we have not checked. If the data is not ready, we say so. It is a harder conversation than jumping straight to the automation demo, but it is an honest one. And it is the difference between an automation that works on day one and one that works on day one hundred.
Your data is the foundation. Get it right, and everything you build on top of it will be reliable. Skip it, and you are automating chaos.