1. Start with friction, not tools
The best automation candidates aren't the flashiest workflows — they're the ones your team complains about. Ask each person to list the three tasks they do every week that feel like busywork. Look for repetition, copy-paste between systems, and status updates that get chased in Slack. Those are the operational leaks worth mapping first.
2. Map the process end-to-end
Before automating anything, write the process down as it actually runs today — not as anyone wishes it ran. A simple format works well:
- Trigger: what event kicks the process off?
- Inputs: what data or documents are needed, and where do they live?
- Actors: who touches the work, in what order?
- Decisions: what judgment calls happen, and what rules drive them?
- Outputs: what changes when the process is done — a record updated, an email sent, a payment made?
If you can't answer these in a paragraph, the process isn't ready to automate. That's not a failure — it's the point of the exercise.
3. Define the handoffs
Most automation projects break at the seams between people and systems. For every handoff in the process, define three things: what data must be present, what state the record is in, and who owns the next step. Ambiguous handoffs are where manual "just this once" work sneaks back in and quietly undoes the automation.
4. Separate rules from exceptions
A well-defined process has a clear happy path and a small, named set of exceptions. Write down the rule that covers 80–90% of cases first. Then list the exceptions and decide — explicitly — whether each one should be automated, routed to a human, or eliminated. Trying to automate every edge case at once is how projects stall.
5. Score processes for ROI
Not every defined process is worth automating. Score each candidate on:
- Frequency — how often does it run?
- Time cost — minutes per run, times frequency, is your annual hours saved.
- Error cost — what breaks when it's done wrong?
- Stability — is the process likely to change in the next 6 months?
High-frequency, stable, painful processes are where automation pays for itself fastest. Volatile or rarely-run processes are usually better left as documented checklists until they settle.
6. Write the spec before the workflow
The final artifact of process definition isn't a diagram — it's a spec another person could build from without asking questions. It names the trigger, the inputs, the systems involved, the decisions and their rules, the outputs, and the failure modes. Once that spec exists, choosing a tool and building the automation becomes the easy part.
From definition to architecture
Defining processes well is where automation projects succeed or fail. It's also the bridge between listening to how your team works and architecting the systems that let them work bigger. If you'd like a second set of eyes on the processes you're considering automating, an Automation Audit is where we start.