When does an automation project actually finish?
The accountant stopped asking where the data comes from.
Not because someone told her to stop. Not because she was trained out of curiosity. She stopped because the question became pointless — the same way nobody asks where the electricity comes from when they flip a switch.
Every morning at 9:00 the data shows up. Clean, on time, in the right place.
That moment — quiet, unremarkable, easy to miss — is when an automation project actually finishes.
What "done" usually looks like vs. what it actually means
Most teams call a project done when it works. The workflow runs, the output is correct, someone on the team knows how to trigger it. That's functional. That's a real milestone.
But functional isn't the same as finished.
A project that runs when someone remembers to run it is still a project. It still lives on someone's to-do list. It still costs attention — the low-grade, recurring kind that adds up over weeks. Someone has to remember it exists. Someone has to notice when it doesn't fire. Someone has to maintain the habit of using it.
That's a solution dressed up as a project. The automation is real, but it hasn't crossed the line yet.
The line: zero attention cost
The finish line isn't "functional." It isn't "the team runs it when they remember."
It's boring. It's invisible. It costs zero attention.
When a process reaches that state, nobody notices it running — and nobody notices it in a good way. It just works, the way background infrastructure works. You only think about electricity when it goes out. You only think about a mature automation when something breaks.
That's the goal. Not impressive. Not celebrated. Just gone from the mental overhead of everyone involved.
Why most implementations stop short
Getting to functional is hard enough. Getting to invisible is a different problem.
Functional requires building the thing correctly. Invisible requires removing every remaining reason for a human to touch it — the manual trigger, the weekly check, the "just to make sure" step that never got automated, the exception someone handles by hand because it was easier than building the edge case.
Each of those remnants keeps the project alive as a habit. And habits require maintenance. Maintenance requires attention. Attention has a cost.
Most implementations stall here — not because the core automation broke, but because the surrounding friction never got cleared. The project works, but it never disappears.
What crossing the line actually looks like
In the case this post is about: nobody ran it. Nobody requested it. The person who built it didn't notice it had crossed the line for a full week.
That's the tell. When the builder stops tracking it daily, when the user stops thinking about it, when the question of "did it run?" stops occurring to anyone — that's when it's done.
Not when you deploy it. Not when the team approves it. Not when the first automated report lands in someone's inbox and they reply "great, thanks."
When it becomes part of the background. Sometime last week, at 9 in the morning.
What this means practically
If you're running an automation project, the question to ask isn't "does it work?" Ask: who still has to think about this, and why?
Every person who still has to touch it, monitor it, or remember it is a sign the project hasn't finished. That's not a failure — it's just a remaining task. Find the friction, remove it, and keep going until nobody has to think about it anymore.
Functional is a milestone. Invisible is the finish line.