The first project sets expectations for everything that follows. A manageable success helps a team learn how to monitor and improve automation. A poorly chosen project can create an exception queue that nobody owns. The selection process should therefore consider operational fit as carefully as potential time savings.
Create a short inventory of recurring work
Ask each team to describe tasks they repeat, the systems involved, and the point at which work tends to wait. Look for copying between tools, repeated status checks, standard reminders, and reports assembled from the same sources. Record the task rather than the tool someone wishes to buy.
Observe a few real examples. A task described as simple data entry may involve interpretation that staff perform almost unconsciously. Record where they correct names, combine records, or contact someone for clarification. These details reveal whether the workflow is ready for automation or needs to be simplified first.
Score candidates on effort and readiness
Use a lightweight scorecard with frequency, handling time, input consistency, exception rate, and consequence of error. You do not need elaborate weighting to make a useful comparison. A task with modest savings and clean inputs can be a better first project than a large process with unclear ownership.
Separate value from feasibility. A high-value process may require integration access that is not available, or it may depend on several teams agreeing new rules. Keep it on the roadmap, but do not assume it is the right pilot. The first automation should be something the business can actually operate and evaluate.
Prefer simple rules before adding AI
If a lead should go to a particular salesperson based on region, an explicit rule may be enough. If a message needs to be interpreted to identify its subject, AI could help prepare a classification. Use the least complex method that handles the task reliably and can be explained to the workflow owner.
This distinction helps control both cost and errors. Fixed rules are easier to test against known cases. AI adds flexibility but may also produce uncertain results. When interpretation is necessary, decide what confidence or review process is acceptable before allowing the output to trigger consequential actions.
Example: reminders versus invoice approval
Imagine two candidates. The first sends an internal reminder when a review task is overdue. The second reads supplier invoices, decides whether they are valid, and authorises payment. Both may be repetitive, but their consequences and verification requirements differ considerably.
The reminder is a more manageable first project if task ownership and due dates are reliable. Invoice intake could still be useful as a later assisted workflow: extract fields, identify missing information, and prepare a review queue. Separating preparation from approval can capture some value without delegating the entire decision.
Establish a baseline before the pilot
Measure how much work the task currently creates over a representative period. Include interruptions and correction time when practical. If the task occurs only at month end, observing a quiet week will not tell you much. Choose a period that reflects the workload the automation is intended to handle.
Define a small set of success measures. Handling time, waiting time, duplicate records, and unresolved exceptions may be useful. Select the measures that reflect the problem you are trying to solve. Avoid counting automated actions as the only result; a system can perform many actions without making anyone's job easier.
Agree ownership and a fallback
Name the person who will review failures and the person who can approve changes to the rules. These may be different people. Document how the workflow can be paused and how unfinished work will be completed manually. The fallback should be practical enough to use during an ordinary working day.
Also decide who owns the connected accounts and credentials. An automation tied to one employee's personal account can stop unexpectedly when their role changes. Use an access arrangement appropriate to the systems involved and limit permissions to the actions the workflow actually needs.
Run a controlled first release
Begin with a limited source, team, or type of request. Watch the outputs and collect exceptions instead of assuming the first successful run proves reliability. Review what went wrong, whether the rule was unclear, and whether the source information was suitable. Improve the process before increasing the volume.
At the review point, compare net effort with the baseline. Include supervision and maintenance. Decide whether to expand, revise, or retire the automation. Stopping a weak pilot is a useful outcome when it prevents a larger investment in a process that is not ready.
First-automation checklist
- The task occurs often enough to observe a meaningful result.
- Inputs, outputs, and decision rules are described in plain language.
- Exceptions are understood and routed to a named person.
- The consequences of an incorrect action are acceptable for the pilot.
- A baseline and success measures exist before implementation.
- The team can pause the workflow and finish work manually.
Frequently asked questions
Should the first automation target the biggest time-consuming task?
Not always. A large task may contain many changing decisions or unreliable inputs. Choose the best combination of value, readiness, and manageable consequences. A smaller project can establish the monitoring and ownership practices needed for more complex work later.
What if our process changes every week?
Stabilise the important rules before automating them. You can still automate a consistent subtask, such as collecting submissions or sending an acknowledgement. Avoid encoding an unstable approval process that will need frequent repairs and confuse the people using it.
How many automations should we launch at once?
For a first initiative, keep the scope small enough that the owner can inspect results and explain failures. Launching several connected workflows simultaneously makes it harder to identify causes. Expand when the team can support the existing process without hidden effort.
