Every automation project starts with someone saying "we should automate this." Usually they are pointing at the thing that annoys them most. That is rarely the thing worth doing first.
The annoying process and the expensive process are different processes. The one that gets talked about in meetings is the one with a visible villain — the spreadsheet everyone hates, the report nobody wants to write. The one quietly costing the most is usually invisible, because the people absorbing it stopped mentioning it years ago.
The four traits
Before we scope anything we look for four things. A process that has all four is a good first build. A process missing two of them is a good second or third build, once the team has seen one work.
It runs often. Not "it is important" — often. A quarterly process that takes a full day is eight days a year. A daily process that takes twenty minutes is about the same, but you find out within a week whether the automation actually holds, instead of finding out next quarter. Frequency is what turns a build into feedback.
The rules are already written down somewhere. Not necessarily in a document. In a checklist, an email template, a set of filters someone made in their inbox, the conditional formatting on a spreadsheet. If a person can explain the rule in two sentences without saying "it depends," the rule is real. If every example comes with an exception, you are looking at judgement wearing a process costume, and judgement does not automate — it gets assisted, which is a different build with a different budget.
The inputs arrive in a fixed shape. An invoice that always comes as a PDF from the same six suppliers is tractable. An invoice that arrives as a PDF, a photo of a printout, or a line in the body of an email is three problems, and the third one is the one that will eat the timeline. This is the trait people most often wave away during scoping and most often get caught by during build.
Somebody would notice tomorrow if it stopped. This is the one that gets skipped, and it is the one that decides whether the project survives. If a process can silently stop for a fortnight before anyone asks, it has no owner. An automation without an owner does not get maintained, does not get fixed when an API changes underneath it, and quietly becomes a liability wearing the shape of an asset.
The question we actually ask
Not "what takes the longest." That question gets you a wish list.
We ask: what does this team redo?
Rework is the honest signal. Time spent doing something once is work. Time spent doing it a second time because the first version went to the wrong person, or was missing a field, or crossed with someone else doing the same thing, is the process failing. Rework is measurable without a stopwatch, because people remember it — it is the part of the job they complain about by name.
Almost every automation worth building either removes a handoff or removes a lookup. Handoffs are where work waits. Lookups are where people go and find the thing they need in another system, then type it into this one. Both are cheap to find if you ask people to narrate a day rather than describe their role.
What we do not start with
The full department. A first build that touches four systems and three teams does not fail because it was technically hard. It fails because nobody can tell which of the twelve assumptions in it was the wrong one. Start with something whose failure is legible.
Anything where the current process is genuinely unclear. If two people describe the same process differently, that disagreement is the deliverable. Automating it just picks one of them as the winner without saying so, and the other person's exceptions start arriving as bug reports six weeks later.
A process that is about to change anyway. If the team is mid-migration, or the vendor is being replaced next quarter, building against today's shape is buying a rebuild.
What this looks like in practice
We start with a scoping pass that produces a written description of the process as it currently runs — not as anyone believes it runs. That document is the actual first deliverable, and it is useful even if nothing gets built, because it is the first time the process exists in one place.
Then one process. Built, watched for a fortnight, adjusted.
Then the next one, which is nearly always easier, because the first one settled half the arguments about how the data is shaped.
Our capability library is mostly systems that started this way — one narrow process that ran often, with rules somebody had already written down. The larger platforms in there grew out of those, rather than being designed whole.
If you want a second opinion on which process to start with, describe the one that annoys you most. We will usually tell you it is the wrong place to start, and why — and that conversation is generally more useful than the build you thought you were asking for.