Audit the process before you automate it
Hours × error risk decides what gets automated first. The impressive task is almost never the right one.
Every automation request I get starts with the most visible task. The weekly management report. The dashboard the owner wants on the wall. It is rarely the right place to start.
The scoring rule
Before I write a line of code I sit with the person who does the work and fill in two columns for each task:
| Task | Hours per month | What breaks when it is wrong |
|---|---|---|
| Re-typing portal grids into Excel | 24 | Gross profit per vehicle is wrong, nobody notices for a month |
| Chasing guards for shift confirmation | 10 | A site goes uncovered |
| Building the weekly dashboard | 3 | Management is annoyed |
Hours × error risk. The dashboard scores lowest and it is the thing everyone asked for. The portal re-typing scores highest and nobody mentioned it, because it has been done by hand for so long that it stopped looking like a problem.
What "watch first" actually means
I stand next to the person for a full cycle of the task. Not a walkthrough, the real thing, with the real data. Three things always come out of it:
- Half the steps in the written procedure are skipped.
- There is an unwritten step that fixes a known data problem ("I always delete the rows with 'TEST' in the client name").
- The output goes somewhere nobody told me about, usually a second spreadsheet that someone else depends on.
Miss any of those and the automation ships, runs for a week, and quietly gets abandoned while the old spreadsheet comes back.
The scoring sheet, in full
The table above is the short version. The sheet I actually fill in has six columns, and the last two are the ones people skip:
| Column | What goes in it |
|---|---|
| Task | One line, in the words of the person who does it |
| Who | The actual person, not the department |
| Hours per month | Counted from one real cycle, then multiplied. Never estimated by the manager |
| What breaks | The concrete consequence of a wrong result, and how long until someone notices |
| Inputs | Where the data comes from: a portal, a WhatsApp photo, a phone call, memory |
| Outputs | Where the result goes, including the second spreadsheet nobody mentioned |
The "Inputs" column is where automation projects quietly die. A task that starts from a phone call cannot be automated until the call becomes a form. A task that starts from a WhatsApp photo of a closing sheet needs a cashier app before it needs a dashboard. Writing the input down forces the real first step into the open.
Three real rows
From the fleet accounting work: re-typing portal grids scored 24 hours a month, with a wrong gross profit per vehicle that nobody caught for a month. It was first on the list and nobody had asked for it.
From the security workforce system: chasing guards for shift confirmation scored 10 hours a month. The consequence column said "a site goes uncovered", which is a contract breach, not an inconvenience. That row is why the guard app got a confirmation flow before it got anything pretty.
From the fleet dashboard: the weekly management dashboard scored 3 hours a month and "management is annoyed". It was built last, in a week, once the data it needed already existed because of the first two rows.
Say no to some of it
Some tasks score low on both columns. Automating them costs more than they will ever save. I tell the client that in writing, with the numbers, before the project starts. It is the cheapest decision in the whole engagement, and it is the one that makes them trust the rest of the list.