Most automation projects don’t fail because the technology doesn’t work.
They fail — or stall, or underperform, or quietly get abandoned six months after launch — because nobody answered three basic questions before the project started.
Not “which platform should we use.” Not “Zapier, Make, or n8n.” Those are real questions, but they’re not the first ones. The first three questions are about the operation itself, not the tools you’re about to point at it.
Here they are.
Question 1: What is the manual process path, start to finish?
You cannot automate a process you don’t fully understand. That sounds obvious. In practice, almost nobody has actually mapped it — every step, every click, every decision point — before automation gets discussed.
Two things matter here.
The standard path is the ideal, error-free route the data takes from the moment it enters the process to the moment the process is done. Most teams can describe this in general terms. Fewer can describe it precisely enough to hand to someone else.
The exceptions are what happens when the referral record is missing the DOB, when an email comes in formatted differently than expected, when a field that’s supposed to be populated is blank. Every real-world process has exception paths, and the exception paths are usually where the actual complexity lives — not the happy path.
There’s a hard rule buried in this question: if a process depends on human intuition rather than strict, describable logic, it is not ready for automation. Not “harder to automate” — not ready. Intuition-dependent steps need to be redesigned into explicit rules first, or they need a human to stay in the loop by design, not by accident.
Question 2: Is the underlying process already optimized?
Automating a broken process doesn’t fix it. It just lets you generate the same mistakes faster, and with less visibility into where they’re coming from.
Before any line of automation logic gets written, three things are worth checking.
Elimination: before building anything custom, check what the platforms you already have can now do on their own. Most applications have added native automation, AI, or MCP-based capabilities since you first implemented them — steps your team still does manually today may already be solvable with a feature that didn’t exist, or wasn’t considered, when the system went in.
Standardization: is everyone on the team actually doing this task the same way, or has each department quietly built their own workaround over the years? Automating five different versions of the same process means picking one, and that decision needs to happen deliberately, not get made by default inside a workflow tool.
Clean data: is the input structured — a CSV, a database, a form with defined fields — or unstructured, like handwritten notes or emails that vary in format every time? This is where a lot of automation projects quietly die: the logic is fine, but the data feeding it isn’t consistent enough to trust.
This is also where the familiar failure patterns show up — the spreadsheet that started as a stopgap and became load-bearing infrastructure, information that gets re-keyed and manipulated in pivot tables or a separate version of the same system stood up for each operational area, the status update that lives in one tool and gets manually downloaded and dropped into an already-complex worksheet. None of that is a technology problem. It’s a process-readiness problem, and automating around it usually makes it more expensive to unwind later, not less.
Question 3: What is the financial and operational ROI?
Automation isn’t free. It costs time to build and money to maintain, and both of those costs are ongoing, not one-time. Before committing, three numbers are worth having an honest answer for.
Time saved: how many hours per week does this actually save your team — not in theory, but based on how the process runs today, exceptions included?
Maintenance overhead: who fixes this when a third-party platform updates its API and the workflow breaks? Every automation has an owner, whether or not anyone assigned one.
Risk reduction: does this eliminate a class of data-entry error that’s currently costing the company time and money — a missed invoice, a duplicate record, a compliance flag that got missed because a form was filled out inconsistently? Sometimes the strongest ROI case isn’t time saved at all. It’s the mistake that stops happening.
The order matters
These three questions have to be asked in this order, not worked backward from a tool someone’s already excited about.
Map the process first. Confirm it’s actually optimized second. Then — and only then — does the ROI conversation produce numbers worth trusting, because they’re built on a process that’s understood and clean rather than a guess layered on top of a mess.
Skip the order, and you get what most stalled automation projects have in common: a tool that was implemented correctly, running against a process nobody had actually mapped.
If you’re not sure how your organization would answer these three questions right now, that uncertainty is usually the most useful starting point there is.