Don't Automate That. Delete It Instead.

You have a list of things you mean to automate one day. Look at the top item. You can describe the work in a sentence, because you have done it forty times this year. Now describe why it exists. Not what you do, but what happens first, the event that puts the work in front of you. Most of that list does not survive the question. The items that die are usually the ones you were closest to building.

WHAT WORKS

Look at the trigger, not the task.

Write the item as one sentence with the trigger in front. Every time X happens, I have to Y.

If you cannot finish that sentence, you do not understand the work well enough to automate it, and that is a useful finding for fifteen seconds of effort.

Everyone builds on Y. The whole question is X.

X takes one of five shapes, and the shape decides the verdict before you have priced a single hour of build.

• →Bad input. Somebody upstream left a field blank, sent the wrong version, or skipped a step. Y is rework. Automate Y and the wrong input gets processed faster, while the person creating it never finds out they are creating it.
• →No written rule. A decision gets made fresh every time because nobody wrote it down once. You are the rule. Write the rule down and Y stops happening.
• →A dead policy. A step that made sense for a reason that has since gone away. Nobody has questioned it because everyone assumes somebody already did.
• →No bridge. Two systems that cannot talk to each other, and you standing between them retyping. Nothing upstream fixes this.
• →Nothing fires. The work only happens if a person remembers, and some weeks that person does not. There is no upstream fix for forgetting.

Two kinds of trigger. Three of them go away when you fix what causes them. Two of them are still there after every fix, and those are the ones worth building.

The first three disappear when you remove the cause. The last two are still standing after every upstream fix you can think of, and those are the only real automation candidates on your list.

Automation makes work faster. Removing the cause is the only thing that makes work stop.

One more rule about who to ask. Put the trigger question to the person upstream, never to the person doing the task. The person doing it will tell you how to do it better, in detail, and every answer will take the trigger as given. They have spent a year inside that question. It is the one thing they cannot see around.

Run this on a list of ten and expect two to survive. That is a good afternoon, not a disappointing one. You just cancelled eight builds and kept the two that pay.

ONE PRACTICAL IMPLEMENTATION

One line per item, four fields: the trigger, the work, the shape, the verdict.

Here is a week of one, with round numbers rather than any real client's.

• →A client returns the onboarding form with fields left blank, so I read it, find the gaps and write a chase email. Shape: bad input. Verdict: fix the cause.
• →Somebody asks what my rush rate is, so I work it out again from whatever I charged last time. Shape: no written rule. Verdict: fix the cause.
• →A proposal goes out, so I copy it into the shared folder where the accountant can find it. Shape: dead policy. Verdict: ask whether the accountant has opened that folder this year.
• →An invoice gets paid, so I open the bank app and mark it off in the tracker. Shape: no bridge. Verdict: build.
• →A call ends, so I have to remember to send the summary. Shape: nothing fires. Verdict: build.

Then count. Three of five say fix the cause, which is the normal result and the reason to do the count before anything else. If more than half your list reads that way, what you have is not an automation backlog. It is a rework backlog wearing an automation costume, and building any of it welds the mistake into the process where nobody will ever look at it again.

Take the top row and follow it all the way down.

The same task priced two ways. On the left, the automation that handles it forever. On the right, the forty minutes that stop it happening.

The chase-email bot is a good build. It works, it saves the time it promised, and it is still the wrong thing, because it needs the client to keep getting it wrong in order to have a job. Four required fields and one filled-in example cost forty minutes and there is nothing left to chase.

Notice which of the two you would rather show somebody.

WHAT DOESN'T WORK

• →Starting from the tool. Asking what your automation tool can do gives you a list of work shaped like the tool, and none of it is shaped like your business.
• →Automating rework. If the input is wrong three times in ten, you now handle the wrong input three times in ten, faster, and with better hiding.
• →Asking the person who does the task whether it should exist. You will get a very good answer to a different question.
• →Calling something automated the day it runs. It is automated when somebody other than you would notice it had stopped.
• →Deleting a step without telling whoever is downstream of it. A dead policy is often load-bearing one desk over, and you find out in the worst week of the quarter.

ONE THING TO DO THIS WEEK

Take the top three items off your automate-someday list. Fifteen minutes, no tooling.

• →Write each one as: every time ___ happens, I have to ___.
• →For each, name what would have to change upstream for that trigger to stop firing.
• →Mark the row: fix the cause, or build it.
• →Build nothing this week. The marked list is the deliverable.

---

The test rejects more than it approves, and that is what it is for. What survives is a much shorter list, and a short list is the only kind anybody finishes. Alacrio sits on mine for the last shape, the work that happens only if somebody remembers, because that is the one no amount of fixing upstream ever removes.

If you have a list of automations you keep not building, book a free consultation and we can work out which two of them are real.