Most people expect me to come into a conversation and find things to automate. That's the job, right?
Sometimes. But the intake conversation I do before any project isn't designed to find automation opportunities. It's designed to find out whether automation is actually the right move. Those are different questions with different answers.
I've talked people out of projects. I've scoped something and come back with "honestly, a good spreadsheet and a clear process would serve you better right now." I've had conversations where someone came in convinced they needed a full CRM automation build and left with three things they could fix themselves that afternoon for free.
That's not me being unhelpful. That's the job done right.
So here's an honest list of situations where automation is not the answer. From someone who builds automations for a living.
When You Haven't Defined the Process Yet
This is the most common one and the one I see cause the most wasted money.
You can't automate a process that lives in someone's head. Or that three people do three different ways. Or that changes depending on who's in the office that day.
Automation is a fixed set of instructions. It does exactly what you built it to do, every time. If the underlying process isn't defined, consistent, and agreed upon, you're not automating a process. You're automating your current level of chaos and making it move faster.
The analogy I use: it's like paving a path before you know where people are actually walking. You'll end up with a very efficient road to the wrong place.
The fix before the fix — documentation. Write down exactly how the process works, step by step, with no room for interpretation. If you can't do that (if different people describe it differently, or there are too many "it depends" moments) the process isn't ready. That work has to happen first.
When the Volume Doesn't Justify the Build
Automation has a setup cost. Time, money, testing, documentation, ongoing maintenance. That cost needs to pay itself back in time saved.
If a process happens twice a month and takes 15 minutes each time, you're looking at six hours a year. Building, testing, and maintaining an automation for that process might cost you ten times that in the first year alone. The math doesn't work.
The threshold varies by process and by how much the time saved is actually worth. But the question to ask is simple: how many times does this happen, and how long does it take? If the answer is "not that often" and "not that long," a clear checklist or a good template might be a better investment than an automation.
Not glamorous. Not exciting. But it's the right answer for that situation.
When the Process Is About to Change
Automating something you're actively redesigning is building on a moving foundation.
I've had clients who were mid-reorg, planning a platform switch, or knew they were about to change their service model, and wanted to automate their current workflow while they figured it out. The logic was that it would save time in the meantime.
The problem is that a well-built automation is tightly connected to the specific process it was built for. Change the process and you're usually rebuilding the automation. You haven't saved time. You've done double the work.
Wait until the process is stable. Build once. Build it right.
When Human Judgment Is the Actual Deliverable
Some things should not be automated because the human element is the point.
A client follow-up after a difficult project. A response to a complaint that needs genuine empathy. A proposal for a client you've worked with for ten years. These aren't tasks to optimize. They're moments that define what kind of business you are.
AI can draft. Automation can send. But there's a difference between a tool that helps you do something better and a tool that replaces the thing entirely. When the relationship IS the product, be careful about how much you hand off.
This doesn't mean you can't use AI or automation to support these moments. A well-built system can surface the right information at the right time so your response is better informed and faster. That's different from taking yourself out of the loop entirely.
When Your Team Isn't Ready to Use It
An automation nobody uses is a waste of a build.
I've seen this happen when a tool gets built for a team that wasn't involved in designing it, doesn't understand why it exists, or doesn't trust it. They route around it. They keep doing things the old way. The automation runs in the background touching nothing.
Adoption is not an afterthought. If the people who are supposed to use the system don't buy into it (if they weren't part of the conversation about what the problem was and how to solve it) you have a tools problem sitting on top of a people problem. The automation doesn't fix the people problem.
Before you build anything, the question isn't just "can we automate this." It's "will the people involved actually use it, and do they understand why it's better?"
When You're Using Automation to Avoid a Harder Conversation
This one is rarer but worth naming.
Sometimes people want to automate something because there's an underlying issue they don't want to address directly. A team member who's inconsistent. A process that's broken because of a decision nobody wants to revisit. A client relationship that has friction nobody wants to name.
Automation doesn't fix people problems. It doesn't fix decisions that were wrong to begin with. It runs on top of whatever is there. If what's there is a problem, the automation makes it a faster problem.
If I'm scoping a project and the real issue starts to look like something other than the process itself, I say so. It's not always what people want to hear — but it's usually what they need to hear before spending money on a build.
The Honest Version of This
I want your automation project to work. The best way for it to work is to build the right thing, at the right time, on a solid foundation.
Sometimes that means telling you the timing is off. Sometimes it means suggesting you solve two smaller things first. Sometimes it means the automation you came in asking for is exactly right and we get started immediately.
The Automation Audit exists for exactly this reason. Before we build anything, we look at what's actually there: your tools, your processes, your team, your volume. We give you a straight answer about what makes sense. No assumptions. No selling you on a build you don't need.
If the answer is "not yet," that's what you'll hear.
Michelle Onizuka is co-founder and Systems Architect at Onizuka Studio. She builds automation and AI systems for small and mid-size businesses, and occasionally talks people out of the project they came in asking for.
[Book an Automation Audit](/automation-audit/) to find out what actually makes sense for your business right now.