Nicolas Dominici

When Not to Automate: Common Automation Anti-Patterns

When Not to Automate: Common Automation Anti-Patterns

I love automation. It’s my job. But I spend a surprising amount of time talking clients out of automating things.

Automation is leverage. It multiplies output. But if you multiply a bad process, you just get automated chaos.

Here are the most common “Anti-Patterns” I see—situations where automation makes things worse, not better.

1. Automating the Exception

The Scenario: You have a standard process that works 90% of the time. But 10% of the time, there’s a weird edge case (e.g., “Customer pays with a check” or “Shipping address is international”).

The Trap: You try to build an automation that handles every possible edge case.

The Result: You build a monster. The logic becomes a spaghetti mess of IF/ELSE statements. It takes weeks to build and breaks constantly.

The Better Way: Automate the 90% standard path. For the 10% edge cases, have the automation simply send a notification: “Hey human, this one is weird. Please handle it manually.”

2. Automating a Broken Process

The Scenario: “Our lead qualification process is a mess. No one knows who should follow up. Let’s automate it!”

The Trap: Thinking tools will fix culture or clarity issues.

The Result: You now have a bot assigning leads to the wrong people at lightning speed. You’ve automated the confusion.

The Better Way: Fix the process on paper first. Run it manually for two weeks. Then automate it.

3. The “Rube Goldberg” Integration

The Scenario: You want Tool A to talk to Tool B. But they don’t integrate directly. So you use Zapier to send data to Google Sheets, which triggers a script, which emails a parser, which updates Tool B.

The Trap: Chaining too many fragile dependencies.

The Result: One API changes, or one password expires, and the whole chain collapses. Debugging it is a nightmare.

The Better Way: Seek direct integrations or use robust middleware (like n8n) with proper error handling. If it requires 5 hops to do one thing, reconsider the architecture.

Conclusion

Automation isn’t magic; it’s engineering. Good engineering requires constraints.

Sometimes the smartest automation move is to say: “Let’s just do this part manually.”