Once a business has decided automation is appropriate, the next question is not “Which tool should we buy?” It is “Which process is a suitable first candidate, and how will we know whether it is safe and useful to automate?”
Good starting points are usually specific, bounded tasks with a known trigger, repeatable steps, dependable inputs, and a clear way to check the result. Examples may include sending a routine notification after an approved event, copying validated data between systems, generating a standard document from reviewed information, or preparing a recurring report. Whether any of these is a good fit depends on the actual workflow, data, systems, and consequences of failure.
This article focuses on what to automate after the business has decided to explore automation. It is different from When Should a Growing Business Invest in Automation?, which addresses whether and when to invest. The framework here is an editorial prioritisation aid, not an ROI formula, engineering standard, or promise of time savings.
List work before selecting a tool
Ask the people who perform and receive the work to name repetitive tasks that consume attention or create avoidable handoffs. Look for duplicate data entry, reminders, routine status updates, document assembly, approval routing, reconciliation preparation, customer follow-up prompts, and recurring reports. Do not assume that every task which feels repetitive can be automated safely.
Describe one candidate as a process rather than a vague pain point. “Automate finance” is too broad. “When an approved purchase request is complete, notify the assigned reviewer and record the decision” is specific enough to inspect. Record the trigger, input, normal steps, decision points, output, owner, systems involved, exceptions, and current manual fallback.
Separate routine mechanics from judgement. A task may contain a standard portion suitable for assistance and a decision that must stay with an authorised person. For example, software might prepare a document from approved fields while a person checks unusual terms before sending it. This division should be explicit; do not imply that an automated output is correct merely because it was generated.
Use a four-factor prioritisation matrix
Assess each candidate qualitatively as low, medium, or high on four dimensions. These labels are conversation prompts, not a weighted score. A “high” on one factor does not automatically make a process the best candidate.
| Candidate | Frequency | Standardisation | Error impact | Integration readiness | Initial view |
|---|---|---|---|---|---|
| Routine notification after a complete approval | Medium/high | High | Low/medium | High if source and recipient are reliable | Often a contained candidate; confirm duplicate and missed-notification handling |
| Reconciliation across inconsistent records | Medium | Low/medium | Potentially high | Low/medium | Fix data ownership and exception rules before automating decisions |
| Customer follow-up reminder from a validated CRM stage | Medium/high | Medium/high | Medium | Medium/high if stage data is current | Could automate the reminder while leaving message and judgement with the owner |
| Approval of an unusual supplier exception | Low/variable | Low | Potentially high | Variable | Keep the decision with an authorised person; a routing aid may be considered |
Use these prompts for the four dimensions:
- Frequency: How often does the task occur, and is volume reasonably predictable? Repeated use may justify attention, but a frequent task with unstable inputs can still be a poor first candidate.
- Standardisation: Are the trigger, steps, rules, and expected outcome clear? How often does a person need to interpret context or choose between exceptions?
- Error impact: What could happen if the automation repeats an error, sends something to the wrong person, skips a check, or acts on stale information? Consider customer impact, rework, money, commitments, records, and any applicable obligations.
- Integration readiness: Are the systems accessible through supported connections? Are the required fields accurate, consistently defined, and owned? Can a person see what happened and correct a failure?
Frequency is not a proxy for value; high impact does not mean automation is appropriate; technical connectivity does not prove data quality. Use the combined picture to select a small, reversible experiment or decide that process repair should come first.
Stabilise the process and its data
Before implementing, write down the normal path and the exceptions that matter. Clarify which system is the source of truth for each input, how missing or conflicting data is handled, and who may approve an action. If two teams use different meanings for “complete,” “approved,” or “urgent,” standardise those meanings before encoding them.
Check that records are sufficiently accurate and current for the intended task. Decide who corrects an error, whether the automation can update the source system, and which changes need review. Limit access to the information required for the task and involve the organisation’s privacy, security, legal, or compliance specialists if the data or decision warrants it. This article does not assess those obligations.
Do not silently automate a process because a system offers a button or template. Ask what happens when the connection is unavailable, a field is empty, a duplicate event arrives, or the result is not what the user expects. A process that cannot explain or recover from a failure may need a manual step or a narrower scope.
Define the human role and control points
For each automated step, name the owner accountable for the process and clarify what a person must still review. A person may approve an action, handle exceptions, monitor a queue, reconcile outputs, or pause the automation. These are different duties; “human in the loop” is not a complete operating design.
Set control points that fit the impact:
- show the data and rule used to produce an output;
- provide a review step before consequential external actions;
- record when a task starts, completes, fails, or is changed;
- alert an owner when a defined error or exception occurs;
- prevent repeated sends or duplicate transactions where possible;
- restrict who can change rules, credentials, and destinations;
- provide a way to pause the workflow and complete the work manually.
Some low-impact notifications may not require the same controls as a payment, customer commitment, hiring decision, or regulated action. Determine the appropriate controls with the accountable process owner and qualified specialists, rather than applying this list as a universal compliance checklist.
Pilot one narrow workflow
Select a process with a clear beginning and end, a named owner, and a manual fallback. Test it with representative cases, including incomplete input, duplicate triggers, delays, system errors, and common exceptions. Compare the output against the current manual process before allowing it to act without review.
Agree what the pilot is meant to learn. Useful observations may include whether the right cases are triggered, whether data is transferred correctly, whether exceptions reach the right person, whether users understand the output, or whether manual corrections are still needed. Do not claim a universal percentage of savings. Record the baseline, sample, limitations, and changes made during the test if you later communicate measured results.
Define a rollback path before launch. Identify how to pause the workflow, who has access, what queue or manual procedure takes over, and how unfinished items will be reconciled. If an error appears, be able to determine which records or people may have been affected and who decides what response is needed.
Monitor ownership after launch
An automation is an operating process with a lifecycle. Assign someone to monitor its status, review exceptions, maintain access, and update it when source systems or business rules change. Ensure that another person can take over if the owner is unavailable. Keep instructions accessible: what the workflow does, what it does not do, how to pause it, and where to report an issue.
Review whether the original need still exists. A process may change, integrations may stop being supported, data quality may decline, or the team may no longer use the output. Retire or simplify automation that is not serving a clear purpose. “It is already built” is not a reason to keep an unreliable process running.
Frequently asked questions
Which business tasks are good candidates for automation?
Consider tasks with a clear trigger, repeatable steps, dependable data, a defined result, and manageable exceptions. Routine notifications, data movement, document preparation, or report assembly may be candidates, but each needs assessment in its real context.
Should we automate a process that has frequent exceptions?
Usually, first understand and classify the exceptions. If the normal path is stable, a tool might assist with that portion while routing exceptions to a person. If exceptions dominate or require unclear judgement, simplify or clarify the process before automating it.
How do we know whether the data is ready for automation?
Check whether inputs are accurate, current, consistently defined, and owned in a known source. Test missing, duplicated, conflicting, and outdated values. If people routinely correct the same fields, improve the information process before relying on it for automatic actions.
What should happen if an automation fails?
The process should make failures visible, notify an owner, preserve enough information to diagnose the issue, and allow work to continue manually or through a defined alternative. The exact recovery design depends on the potential impact and the systems involved.
Choose the smallest useful first step
Pick one repetitive workflow and assess it across frequency, standardisation, error impact, and integration readiness. If the process or data is unclear, fix that first. If it is stable enough to test, define the owner, controls, measures, manual fallback, and rollback before implementation.
Specular’s Technology & Automation service can help assess a workflow and its technical fit. If the underlying process needs clarification, Business Consulting may be a useful starting point.