The Automations You Already Run, and the Ones Nobody Owns

Before you build another automation, count the ones you already have. Not the ones on the roadmap. The ones running right now, in your automation platform, in the workflow tab of your CRM, in the rules somebody set up in the shared inbox two years ago.

Nearly every company of ten to fifty people has more of these than anyone believes, and the interesting finding is never the total.

The three categories you will find

Running and understood. Somebody owns it, they could describe what it does, and if it broke they would notice within a day. These are fine. They are also, in most companies, a minority.

Running and unexamined. It works, so nobody has looked at it since the week it was built. Frequently it was built by somebody who has since changed role or left. It might be doing exactly what it did on day one while the process around it has moved, which means it is now solving a problem that no longer exists, or solving it in a way that creates a small amount of cleanup for somebody else every single day.

Running and unowned. Nobody in the building would put their name against it. This is the category that surprises people, and it is usually the largest.

Why unowned is worse than broken

A broken automation announces itself. Somebody complains, someone fixes it, life continues.

An unowned one that works is silent, and the silence is the problem. When it eventually fails, the first twenty minutes go on discovering that it exists, the next twenty on establishing what it was supposed to do, and the rest on somebody guessing. If it touches customers, those minutes are the expensive kind.

There is a second cost that is harder to see. Unowned automations quietly constrain change. Nobody wants to alter the process it sits in, because nobody knows what will break, so a workaround gets built around the automation, and now there are two things nobody wants to touch.

How to do the count without it becoming a project

Give it two hours and a spreadsheet. Go platform by platform rather than department by department, because platforms have lists and departments have memories.

Your automation platform, your CRM's workflow or rules section, your helpdesk's triggers, your email's server-side rules, your accounting tool's scheduled actions, and any scripts running on a schedule somewhere. That covers most of it. For each one, note what it does, what systems it touches, when it last ran, and who owns it, leaving the owner blank when the honest answer is nobody.

Then sort by the blanks. That list is your actual finding, and it took an afternoon.

If your processes are already mapped, abi. Agent Studio can read an automation you already run back onto the map: the steps, the systems it touches, and which of them nobody owns any more. That last column is generally the one people did not expect to be the point of the exercise.

What to do with what you find

Resist the urge to delete. The impulse after an audit like this is a clear-out, and a clear-out of things whose purpose you do not fully understand is how a company generates its own outage.

Assign first. Every line gets a name, even if the name is yours for now. Then, over the following weeks, work down the list: for each one, either confirm it still earns its place, or switch it off deliberately and watch what complains.

Deliberately is the word doing the work. An automation you disable on purpose, having told people, is an experiment. The same automation deleted quietly in a tidying mood is an incident with a confusing cause, and it will make everyone reluctant to let you near the list again.

The honest counter-argument

If your company is five people and you have four automations, skip all of this. You already know what they are, and formalising it buys you nothing but an afternoon you will not get back.

The threshold is roughly the point where somebody in the business could build an automation that you would not hear about. Once that is true, the count is worth doing, and it is worth doing before the next one gets built rather than after.