Your automation backlog is a list of opinions

Ask five people in a finance team which process to automate first and you will get five answers, each of them sincere and none of them measured. The one that wins is usually the one whose owner is most senior, most persistent, or most recently annoyed. That is not a backlog. It is a record of who has been in the room.

What an opinion-ranked backlog looks like

You can recognise it by the shape of the estimates. Every candidate takes "about two days a week". Every one saves "a couple of FTEs". The numbers are round, they were produced in a workshop, and nobody has been back to check them since.

The failure is not that the estimates are wrong - first estimates always are. It is that there is no mechanism by which they can be corrected, because nothing was measured in the first place.

What the event log already knows

Almost every process you would consider automating leaves a trail: ticket timestamps, ERP document dates, mailbox metadata, approval records. That trail answers questions a workshop cannot:

• Volume. How many cases actually ran last quarter, not how many people remember.
• Handling time. The distribution, not the average. A process with a two-minute median and a four-hour tail is a different automation problem from one that takes forty minutes every time.
• Rework. How often a case comes back. Rework is the most under-reported cost in every backlog we have reviewed, because the person doing it does not experience it as a separate task.
• Variants. How many distinct paths the process actually takes. Six is automatable. Two hundred means you are looking at a policy problem wearing a technology costume.

Ranking by cost, not by noise

Once you have those four numbers, the ranking writes itself: volume multiplied by handling time, weighted by rework, discounted by variant count. It takes an afternoon. The interesting part is not the top of the list - it is the middle, where three candidates everyone was sure about turn out to run eleven times a month.

The part clients dislike

A measured backlog always shortens. In our engagements roughly a third of proposed candidates come off the list, usually for one of three reasons: the volume is not there, the process changes every quarter, or the real cost is a decision a human has to own anyway.

Telling a client that before they have paid for a build is cheaper than telling them afterwards. It is also the fastest way to find out whether you are working with someone who wants automation or wants a number in a slide.

Where to start tomorrow

Pick the process your team complains about most. Before scoping anything, export ninety days of timestamps for it. If you cannot - if the trail does not exist - that is the finding, and it comes before any automation decision.