- List tasks by watching the work, not by asking managers from memory.
- Score each one on hours, how often it happens, the cost of mistakes and how clear the rules are.
- Start with frequent work where a mistake is easy to catch.
- Fix a broken process before you automate it.
- Plan for exceptions from the first day. They usually take most of the effort.
Make the list from the real work
Ask a manager what takes time and you'll get one answer. Sit with the person doing the job and you'll get another. Follow one real order, request or case from start to finish, and write down each step, who does it and which tool they use.
Look especially for moments when someone copies from one screen to another, checks one document against another, or waits on someone else.
Score each task
Give each task a rough score from 1 to 5 on the following. Rough is fine, since the goal is to compare options, not to be precise.
- Hours: how much total time it takes each month?
- Frequency: does it happen daily or quarterly? Frequent work pays back sooner and gives you more to learn from.
- Clear rules: could you write down how to do it for a new hire?
- Easy to check: if the software gets it wrong, would someone notice before it causes harm?
- Cost of waiting: does this delay revenue, customers or other teams?
Add up the scores and look at the top three. Then use judgment, because the highest score isn't always the right choice.
Do the math in hours
Here is a made-up example. Two people spend 15 minutes on each of 40 orders a day. That's 10 hours a day, or about 200 hours a month. If automation handles three out of four orders and people still review the rest, you might get back around 150 hours a month, minus time spent checking.
Multiply your own hours by your loaded labor cost, then compare it with the cost of building and running the system. Be conservative, and count only time you'd really use for something else.
What most guides miss
The exceptions are the project. The normal case might be easy, while the unusual 10% takes most of the work. Before you commit, collect real examples of the strange cases, because they tell you how hard the job really is.
Next, don't automate a mess. If a step exists only because of an old rule, remove it. Sometimes the best first project is deleting work, which costs nothing.
Finally, talk to the people who do the job. They know where things break, and they decide whether the new system gets used. If they think it's meant to replace them, they have little reason to help it succeed.
Good first projects
- Reading orders or requests from email and entering them for review.
- Sending reminders for missing documents.
- Building a report that someone assembles by hand each week.
- Routing approvals to the right person and following up.
Poor first projects tend to be rare, high-stakes decisions with unclear rules, such as big pricing calls or anything where a quiet mistake would be expensive.
How we do it
Our process audit does this with your team: follow the work, size each opportunity and leave you with a ranked plan that's yours to keep. See process automation for the kinds of things we build next.
