Should I Automate This?

What this tool does

CM8-333 puts a number on the repetitive work your organisation does by hand, and then tests whether automating it actually pays. For every task you get the hours a year, what those hours cost, how much automation would realistically remove, what it would cost to build and keep working, the payback in months and the net position over the automation's expected life.

It exists because the two questions people actually argue about — "how much time does this waste?" and "is it worth fixing?" — are usually answered with anecdotes on one side and enthusiasm on the other. Both are arithmetic, and the arithmetic is not hard. It is just never done.

Everything runs inside this single file: no account, no upload, no network request of any kind, so salary rates and candid assessments of how your organisation actually works stay on your computer.

Three questions that come before automating

Automation is the third-best answer to repetitive work, and the tool would be dishonest not to say so.

• Can it be eliminated? A surprising share of routine work exists because somebody asked for it once, years ago, and nobody has asked since whether the output is still read. Automating an unnecessary report makes it permanent and removes the annoyance that would eventually have killed it.
• Can it be simplified? Most tasks that look like automation candidates are complicated by a decision made upstream — a format, an approval step, a system that will not talk to another. Removing that is usually cheaper than building a bridge over it, and it fixes the cause.
• Can it be done less often? A daily report that nobody reads until Friday is a weekly report. That change costs nothing and takes four-fifths of the effort out.

Where none of those apply, automation is exactly the right answer, and this tool tells you how right.

Measuring the task honestly

The single number that decides everything here is minutes per occurrence, and it is almost always understated. When somebody says a task takes ten minutes they usually mean the keystrokes take ten minutes on a day when nothing goes wrong. What it actually costs includes finding the file, waiting for the system, the interruption to whatever they were doing before, the checking afterwards, and the twice-a-month occasion when it fails and has to be redone.

Measure it if you can — watch it happen three times and take the middle figure. If you cannot, take the number you were given and add half. Both are better than the first answer.

The people column is for genuine simultaneous effort only. Where something passes through three pairs of hands in sequence, that is one occurrence with the total minutes, not three people.

The share automation removes

Almost nothing goes to zero. Somebody still handles the exceptions, checks the output looks sane, deals with the days the source system is down, and answers the questions when the format changes. Eighty per cent is a good default for a clean, well-defined task; sixty is realistic where the inputs are messy or arrive in several formats; above ninety should be reserved for cases where you can describe exactly who does the remaining tenth and when.

The stacked chart on the reports tab shows released against retained hours for exactly this reason. A task claiming to release ninety-five per cent of a messy, human-judgement process is not an opportunity — it is an estimate nobody has challenged.

Hours released against money saved

This is where most automation business cases quietly fall apart, so the tool separates the two.

Hours released is a real, defensible number: the work will genuinely stop being done. Money saved is a different claim, and it is only true if a cost actually leaves the business. Saving twenty minutes a day across six people does not reduce the payroll by a penny — those people are salaried and will be paid the same on Friday. It releases capacity, which is valuable if something is done with it, and worth nothing at all if it is absorbed.

The share of freed time that becomes real money setting is how you say which you have. Set it to 100% only where a specific cost will genuinely go — a vacancy left unfilled, agency cover stopped, overtime removed, a contract not renewed. Set it to 0% to price the whole exercise in hours and argue the case on capacity rather than cash, which is often the more honest argument. The default of 50% is a compromise, and like all compromises it is wrong in both directions; change it to match what you can actually commit to.

Build cost, and the part everyone forgets

Build cost here is hours times the build rate, plus any one-off spend. The hours must cover the specification, the building, the testing, the rollout and the retraining — not just the coding, which is usually the smallest part.

Maintenance is charged every year, as a percentage of the build cost, and it defaults to 18%. This is the line that homemade business cases omit, and its absence is why so many automations look brilliant in year one and are quietly abandoned in year three. Automations break when the things at either end of them change: a report layout, a login policy, a file name, an interface version, a supplier's portal. Something has to be paid to keep them alive, and if nothing is, they die.

Any subscription, per-transaction or hosting charge goes in running cost a year and is taken off the saving in full.

How the verdict is decided

The verdict is a plain reading of the payback against the expected life:

• Automate — pays back within twelve months.
• Worth doing — pays back within half the automation's expected life.
• Marginal — pays back before the end of its life, but not comfortably. These need a reason beyond the arithmetic: risk reduction, speed, a bottleneck cleared.
• Do not automate — never pays back, or the net saving is negative once maintenance and running costs are counted.
• Too small — leave it — under twelve hours a year. Even a perfect automation of a task this size cannot repay the meeting you would hold about it.

Benefits this tool does not count

Several real benefits have no place in this arithmetic, and pretending otherwise would make the numbers worse rather than better. Note them beside the row and argue them separately:

• Speed. A requisition that took three days and now takes an hour may be worth far more than the eight minutes of keying it saved.
• Errors avoided. Re-keying has an error rate; automation usually has a different and smaller one. If you know what mistakes cost you, that is a genuine and separate saving.
• Recovery. Reconciliation that finds overcharges pays for itself in a way that has nothing to do with the hours spent.
• Risk and compliance. A control that runs every time beats one that runs when somebody remembers.
• The work nobody wants. Dull, repetitive tasks damage retention, and retention is expensive. It is real, and it is not measurable here.

The formulas

No discounting is applied. Over the three-to-five-year horizons this tool is built for, discounting moves the answer by less than the error in the minutes-per-occurrence figure, and adding it would give the result a false air of precision. If your finance function requires a discounted case, take the net saving a year from here and do that separately.

FAQ

Why is the payback blank on a row? Either there is no build cost entered, or the net saving is zero or negative — in which case there is no payback, not a very long one.

The verdict says do not automate but I am sure it is worth it. Then the case rests on something this tool cannot see — speed, errors, risk, or morale. Write that in the notes and make that argument explicitly. A case that has to be made on grounds the numbers do not support is not necessarily wrong; it is just not a financial case, and calling it one is how credibility is lost.

What if the same task is done by five people? Enter it once with the combined frequency — five people doing it weekly is "every week, times 5" — or as five rows if the durations genuinely differ.

Should I include my own time building it? Yes, at the build rate. Work done "for free" by somebody in among their real job is the most expensive kind, because it displaces whatever they were meant to be doing and nobody ever measures that.

Everything is coming out as “do not automate”. Check the cashable share first — at a low setting almost nothing pays back in cash, which may well be the honest answer. Then check the maintenance percentage and the expected life. If the case only works when all three assumptions are generous, you have learnt something useful.

Saving your work

Tasks, settings and the report header are written to this browser's local storage as you type. That storage belongs to one browser on one computer: another browser, a private window or a clean-up tool that clears site data will not have it.

Treat Export .json as the real save — one file containing everything, which Import .json restores anywhere. Export CSV gives you the business case for spreadsheet work. Reset asks twice, then erases everything this tool has stored. There is no undo.

Accuracy & disclaimer

Two inputs here are estimates dressed as arithmetic, and both flatter automation. Task durations given from memory describe a good day. Build estimates are systematically optimistic — and the figure that decides whether an automation survives is not the build but the years of maintenance after it.

Against that, the saving side is deliberately discounted: freed time becomes money only when a cost actually leaves the business. Treat a payback under a year as worth pursuing, a payback near the expected life as a coin toss, and any case that depends on the maintenance percentage being low as not yet made. Nothing here is a budget approval or a commitment to spend.