TL;DR
Not every process should be automated. Watch for these red flags early: "it depends" answers, missing documentation, single-person knowledge, unstable upstream systems, and processes about to change. Catching these in discovery saves months of painful development.
We've run hundreds of process discovery sessions using our Primo methodology. Over time, we've learned to spot the warning signs early—usually within the first 30 minutes of a discovery call. Here are the five red flags that make us pause before recommending automation.
"It Depends"
When you ask "What happens next?" and the answer is consistently "Well, it depends..."—that's a flag. Some conditional logic is normal. But when every step branches into multiple paths based on judgment calls, you're looking at a process that resists automation.
What we hear: "If it's a large account, I call the relationship manager first. Unless it's quarter-end. Or if they've complained recently."
The issue: Each "it depends" multiplies your automation complexity. Ten decision points with three options each means 59,049 potential paths.
No Documentation Exists
Not outdated documentation—no documentation at all. When you ask for the process steps and get "Let me show you how I do it," you're about to discover the process exists only in someone's head.
What we hear: "We've been meaning to document this. Nobody's had time."
The issue: If humans haven't been able to write down the process, automating it will require extensive discovery. Budget accordingly—or do the documentation first.
Only One Person Knows It
The process runs fine because Maria has done it for 12 years. What happens when Maria's on vacation? "We wait for her to come back." That's not a process—that's a person.
What we hear: "You should really talk to Jim about this. He's the only one who understands the exceptions."
The issue: Single points of knowledge create single points of failure—both for the current process and for the automation project. Jim gets sick, and your discovery stalls.
Upstream Systems Are Unstable
The process touches a system that crashes weekly, changes its UI monthly, or has an API that's "being deprecated soon." Your automation will inherit all that instability.
What we hear: "Sometimes the data doesn't come through, so we have to run it again the next morning."
The issue: Automation amplifies problems. A flaky upstream system that a human can work around becomes a 3am production incident when bots hit it.
"We're Replacing That System Next Year"
The dreaded modernization timeline. If a core system in your process is scheduled for replacement in 6-12 months, you might be building automation with a built-in expiration date.
What we hear: "This will all change when we go live with the new ERP."
The issue: Automation ROI typically needs 12-18 months to materialize. If the system changes in 9 months, you're underwater.
What To Do Instead
When You Spot Red Flags
Red flags don't mean "don't automate"—they mean "not yet" or "not this way." Document the process first. Cross-train team members. Stabilize upstream systems. Wait for the new system to go live. Fix the foundation before building on top of it.
The best automation projects aren't the most complex—they're the ones with stable, documented, well-understood processes where the ROI math clearly works. Save the heroic efforts for processes that deserve them.
