You cannot automate a mess
Automation applied to a broken process produces a broken process at higher speed and lower visibility. Before automating, three things must be true: the process is defined, the data it runs on is trustworthy, and someone owns the outcome. Getting there is usually two weeks of work, not a transformation programme.
Written by Josh Soderblom, founder of ikonic303.
The phrase gets used to justify unlimited delay — endless cleanup before anything useful ships. That is also wrong. Here is the practical version.
The three prerequisites
1. The process is defined
Not documented. Defined — you can draw what really happens on one page and the people who do it agree.
The test: ask three people who touch it to describe it separately. Three different answers means the process has drifted and nobody has looked in years. Normal, and about a week to fix by watching rather than by workshopping.
What you do not need: a process improvement programme, a swim-lane diagram, or a consultant's map. One page. Agreement.
2. The data is trustworthy where it matters
Not clean everywhere. Trustworthy in the fields the automation depends on.
If the system will match orders to customers, customer records must be reliable. Whether every contact has a job title is irrelevant. Scope the cleanup to the fields in the path, which turns a six-month data project into a two-week one.
The test: pick 20 records at random and check the fields that matter. If more than two are wrong, fix before building. Fewer than two, build and handle it as an exception.
3. Someone owns the outcome
One named person who is accountable for the workflow working — not for the software, for the outcome.
Without this the automation has no owner, so when it drifts nobody notices, and when it fails everyone assumes somebody else is handling it. This is the prerequisite people skip and it is the one that determines whether the system exists in a year.
What is NOT a prerequisite
Worth saying, because these get used to stall projects indefinitely:
- Perfect data everywhere. Only the path matters.
- A new CRM. Migrating before fixing entry habits reproduces the mess in a nicer interface, later, more expensively.
- Full documentation. One page.
- Everyone agreeing. You need one authoriser and one operator. Universal consensus is not achievable and waiting for it is a decision to do nothing.
- A finished digital transformation strategy. Fix one workflow. Learn. Then decide.
The two-week version
If you fail the prerequisites, this is usually the whole remedy:
- Days 1–4: watch the process. Not interviews — sit with people. Draw the real one.
- Days 5–6: show the drawing to everyone who touches it. Fix it until they agree.
- Days 7–8: sample 20 records for the fields in the path. Count errors.
- Days 9–10: fix the sampled field problems, or design around them.
- Day 11: name the owner. Out loud, in a meeting, with their manager present.
- Days 12–14: decide what should stop existing rather than be automated. There is always at least one.
That is it. Two weeks, no programme.
The exception worth respecting
If the process is broken because two departments are in conflict, stop. Automation makes that measurably worse — it encodes one department's version of reality into software and hands the other side a permanent grievance.
That is a management problem and it must be solved by management first. It is the one situation where “you cannot automate a mess” should genuinely stop a project rather than delay it two weeks.
Which workflow to automate first → · CRM and sales systems →
Which workflow to automate first · CRM and sales systems · Why AI pilots die
Get in touch
Email solutions@ikonic303.dev to start with the measurement. ikonic303 is based in Colorado and works with clients nationwide.