Isaac Correa · Madrid

Which actions can be undone

Before an action is handed to software, somebody has to be able to say how it would be taken back, and by whom. This is the list I ask a company to write, and what goes in each column.

Isaac Correa, co-founder of Hellomatik, in Madrid
Isaac Correa in Madrid. The list described here is written before any action is handed over, not after something goes wrong.

Sort the actions by how long you have to change your mind

Not by how important they are. Two actions can matter exactly the same amount to the business and still need completely different amounts of supervision, because one of them can be put back all afternoon and the other cannot be put back at all.

Some actions are undoable. A draft is saved, a status is corrected, a note is added to a record. If it is wrong, somebody sets it back and the day carries on.

Some are expensive to undo. Stock is committed, a slot in a delivery round is taken, a credit hold is lifted. It can be reversed, but reversing it costs a phone call, or somebody’s afternoon, or a customer noticing.

And some cannot be undone. A message reaches a customer, money moves, a document goes to someone outside the company. Nothing puts those back.

The third group is usually the shortest of the three, which is why writing it down is an afternoon rather than a project.

Four columns

What it touches

The record, or the thing in the world, that ends up different. If the answer is the name of a system rather than a thing, it is not specific enough yet.

How it is undone

The exact step somebody would take. The word manually is not an answer; it means nobody has checked whether the step exists.

Who can undo it

A role, or a name. It also has to be somebody who is actually there: an action whose only recovery runs through one person is a different risk in August than it is in March.

How long the window stays open

The point after which undoing it stops being free. This is the column that people skip, and it is the one that changes the character of the others.

A filled-in row looks like this

Take releasing an order that is on credit hold. What it touches: the hold flag on that order, and the picking queue it drops into. How it is undone: put the hold back. Who can undo it: whoever is covering the credit desk that day. The window: until the picking list prints, because after that the order is physically being assembled and putting the hold back means walking into the warehouse.

Four short answers, and the last one is the reason this action can be automated at all: there is a clean point where the cost changes, and it can be written down.

The rows in the third group are shorter and less comfortable. Sending a customer the confirmation that their order has shipped: what it touches: their inbox. How it is undone: it is not. Who can undo it: nobody. The window: there is none. Nothing about that row is difficult to fill in. What is difficult is deciding, once it is written down in front of you, whether anything should be allowed to send it without a person looking.

What the finished list is for

Two things. It tells you which actions can run without anybody watching, because the worst case is a correction someone can make. And for everything else, it tells you what has to be true before it runs: who approves it, and how long they have to change their mind.

That second part is why the approval belongs in the same table as the action, with the name and the window as fields — a permission rather than a screen. An approval that lives only in a screen cannot be queried afterwards. What it leaves behind is the order in which things were clicked.

If you write nothing else, write the third group: the actions nothing puts back. It is short, and it is the only one where being wrong cannot be corrected afterwards.

Read more

Four questions before automating anything — a page you can work through with your own team.
The vocabulary — action, permission, boundary and the rest, each with what it is not.
The rules your company never wrote down — what happens in the first week.
The questions people ask, answered — short answers, each with a source.
How we build a company’s ontology — the method this list belongs to, deposited with the DOI 10.5281/zenodo.22647735, where the scope of what runs on it is stated.