Is it worth automating at all

The arithmetic that gets skipped. Automation has a build cost and a maintenance cost, and a surprising number of workflows never repay either, because they were built against a job that happens less often than it felt like it did.

The three numbers

1. 01The time the task takes now, times how often it happens, over a year. This is what you are buying back.
2. 02The time to build it, honestly, including the two evenings it will actually take rather than the twenty minutes the demonstration suggested.
3. 03The time to maintain it. This is the number everybody omits, and over a year it is frequently larger than the build.

If the first number is not comfortably larger than the second and third together, do not build it. And comfortably means by a multiple, not by a margin, because the build estimate is always low and the maintenance estimate always lower.

Why maintenance is the real cost

A workflow sits between tools you do not control. Each of them changes: an interface is redesigned, an authorisation expires, a field is renamed, a pricing tier moves a feature you depended on. Nothing warns you, and the failure is usually silent.

So every workflow is a small ongoing commitment, not a finished object. Ten of them is a system somebody has to look after, and in a small business that somebody is you, in addition to the work.

The cases that are clearly worth it

• Daily or several times a day, identical, and currently done by hand. Repays in weeks.
• Something you forget, where the forgetting costs money: a renewal, a follow-up, a filing deadline.
• Copying between two systems that will both still exist next year.
• Anything where the manual version introduces errors you then have to find, because the error hunt usually costs more than the task.

And the cases that are not

• Monthly or less, unless it is both long and reliably identical.
• Anything whose rules you are still arguing about. Automating an undecided process makes the indecision permanent.
• Anything a person does in four seconds. The workflow will take longer to debug once than the task will take for a year.
• A process you are about to change. Build it after, not before.

The value that is not time

The three numbers measure hours, and hours are not always the point. Some workflows are worth building even when the arithmetic is marginal.

• It stops happening late. Anything that depends on you remembering is unreliable, and automation makes the timing certain rather than merely faster.
• It stops being wrong. A rule applied by a machine is consistent, and the hunt for a transcription error costs far more than the transcription.
• The customer waits less. An acknowledgement that arrives in a second rather than a day changes the experience, which is worth more than the minute it saved you.
• It survives you being unavailable. A process that only works when one person is at a desk is a constraint on holidays, illness and growth.

Knowing when to stop maintaining one

Workflows are easier to build than to retire, so they accumulate. A useful rule: when something breaks, do not fix it reflexively. Ask first whether you would build it today.

Often the answer is no. The process changed, the tool at one end was replaced, the volume dropped, or it was producing something nobody uses. The breakage is the prompt to notice, and the cheapest response is deletion rather than repair. A business that only ever adds workflows ends up maintaining a museum.

Build it badly first

The cheap version is usually enough to test the idea: a scheduled reminder instead of a system, a spreadsheet instead of a database, a saved search instead of a notification. If the rough version turns out to be useful, you have learned what the proper one should do; if it does not, you have spent an hour rather than a weekend. Most workflows that get abandoned were built properly before anybody knew whether they were wanted.