Decision boundary
Let the system prepare the work when it cannot safely decide it.
| Situation | The system may do | A person must decide |
|---|---|---|
| Evidence is complete and the rule is stable | Create, route, notify, or update a routine record | Whether the rule remains appropriate when circumstances change |
| Evidence is missing or conflicting | Label the reason and assemble the context | What the exception means and the next action |
| The action carries a meaningful consequence | Prepare the case and preserve the history | The accountable decision and explanation |
Where automating makes it worse
When automation makes operations worse, not better.
These patterns are worth checking before a build. Each one can make an apparently efficient workflow create more correction work than it removes.
Situation 1
When the relationship is the product
Some follow-up exists not to move a process forward but to maintain a relationship. A check-in that says "I am thinking about you and your situation" is a different kind of message from "your trial expires in three days." Automating the first produces a message that technically arrives on schedule but communicates the opposite of the intended meaning: that nobody is actually thinking about this person.
The test: does the value of this follow-up depend on the recipient believing a human sent it for human reasons? If yes, the automation fails even when it works correctly.
Situation 2
When exceptions outnumber the standard case
Automation works well when the standard case happens most of the time and exceptions are well-defined and handleable. It works poorly when every third record has something unusual about it that the automation does not know how to handle, a paused relationship, a special arrangement, a sensitivity the system cannot detect.
When the exception rate is high, the cost of managing exceptions can exceed the value of automating the standard case. Measure the normal path and the exception work together before calling the workflow a time saving.
Situation 3
When the underlying process is broken
Automating a broken process produces broken outcomes faster and at scale. A follow-up sequence built on a CRM with inaccurate data sends the wrong messages to the wrong people at the wrong time, reliably. A reporting automation built on inconsistent source data produces inconsistent reports automatically, every week, without anyone making the error manually.
Fix the process before automating it. Automation is a force multiplier. It multiplies problems as readily as it multiplies efficiency.
Situation 4
When accountability needs to stay human
Some actions should not be automated not because the rule is unclear but because the accountability for the outcome needs to belong to a specific person. A payment collection message. A decision to close an account. A communication during a difficult client situation. These may follow a pattern, but the person who sends them should be aware they are sending them and own the consequence if something goes wrong.
Automation removes awareness. In situations where awareness and accountability are part of what makes the action appropriate, removing them changes the nature of the action, not just the delivery mechanism.
The cost comparison
Wrong automation can create more work than the build saves when nobody can see or correct the exceptions.
A manual mistake is visible to the person doing the work. An automated mistake can repeat until a customer, teammate, or monitoring check exposes it. For consequential work, build the review point before you remove the person from the path.
Common questions
Questions about when not to automate
If you cannot write the rule clearly enough that it would fire correctly without your involvement, the work requires judgement. Test the rule by trying to write it down. If it includes phrases like "depending on the situation" or "use your discretion," those are the judgement points that should stay human.
The automation handles normal cases correctly and edge cases in ways that are subtly wrong but hard to detect. Over time the edge cases compound. Trust erodes. The team reverts to manual handling for more and more cases, eventually making the automation redundant while continuing to maintain it.
Yes. This is the correct design for most operational workflows. Automate the parts with known rules and predictable outputs. Build a clear handoff point where the automation stops and a human takes over for the parts that require context and judgement. The goal is not to choose between automation and humans but to use each where they are actually better.
No, and treating it as binary is the usual mistake. The real question is how much safeguarding the action deserves, matched to how bad a wrong result would be and whether you can undo it. A reversible, low-stakes step, tagging a lead or drafting an internal note, can run automatically with almost no ceremony. An expensive or irreversible one, a refund, a contract change, a message to a sensitive account, should keep a human gate even when the rule is clear, because the cost of being wrong outweighs the minutes saved. Spend the effort where a mistake actually hurts, not evenly across everything.
Before building the automation, ask whether this work should be automated at all.
The most useful part of the audit path is not identifying what to automate. It is identifying what should stay human, and making that decision deliberately rather than discovering it after the automation has been running for three months.
Bring the page, report, or workflow as it is now.
We reply with the clearest next step, or an honest no.
