Articles / If You Cannot Define Done, Do Not Automate Yet

sr-leaf Article

If You Cannot Define Done, Do Not Automate Yet

Most automations fail before code because nobody can say what done means. Here is a simple test you can run in 60 seconds.

Back to articles

In one line

Make the outcome visible

Read time

2 min

Focus

Operations & Process

Automation

Quick test: if I asked three people on your team, "What does done mean?" would I get the same answer three times?

If not, do not automate yet. That may sound a bit harsh. It is still cheaper than building the wrong thing.

Most automation projects do not fail because the tool is bad. They fail because the goal is fuzzy. Once the goal is fuzzy, the build turns into guesswork with a login.

The trap that gets teams stuck

A team says, "We should automate onboarding." Or, "We should automate invoicing."

Maybe. But that is not a plan.

Here is what usually happens next. One person thinks done means the email went out. Another thinks it means the folder got created. Someone else thinks done means the kickoff is booked. The automation goes live, and everyone is quietly disappointed for different reasons.

A real example

Say you want to automate onboarding. You build a Zap that sends a welcome email after payment. Great.

But the client still has no folder. Nobody set up access. The kickoff call is not booked. So yes, one step got faster. The overall experience is still messy.

That is why done matters. You need to name the finish line before you build the road to it. Boring advice, maybe. Still solid.

What "done" really is

Done is something you can point to. It is not a vibe.

Examples:

  • the invoice is sent
  • the client folder exists
  • the order is packed
  • the follow-up email went out

If you cannot name the thing, the automation will have holes. Someone will always be guessing, patching, or asking for confirmation after the fact.

The 60 second note

Before you build anything, write one note with four lines:

  1. Trigger: when does the work start?
  2. Output: what exists when it is done?
  3. Owner: who is responsible for done?
  4. Time promise: by when?

If you get stuck on any of those lines, that is the work. Fix the definition first. Then build.

Try this today

Pick one workflow that keeps annoying you and write the finish line in one sentence. Then ask one question: What would I need to see to believe this is done?

Why this matters

Automation makes things faster. If your workflow is unclear, it just makes the chaos faster. That is why clarity comes first and automation comes second.

If you want help with this, book a discovery call.

What is one workflow in your business that feels stuck right now?

sr-leaf Next step

If this article feels familiar, the workflow probably needs a better first move

If you want help figuring out where to start, a Discovery Call is usually the fastest way to get clear.

Newsletter

Get practical ops insights once a week

No spam. Unsubscribe anytime.

Keep reading