There are processes worth improving that are not yet worth automating. A task can be repetitive and still depend on unreliable inputs, frequent judgement or a rule nobody agrees on. Automating it too early can turn a visible inconvenience into a faster, less visible failure.
The process nobody can explain consistently
Ask two people how the task works. If they describe different approval rules, do not encode one account and call the disagreement solved. Observe a few real cases, list the exceptions and agree who owns the rule.
A process map can expose the uncertainty cheaply. The first improvement may be a shared intake form or a clearer decision table. Our automation process mapping guide helps separate a trigger, a decision and a handoff before selecting a tool.
A small saving with a large recovery cost
Consider a hypothetical weekly report that takes 20 minutes to assemble. An automation that saves most of that time sounds useful, but it also needs setup, access management, failure monitoring and somebody who can repair it when the source changes.
Compare the whole operating cost, not only the number of clicks removed. If the report is about to be replaced or the task happens rarely, a clearer manual procedure may be the sensible choice. That is not a rejection of automation; it is a decision about where effort is worth spending.
An error that is hard to notice or reverse
Copying approved meeting details into a draft reminder is different from changing a customer's price or releasing a payment. Ask how quickly a wrong action would be detected and what it would take to undo it.
Where consequences are significant, keep a deliberate review step. The automation might prepare a proposed update, show the evidence and wait for an authorised person. Microsoft's guidance on choosing work for AI assistance discusses repeatability, impact and verification. A deterministic workflow and an AI-generated recommendation have different failure modes; neither removes responsibility for the outcome.
Inputs that are not ready
Missing customer IDs, conflicting spreadsheet columns and uncontrolled inboxes make automation brittle. Decide which system is authoritative and how records are matched. Do not use a person's name alone as a reliable identifier when duplicates are plausible.
If a task depends on credentials copied into a personal account, resolve ownership first. A workflow that stops when one employee leaves has not removed the business dependency; it has hidden it in an integration.
No owner for the exception queue
A workflow needs somewhere to put work it cannot complete. “Send an email on error” is insufficient if the mailbox is unmonitored or the message does not identify the affected record. Agree a responsible team, response window and route for unresolved failures.
Make retries deliberate. Repeating a read request may be harmless; repeating an invoice creation or customer message may create duplicates. The implementation needs a way to recognise work already completed, plus a safe route for a person to investigate an uncertain result.
A useful compromise: automate preparation
- Collect the source records without changing them.
- Check required fields and flag uncertain matches.
- Prepare a draft action with supporting evidence.
- Let an authorised person approve or correct it.
- Record what was applied and what remains unresolved.
This can reduce routine effort while preserving judgement at the point where it matters. Measure how much review time remains, how often exceptions occur and whether the task actually becomes easier for the team.
What would change the decision?
Write the conditions for revisiting the idea: stable rules, reliable identifiers, enough recurring volume, a tested recovery path and an owner for ongoing operation. Then trial one bounded workflow with representative examples before extending it.
A rough break-even check
Using the same hypothetical 20-minute weekly task, suppose automation leaves five minutes of review and takes eight hours to set up. The 15-minute weekly saving takes 32 weeks to recover eight hours of setup, before monitoring, repairs or tool fees. If ongoing maintenance also takes 15 minutes each week, there is no net time saving on those assumptions. Other benefits may justify the work, but state them separately.
For a proposed automation project, a valid discovery outcome can be “repair the process first”. A smaller improvement that staff can understand and recover is often more useful than a chain of unattended actions nobody feels able to question.
