Choosing your first automation project
The strongest first automation project is rarely the workflow with the loudest technology request. It is the one whose trigger, outcome, ownership, and failure modes can be described well enough to improve safely. Start there, then choose the mechanism.
Define the unit of work
“Automate finance” is not a workable scope. “From receiving an invoice to recording approved fields in the accounting system” gives you a trigger, a destination, and a set of decisions to inspect. The same principle applies to support requests, product data, onboarding, or internal reporting.
Name the person accountable for the outcome. They should be able to say whether a case is complete, which exceptions matter, and who resolves them. If nobody can answer those questions, automation is likely to make ambiguity move faster.
Score the workflow, not the excitement
Use six dimensions to compare candidates.
Frequency and effort. Regular repetition makes improvement easier to observe, but volume alone is not enough. A frequent two-click step may matter less than a smaller queue that blocks revenue or creates substantial rework.
Rule stability. Ask two experienced people to explain how the next action is chosen. If their answers conflict, align the process before encoding it.
Input quality. Structured records and shared identifiers reduce uncertainty. Attachments, free-form email, and mismatched customer names introduce interpretation and reconciliation work. That may justify an AI-assisted step, but it also raises the evaluation burden.
Exception visibility. A healthy workflow can recognise when the normal path does not apply. “The automation usually works” is not enough if the remaining cases disappear into a generic error log.
Reversibility. Creating a draft or internal task carries different risk from issuing a refund, changing access, or deleting a record. Early projects benefit from a review point before consequential actions.
Measurable completion. Decide what a better process means: fewer manual handoffs, fewer unowned cases, shorter approval waits, or a higher proportion completed without correction. Avoid measures that only describe system activity.
Remove before you automate
Workflow mapping often reveals a report nobody reads, duplicate approval inherited from an older structure, or a copy-and-paste step required only because two products were never connected. Ask who uses each output and what decision it supports. Deleting an unnecessary step is more robust than rebuilding it in code.
Choose one end-to-end slice
A useful pilot begins with a real input and ends with an outcome someone can use. Automating an impressive middle step while leaving intake and follow-up manual simply relocates the queue.
Consider a hypothetical customer-service workflow. Instead of trying to automate every inquiry, begin with one recognisable request type. The system checks for required information, assembles relevant context, prepares a proposed response, and places it in a review queue. The team keeps control while learning how often information is missing and where classification fails.
Design the exception path first
For every action, document what can go wrong, how the condition is detected, what is retained, who receives the case, and whether retrying is safe. The interface should expose the reason and next step, not only a red status.
Idempotency matters whenever an event can be delivered twice. Observability matters whenever work crosses system boundaries. Ownership matters whenever recovery is partly manual. These are core behavior, not launch polish.
A practical readiness checklist
- There is one clear trigger and one useful end state.
- Normal decisions can be explained consistently.
- The source of truth for critical information is known.
- Representative normal and difficult examples are available.
- A named person owns the outcome and exception queue.
- Consequential actions have review or reversal controls.
- A process metric and observation period are agreed.
If several workflows qualify, prefer the one with a meaningful outcome, manageable operational risk, and an engaged owner. A first automation should improve work and establish a reliable way to evaluate the next opportunity.
CTA: Have a workflow you want to assess? Tell us about your project.