Automation Does Not Fix a Decision You Never Made

People come to me wanting to automate something.

Nine times out of ten, the thing they want to automate is not a task. It is a decision they have been avoiding.

And a computer cannot avoid a decision on your behalf. It can only make the same wrong one faster, forever, at three in the morning, while you sleep.

What automation actually is

Automation is not intelligence. It is repetition.

You are taking a decision you already made and telling a machine to make it again every time the same conditions show up.

That means the quality of the automation is capped by the quality of the decision underneath it. There is no software on earth that improves a rule you never wrote down.

The test I run before I automate anything

Before I wire up a single step, I make myself finish this sentence out loud:

"When ______ happens, we always do ______, unless ______."

Three blanks. Trigger, action, exception.

If I cannot fill all three without hedging, the process is not ready to be automated. It is ready to be written down.

That sounds slow. It is the opposite of slow. Every hour I have ever lost to a broken automation traces back to a blank I could not fill and automated anyway.

What it looks like when you skip it

A lead comes in at 9pm. Your automation sends a text.

Great. Except nobody decided what happens when the same person fills the form twice. So they get two texts. Nobody decided what happens when the phone number is a landline. So the text fails silently and the lead sits there. Nobody decided who owns it if you are on a job site. So nobody owns it.

None of those are software problems. Every one of them is an unmade decision that got a wire run to it.

The software did exactly what you told it. You just never told it much.

The order that actually works

Here is the sequence I use, and I use it on my own stuff before I ever hand it to a client.

One. Do it by hand, badly, ten times. You cannot see the exceptions from a whiteboard. You see them by doing the work and getting surprised.

Two. Write the rule down. Trigger, action, exception. A paragraph is fine. It has to be a document somebody else could follow without calling you.

Three. Find the ugly cases. What happens on a duplicate. What happens on a bad input. What happens when it is a holiday. What happens when the person replies "stop."

Four. Then build it. And build it so it tells you when it skipped something, instead of going quiet.

Five. Read the log. Not the dashboard. The log. Dashboards are built to make you feel good. Logs are built to tell you what happened.

Why this is an ownership issue, not a tech issue

Here is the part nobody tells you.

When you buy somebody else's automation, you are also buying somebody else's decisions. Their rules. Their exceptions. Their idea of what a lead is worth and how fast it should be answered.

You inherit all of it, and you usually cannot see it. It is baked into a product built for the average of ten thousand businesses that are not yours.

That is fine at the start. Everybody starts renting. But the day your business gets specific, and it will, those borrowed decisions start costing you and you will not be able to find them to change them.

Written rules are portable. Rented rules are not.

If you ever move platforms, and you will, the document walks with you. The wiring does not.

That is the whole argument for owning your systems. Not that the software is better. It is that the decisions stay yours and stay visible.

The bottom line

Automation is a multiplier. It multiplies whatever you point it at.

Point it at a decision you thought through and it pays you every day without asking for anything.

Point it at a blank and it multiplies the blank.

Write the rule. Then build the machine.

That order is not a preference. It is the whole job.

---

Share it. Send receipts. Put eyes on the record. Do not threaten, harass, or contact anyone in my name.