Nobody is watching your automation (and that is the problem)
Most conversations about automation are about the build. Which tools, how they connect, what the workflow does. That is the exciting part, and it is the part people pay attention to. It is also, at most, half the job. The other half is the part nobody sells you, and it is the half that decides whether your automation is still doing its job in six months or quietly doing nothing.
Automations do not fail loudly
Here is the thing that makes automation different from a person doing the same task. When a person drops a ball, they usually know. They notice the mistake, or they feel that something is off, and they say something. An automation has no such instinct. When it breaks, it does not raise its hand. It just stops doing the thing, or starts doing it wrong, and carries on looking exactly as calm as it did the day before.
And it will break, not because it was built badly, but because the world around it moves. An app pushes an update and changes where a button lives. A login expires and is never renewed. A form gets a new field, and the workflow that fed the old form quietly sends nothing. None of these are dramatic. None of them set off an alarm. The workflow does not fail so much as rot, slowly, in a way you cannot see from the outside.
So how do you find out? Usually the worst possible way: weeks later, from a client. The reminder that stopped going out. The report that has been wrong since April. The document that was never filed. By the time a human notices, the automation has been failing silently for a long time, and the bill for that silence lands all at once.
The build is half the job
If the build is half the job, what is the other half? Operating it. And operating a workflow is not glamorous, which is exactly why it gets left out of the pitch.
Operating means a few specific things. It means monitoring, so that when something stops, someone knows in hours, not weeks. It means reviewing the AI outputs before they reach a client, because an assistant that drafts replies or sorts documents will occasionally get one wrong, and the difference between a useful tool and an embarrassment is whether a person checks the work first. It means small improvements, because the first version is never quite right and the needs shift as the firm grows. And it means a short, honest note each month about what the system actually did: how many things it handled, where it stumbled, what got fixed. Not a dashboard nobody opens. A plain account of whether the thing is earning its place.
None of that is exciting. All of it is the difference between a workflow you can trust and one you are quietly gambling on.
"Set and forget" is the biggest lie in automation
You will see "set and forget" everywhere. It is the most appealing phrase in this whole field and the least true. It tells you the tempting thing, which is that you can hand over a job and never think about it again. What actually happens when you set and forget is that you set, and then you forget, and the system rots in the corner while you assume it is fine because it made no noise. The absence of noise is not the same as the presence of working.
Anything connected to the outside world, to other apps, to logins, to the internet, needs tending. That is not a flaw in the build. It is the nature of software that depends on things it does not control. A workflow is a garden, not a statue. Leave a statue alone and it is fine. Leave a garden alone and it goes to weeds.
What watching looks like in practice
For a small firm this does not need a team or a fancy tool. It needs four modest things.
A named owner. One person, by name, whose job it is to care that the workflow is alive. Not a committee, not "the office". A person. Error alerts that go somewhere a human reads. It is not enough for the system to detect a problem; the alert has to land in an inbox or a channel a real person actually looks at, or it is just a message shouted into an empty room. A review queue for anything with stakes, so AI outputs and important actions get a human glance before they reach a client. And a monthly check: ten minutes to look at whether it is still doing the job, and to feed back anything that has drifted.
That is it. Modest, unglamorous, and the whole difference between an automation that helps for years and one that fails you at the worst moment.
The question to ask
So here is the question to put to any provider selling you an automation, or to your own team if you are building it in house. Ask them: "Who will notice when this breaks, and how fast?"
Listen carefully to the answer. If it is a confident, specific "this person, through this alert, within this long", good. That is someone who understands that the build is the start, not the finish. If the answer is vague, or if it leans on the words "set and forget", you have learned something important before you have spent a dollar.
And let me be honest about my own view, because it points the other way from what most people selling automation want you to hear. If nobody can own the watching, build less. A smaller automation that someone actually keeps an eye on beats an ambitious one that nobody is minding. Automate the piece you can operate, leave the rest by hand for now, or pay someone to own the watching properly. What you should not do is build something clever, walk away, and call the silence success. The silence is the problem.