What to automate first, and what never to automate

The problem it solves

A company's first automation is almost never chosen. It is inherited from whichever task annoys someone the most. Somebody says in a meeting that reconciling the Friday reports is unbearable, the room agrees, and that becomes the project. Nobody asked how often it happens or how many hours a year it actually consumes.

The task that annoys and the task that costs are rarely the same one. The annoying task is loud, visible and concentrated in one person who talks about it. The expensive one is usually spread across fifteen-minute pieces of five people's days, and none of them mentions it, because each one treats it as a minor detail of their own work.

There is a third category, and it is the costliest. It is the task that looks ideal for automation, repetitive, rule-based, daily, and that in practice rests on exceptions the person handles without noticing that handling them is the job. Automate it and the rule runs cleanly while the exception turns into an error somebody finds out about late.

What it covers

The workshop does not open with tools and does not close with a purchase recommendation. It opens with an inventory: each participant brings the real administrative and operational tasks of their company, with who does them, how often, and what happens when they go wrong.

Explicit criteria are then applied to that inventory, one at a time: frequency, volume, how stable the rules are, how many exceptions the task tolerates, how expensive an error is, and how soon the underlying process is likely to change. Each task is scored in front of the group, and that is where the most useful result of the exercise shows up: candidates that had topped the pending list for months fall to the bottom, and tasks nobody had mentioned rise.

What comes out is a ranked list with three zones: what gets automated first, what waits until the process settles, and what is ruled out on purpose. The last zone is the one most defended in the room, because writing down that something will not be automated closes an argument that otherwise returns every six months.

What participants learn

• Tell the task that irritates apart from the task that consumes time and money.
• Apply explicit criteria of frequency, volume, stability and cost of error to every candidate.
• Recognise the tasks that look automatable and in fact rest on exceptions.
• Rank a list of candidates by what each one returns, not by who asked for it.
• Defend to the leadership team why a task is being ruled out.

Agenda

1. 01The task inventory: who runs each one, how often, and what breaks when it fails
2. 02Frequency and volume: why a ten-minute daily task outweighs a four-hour monthly one
3. 03Rule stability: how often what is decided the same way today actually changes
4. 04Exceptions: the part of the job nobody describes when describing the job
5. 05The cost of an error and who discovers it
6. 06Tasks that look ideal and are not: judgement dressed up as a rule
7. 07What is better left in a person's hands, and why
8. 08Ranking the list: first, later, and ruled out in writing

What the organisation leaves with

• A written inventory of candidate tasks in your company, with an owner and a frequency.
• A ranked list, with each task's score visible against the criteria used.
• An explicit ruled-out list, with the reason written next to each task.
• A one-page selection criterion you can apply to candidates that appear later.