Automation can make a good process faster. It can also make an ambiguous decision, broken field or bad customer experience happen at scale. The most valuable automation decision is sometimes “not yet.”
A do-not-automate-yet checklist identifies the conditions under which manual work is still producing essential learning or protecting the system. It does not reject automation. It defines what must become stable, observable and reversible first.
Do not automate an undefined decision
If two experienced operators would make different choices from the same record and cannot explain why, the decision is not ready. Examples include “send qualified leads to sales,” “flag high-intent accounts” or “choose the best creative” when the underlying terms have no operational definition.
Before automation, write:
- required inputs;
- decision rule;
- allowed outputs;
- exceptions;
- evidence of a correct result;
- owner of the rule.
Do not automate unstable inputs
A workflow is fragile when it depends on fields that are frequently missing, manually reinterpreted or populated differently by each source.
Measure input coverage and consistency. Sample records. If missing data would route a customer incorrectly, define a safe unknown path instead of guessing.
Do not automate a process with hidden repair work
A manual process may appear repetitive because operators silently correct duplicates, recognize exceptions and recover failed integrations. Map that work before removing the human step.
Ask operators:
- What do you check that is not in the procedure?
- Which records do you distrust?
- What makes you override the normal route?
- How do you know a prior step failed?
- Which customer situations need judgment?
Do not automate without observability
The workflow needs more than a success count. It should expose:
- items received;
- items completed;
- items waiting;
- items rejected or routed to unknown;
- processing delay;
- rule version;
- material overrides;
- downstream outcome;
- failure and retry history.
An automation that fails silently is not efficient. It transfers labor from routine execution to late investigation.
Do not automate an irreversible action first
Begin with suggestions, queues or draft states. A human can review the proposed result while the team measures error patterns. Move toward automatic execution only after the evidence supports it.
Use a progression:
- Shadow: automation predicts; people continue the existing process.
- Assist: automation prepares a recommendation or draft.
- Approve: automation acts after a human gate.
- Bounded execute: automation handles low-risk cases and escalates exceptions.
- Broader execute: scope expands after monitored evidence.
Readiness checklist
| Area | Ready condition | If not ready |
|---|---|---|
| Purpose | Business decision and benefit are explicit | Keep manual; define outcome |
| Rule | Operators agree on inputs, outputs and exceptions | Run calibration cases |
| Data | Coverage and quality meet the risk threshold | Repair fields or add unknown route |
| Volume | Repetition is high enough to justify maintenance | Use checklist or template |
| Risk | Failure impact is understood and bounded | Reduce scope or retain approval |
| Observability | Success, delay, failure and override are visible | Instrument before execution |
| Recovery | Pause, rollback and manual fallback are tested | Do not enable automatic action |
| Ownership | Named role maintains rule and reviews incidents | Assign accountability |
Define stop and rollback rules
Before activation, specify:
- which error stops new actions;
- who can pause the workflow;
- how affected records are identified;
- whether actions can be reversed;
- how the manual process resumes;
- what evidence is required for restart;
- how users or customers are notified when necessary.
Test the failure path. A rollback plan that exists only in a document may depend on access or data that is unavailable during an incident.
Calculate maintenance, not only build effort
Automation creates an ongoing responsibility. Include:
- monitoring and incident review;
- rule updates when the business changes;
- connector and permission maintenance;
- testing after platform changes;
- documentation and training;
- audit of unexpected outcomes;
- eventual decommissioning.
A low-volume process with many exceptions may be cheaper and safer with a clear checklist than a complex automation.
The final decision
- Automate now: rule, data, monitoring, recovery and ownership pass.
- Automate partially: low-risk cases are stable; exceptions remain human.
- Run in shadow mode: the team needs error evidence before action.
- Standardize manually: the process needs a template or checklist first.
- Do not automate: the decision is rare, high judgment or too risky under current controls.
“Not yet” should produce a specific readiness backlog, not an indefinite rejection. When the rule is clear, inputs are trustworthy and failure is visible and reversible, automation becomes a controlled operating choice rather than a leap of faith.
