The payback arithmetic

The arithmetic is not hard and almost nobody does it. That is the entire reason so much automation spending produces nothing: the decision was made on a demo rather than on a payback period.

Four numbers

For one task you need:

Volume — repetitions per month.
Time each — including the interruption it causes, not just the keystrokes.
Build cost — hours to make it work, at what those hours are worth, plus anything you buy.
Running cost — per month, forever: inference, hosting, and the human who checks it.

That fourth one is where honest models diverge from vendor ones. Almost nothing here runs unsupervised, and the supervision is a permanent line item rather than a transition cost.

A worked payback

A small firm's invoice-entry task. Real shape, round numbers.

Run it on your own top task

Take the largest task from your decomposition and get all four numbers. Where you cannot measure, estimate — but write the estimate down as an estimate, so you know later which parts of your answer were load-bearing guesses.

Be honest about the running cost. If a human has to look at every output, say so; that is not a failure of the exercise, it is the finding.

Your payback period

Build cost divided by net monthly saving, in months. If the net saving is zero or negative, record 0 and note why — that is a real and common answer.

The volume that makes it worthwhile

Now solve backwards. Holding everything else fixed, how many repetitions a month would this task need for payback inside a year? That is your volume threshold, and it is the number to check any future pitch against.

The vendor's version

A vendor quotes a 3-month payback on the same task. Their figure assumes no exception handling and values your time at your billing rate rather than your cost.