A solid brief with a missing foundation
A client came to me with a clear vision. They wanted a CEO dashboard showing real-time business health. Automated email updates to the team. A proper interface where everyone works from one source of truth instead of scattered Excel files on individual laptops.
It was a solid brief. The technology to build all of it exists. I've built versions of it before.
But as we went deeper into discovery, a different picture emerged.
Data lived on personal company laptops — not in the cloud, not in a shared drive. Files were only moved or consolidated when someone asked for them, or when a problem surfaced. There was no clear owner for the data. No defined step for who does what, in what order, when. The team would discuss and figure it out as needed, but there was no documented process — no rules anyone was actually following consistently.
That sentence is the automation killer
Not budget. Not technology. Not tool selection.
Automation and AI run on rules. They follow defined logic: if this happens, do that. If that condition is met, trigger this. If the data looks like X, route it to Y. The moment you ask an automation to make a judgment call that hasn't been defined — to handle an exception no one has mapped — it either fails silently or does the wrong thing at scale.
You can't automate a process that exists only in people's heads and changes based on who's in the room that day.
Automation doesn't fix a broken process. It moves the confusion faster.
This is the most important sentence in this post. Read it again.
If your team is currently handling a workflow through a mix of chat messages, email threads, and verbal handoffs — and you automate that — you now have a faster, more consistent version of the same chaos. The gaps don't disappear. They just compound.
I've seen this pattern across industries: a trading company where field agents send daily reports through group chats. A travel agency where quotations, bookings, and payments live in separate Excel files on separate machines. A logistics operation where 45 trucks deploy daily but status updates come through chat hours later, if at all.
In every case, the ask was "can you build us a system?" And in every case, the real work started before the build — with mapping what actually happens today.
The consultation that changes everything: Process mapping first
Before I design anything, I do a paid consultation session using Miro — a digital whiteboard where we map the process as it exists right now, not as anyone wishes it worked.
We trace every step: what starts the workflow, who does what, where the data goes, what happens when something breaks. We look for the bottlenecks — the steps where work stalls, where judgment calls happen without documentation, where handoffs fall into a void.
This session is not about technology. It's about understanding the actual operation well enough to know where automation genuinely earns its place — and where it would just be expensive wallpaper over a structural problem.
Only after that map exists do we start talking about what to build.
Five questions your team needs to answer before you automate anything
If you're evaluating whether a workflow is ready to automate, start here. These are the same questions I ask in every discovery call.
- 1
Who or what starts it?
Is there a clear trigger — a form submission, an email, a calendar event, a status change? Or does it start when someone remembers to do it?
- 2
Who does the work after the automation has done its job?
Automation handles the deterministic steps. Humans handle the judgment calls. Is it clear who owns what happens next?
- 3
What inputs does it need — and what context does it need to do it correctly?
Garbage in, garbage out. If the data coming into the system is inconsistent, incomplete, or unstructured, the output will be too.
- 4
Is this purely deterministic, or does judgment matter?
Does this step always have one right answer? Or does someone need to assess the situation and make a call? Automation handles the first. AI can assist with the second — but only if the rules for that judgment have been defined.
- 5
If something goes wrong — what happens, and more importantly, who handles it?
Every automated system will eventually hit an edge case. If there's no defined escalation path, the failure becomes invisible until it's a much bigger problem.
What "not ready to automate" actually means
It doesn't mean the vision is wrong. A CEO dashboard, automated notifications, a single source of truth — those are the right goals. The technology exists. The ROI is real.
It means the foundation isn't there yet. And building on an unstable foundation doesn't give you a faster business. It gives you a faster way to make the same mistakes.
The clients who get the most out of automation are the ones who did the unsexy work first: they mapped their process, identified who owns what, defined the rules, and cleaned up the exceptions. Only then did the build make sense — because there was something solid to build on.
That's the work I do in the consultation phase. Not because it's billable, but because skipping it guarantees a system that nobody uses, or worse, one that gets used incorrectly at scale.
If your team can't answer the five questions above clearly and consistently, you're not ready to automate. You're ready to document.
If you're sitting on a workflow that feels ready for automation but you're not sure where to start — or you've tried before and it didn't stick — that's usually the signal. The process needs to be mapped before anything gets built.
Want this built for your operation?
One discovery call and you'll know what's worth automating in your operation, what isn't, and what a working system would look like.