Most teams pick the wrong process to automate first. They either try to automate everything at once, which stalls, or they reach for the part of the work that looks most impressive in a demo. Neither approach starts from the question that matters: of all the manual work your team does, which single process is worth turning into software before any other?
This is a piece about how to answer that question. It is not a pitch. It is the way I look at a team's work before I build anything.
Start with the work, not the tools
Before you compare software, spend a week watching how the work actually happens. Not how the process is written down, how it happens. Who touches each task, how often, and what breaks when someone is out sick or in a hurry. Most good candidates for automation are hiding in plain sight, in the tasks people do so often that they have stopped noticing them.
Once you can see the work, rank each repetitive process against three questions.
Three questions that rank a process
How often does it repeat? A task that happens many times a day deserves more attention than one that happens once a quarter. Frequency is where automation pays back, because you are removing the same manual step again and again.
How much does a mistake cost? Some manual work is forgiving. A typo gets caught and fixed with no harm done. Other work is not. An error in the wrong place quietly costs money or trust, and nobody notices until later. The higher the cost of a mistake, the more a reliable system is worth.
How clear are the rules? Automation is good at work that follows rules a person can write down. It struggles with judgment calls that change every time. If you can explain the steps to a new hire in a short list, a system can probably follow them too.
The process that scores high on all three, frequent, costly when wrong, and rule based, is usually the one to start with.
Two ordinary examples
Take a distributor that reconciles stock by hand. Every day, someone compares what the system says is on the shelf against what is actually there, keys the differences into a spreadsheet, and chases down the gaps. It happens daily, so it is frequent. A wrong number leads to a stockout or a pile of dead inventory, so a mistake is costly. And the steps are the same every time, so the rules are clear. This is a strong first candidate. It scores high on all three questions, and the team feels the pain of it every day.
Now take a small English center that tracks student progress in spreadsheets. A teacher updates a sheet after each class, someone copies the numbers into a report for parents, and by the end of the term the sheets no longer agree. It is frequent, and mistakes cost trust with parents, so far it looks similar. But look at the rules. Deciding what counts as progress, and how to talk about a student who is behind, involves judgment. The part worth automating first is not the judgment. It is the copying and the reporting, the mechanical work around the edges that eats a teacher's evening. Narrow the process down to that, and it becomes a good first project.
What to avoid
Do not automate a process that is broken. If the manual steps are wrong, a system will just do the wrong thing faster. Fix the process on paper first, then build.
Do not start with something rare. A quarterly task might annoy you, but automating it returns little, and you learn less from it. Save it for later.
And do not try to automate the whole operation in one go. The point of choosing a first process is to ship something real, watch it work, and earn the confidence to do the next one. A single automated process that a team trusts is worth more than a grand plan that never leaves the slide deck.
The first one teaches you the rest
The reason to choose carefully is not only the payback from that one process. It is what the work teaches you. The first system shows you where your data is messy, where the real edge cases live, and how your team actually adopts a new tool. Those lessons make every process after it easier.
So the honest answer to which process to automate first is the one that is frequent, costly when wrong, and rule based, and that your team already wishes they did not have to do by hand. Start there.
If you would like a second pair of eyes on which process that is for your team, that is the kind of thing I help with on the services page.