The automation backlog: how I actually prioritize what gets built next

An automation backlog accumulates ideas faster than a team can build them, and the default way most get worked is roughly first-in-first-out, whatever's been on the list longest or whoever asked most recently gets attention next. That ordering has nothing to do with which automation would actually matter most.

The prioritization I actually use scores each candidate on three things: how often the process happens, how much time or error it costs per occurrence, and how stable the process is, since a process still changing shape monthly is a worse automation candidate than one that's been stable and repetitive for a year, regardless of its raw time cost.

Applied honestly, this reorders most backlogs significantly: the flashy, frequently-requested idea often scores lower than a boring, high-frequency process nobody's been vocal about, because volume and stability compound in ways that a single person's loud request doesn't reflect.

The backlog isn't a queue to work through in arrival order, it's a list to actively re-rank against the same three questions every time capacity opens up, which is a different discipline than just picking whatever's been waiting longest or whoever asked most recently.