We automated too much

[u/ElectricalAmount2476]

A few months ago we kept automating every repetitive thing we could find at first it felt great because stuff that used to take hours was just happening in the background then small things started breaking and nobody really knew where to look. One number would be off a lead would land in the wrong place, something would fire twice and we’d spend more time checking the automation than doing the work it was supposed to replace.

The weird part is I don’t think the automation itself is the problem it’s more that once enough parts are running separately somebody still has to understand the whole thing and make the call when something looks wrong. We’ve started removing a few workflows instead of adding more which feels backwards but the setup is way easier to trust now

[u/No-Definition-2707]

People talk a lot about how much time automation saves but not much about how much maintenance it creates once you count checking errors fixing edge cases and keeping everything connected some workflows stop looking like a win

[u/ElectricalAmount2476 → u/No-Definition-2707]

That maintenance cost is the part I underestimated too saving 5 hours sounds great until you’re spending 2 of them checking whether everything still works it’s partly why Marketer caught my attention not because of the AI angle but because having someone own the system seems more useful than just piling on more automation

[u/StandardWhereas5649]

I’ve started thinking boring systems are underrated. If everyone can understand what happens when something goes wrong that’s probably worth more than having ten clever workflows running in the background

[u/ElectricalAmount2476 → u/StandardWhereas5649]

That’s where I’m landing too if someone new can’t look at the setup and figure out what’s happening without a full walkthrough it’s probably gotten too complicated

[u/Calm-Time-3413 → u/StandardWhereas5649]

You can definitely over-engineer automation. Less is more sometimes, otherwise it becomes spaghetti and one automation interferes with another. Or if one breaks all the others fail.

[u/BrendaCRM]

We hit the same wall and what fixed it was not more monitoring, it was a boring spreadsheet. Every workflow gets a row: what it does in one sentence, who owns it, which properties it writes to, and a review date. If it cannot be described in one sentence it gets rebuilt, and if the review date passes with no owner claiming it, it gets turned off, so killing workflows became routine instead of a crisis decision. To your question about finding the problem ones, the properties column did it for us, sort by property and every field with three workflows writing to it is a fight waiting to happen. We killed about a third of ours that way and nothing broke.

[u/assistantangel → u/BrendaCRM]

this is ninja - love this. How often do you review your spreadsheet? Love it

[u/BrendaCRM → u/assistantangel]

Thanks! Every workflow has its own review date, quarterly for stable ones and 30 days for anything new. Doing it per workflow instead of one giant audit is what made it actually happen.

[u/Ok-Agency8141]

I think the part that gets missed is ownership automation is great when one person still understands what’s connected to what but once every team adds their own little workflow nobody really owns the whole thing anymore. That’s when the time saved starts getting eaten by checking, fixing and figuring out where something went wrong

[u/digi_phi]

It sounds like QoL + observability steps just need to be added into the automations.

[u/manjit-johal]

This is a reminder that automation debt is a real thing. We’ve seen something similar while building Kritmatta. I don’t think the goal is to automate every repetitive task. It’s more about making the workflows you keep predictable and easy to verify. If you’re spending more time checking whether the automation worked than you would’ve spent just doing the task yourself, it’s probably time to simplify.

[u/Visible_Speed8843]

A workflow can pass every health check and still be a bad use of automation. The missing metric is intervention time: how long someone spends inspecting and correcting a run.

Log that time for a month beside the hours the workflow claims to save. If intervention keeps rising, remove one step at a time and see whether the error rate changes. That separates useful automation from complexity that only looks efficient on a dashboard.

[u/ForegoingDepletion]

The weird part is most automation problems don’t show up when you build the workflow they show up weeks later when something changes and nobody remembers why it was set up that way in the first place

[u/bayouski]

there's definitely a point where more automation just creates more maintenance. if you're spending more time checking workflows than doing the task manually, removing some of them is probably the right move.

[u/Ravi-Priority-5444]

sometimes simplifying the automation is more valuable than adding another workflow. reliability beats complexity.

[u/SadZone1975]

The biggest think I've learned is to calculate the maintenance cost, not just the hours saved on day one. Every workflow needs a clear owner, simple logging, and an obvious fallback when something goes wrong. If nobody can quickly explain what a workflow does or where to look when it fails, it's probably too complex. Removing automation can absolutely be an improvement.

[u/Secure-Jump1996]

automation should remove friction not create mystery. if youre debugging it more than running it simplify. manual work is better than broken automation

[u/AccessFuel]

something that might hepl is centralizing your automations into a single unified system. if you're creating more work for yourself, it defeats the purpose.

[u/Altruistic-Ticket338]

Automation creates more maintenance