I've seen the same automation sitting broken for 18 months in more businesses than I can count. Nobody wants to touch it. The person who built it left. The documentation is wrong. Every time someone patches it, something else breaks. And the team just routes around it, doing the work manually, because that's faster than fighting the system.
Nine years into this work, the question I get asked most is not "should we automate this?" It's "should we fix what we have, or start over?" That's the harder call. Get it wrong and you either spend months patching something that can't be saved, or you blow up something that just needed one hour of cleanup.
This is the framework I use. It's not theoretical. I've used it to talk clients out of expensive rebuilds they didn't need, and I've used it to tell clients the hard truth that their beloved system was a foundation-level failure no amount of patching would fix.
Optimization is underrated. Most broken automations aren't broken because the design was wrong. They're broken because the edges weren't handled, the data got messy, or the business changed and nobody updated the rules. Here's when optimization is the right call.
The automation handles 80% of scenarios correctly. It chokes on exceptions, unusual inputs, or situations the original builder didn't anticipate. This is an optimization problem, not a rebuild problem. The pattern is right. The coverage is incomplete.
You know exactly when it fails and why. Predictable failures are fixable failures. If you can describe the break before it happens, you can write a rule that prevents it. That's not a rebuild. That's a patch that actually works.
The platforms it connects to are still the right platforms. Nobody is planning to replace the CRM, swap out the email tool, or change the data structure. If the environment is stable, you're fixing the automation in place, not rebuilding it on a foundation that's about to move.
There is at least one person who can read the workflow and explain what it does. Optimization requires understanding. If the knowledge exists inside the organization, you can work with what's there. If it walked out the door, that changes the math.
Low-volume automations rarely justify the cost of a full rebuild. If it processes 20 records a day and fails on 3 of them, that's a targeted fix. Save the rebuild budget for systems that touch hundreds of records a day or sit in your critical revenue path.
Here is where I have to be honest with clients, even when they don't want to hear it. Some systems cannot be saved. Patching them costs more than replacing them, and it takes longer. These are the signals I look for.
This is the clearest signal. If the original automation was built on faulty assumptions about how the data is structured, every fix creates a new problem somewhere else. You can't optimize your way out of a wrong data model. I've seen teams spend six months patching, only to end up with something more fragile than what they started with.
The company has changed. New products, new team structure, new sales process, new compliance requirements. The automation was designed around a version of the business that's two or three evolutions old. Optimizing it means preserving assumptions that are no longer true.
The automation has been patched so many times it's become unpredictable. You fix the lead assignment rule and the email sequence breaks. You fix the sequence and the CRM fields stop syncing. When patches have that effect, it means the architecture has no coherent logic anymore. That's a rebuild.
If you're migrating your CRM, replacing your email provider, or changing your project management tool, any automation built on the old platform needs to be rebuilt for the new one. Optimization isn't possible when the foundation is being replaced under the workflow.
The builder left. There's no documentation. Running the workflow in a test environment produces results nobody can explain. When institutional knowledge is completely gone and the system is a black box, you're not optimizing, you're guessing. That's more expensive than a clean rebuild with proper documentation.
When I'm standing in front of a broken automation with a client, I run through eight questions. The answers give me a score. The score tells me which direction to go. Score 1 point for each "yes."
Does the automation handle at least 70% of real-world cases without manual intervention?
Can someone on the current team read it and explain what it does in plain language?
Are all the platforms it connects to staying in place for the next 12 months?
When it fails, does it fail in predictable, repeatable ways that can be described in advance?
Has the underlying business process the automation supports stayed substantially the same?
Does patching one part of it leave the rest of the automation intact and unaffected?
Is this automation processing fewer than 100 transactions per day?
Would fixing the known failure points take less than 20% of what a rebuild would cost?
I've found this scorecard right about 85% of the time. The other 15% involves legacy integrations with unusual constraints or businesses with very specific compliance requirements. In those cases, the scorecard gets you close and then you need a deeper conversation.
Most automation systems aren't one thing. They're a chain of connected steps. And in a chain, a bad link doesn't mean you throw out the whole chain.
I worked with a marketing agency last year whose lead intake automation had a solid data capture layer and a reliable CRM sync. Both worked. But the follow-up sequence in the middle was a mess. Seven years of patches, conflicting logic, triggers that fired in the wrong order. The team had learned to just manually intervene at that stage every time.
We didn't rebuild the whole system. We rebuilt only the sequence layer and kept the intake and sync logic in place. Total time: three weeks instead of the three months a full rebuild would have required. The team stopped intervening manually within the first week.
The hybrid approach works when you can isolate the broken section, define clean handoff points on either side of it, and rebuild just that component. If you can't define those handoff points clearly, the isolation isn't possible and you're back to a full rebuild decision.
I have to be honest about something. Engineers and consultants want to rebuild. There's something satisfying about a clean start. A new system designed right, documented well, no legacy baggage. It feels like progress.
That impulse costs clients money. Rebuilds almost always take longer and cost more than estimated. My rule of thumb after nine years: take whatever a rebuild is quoted at and multiply by three. That's the real number. Scope creep, unexpected data migration complexity, retraining the team, rebuilding the reporting that was baked into the old system. It adds up fast.
The second thing I'd tell myself is that optimization has a compounding return that rebuilds don't. An automation you understand deeply and have been refining for two years is more valuable than a new build at month three. The institutional knowledge of why certain rules exist, what edge cases you've already handled, where the business tends to generate exceptions. That knowledge lives in an optimized system. It doesn't exist yet in a new one.
The third thing, and the hardest one: when a rebuild is the right call, do it cleanly. Don't half-rebuild. Don't keep the old system running in parallel for six months because it feels safer. Parallel systems mean double the maintenance, double the failure points, and a team that never fully commits to the new way of working. Make the call. Execute it. Decommission the old system on a defined date.
The businesses I've seen get this right all have one thing in common. They treat the rebuild vs. optimize decision as a business decision, not a technical one. They look at time, cost, risk, and business continuity, not just code quality. The technical assessment informs the business decision. It doesn't make it.
Pull up the automation you've been avoiding. Run the eight questions. Be honest with the answers, especially questions four and six. Those two catch the most mistakes.
If your score is in the middle range, look at the system as a chain. Map each component. Find the one or two sections that are failing. Ask whether those sections have clean handoff points on either side. If yes, the hybrid approach is worth a closer look.
If you want a second opinion before committing to a rebuild budget, that's exactly what our consulting process is designed for. I've talked more clients out of expensive rebuilds than into them. The goal is always the same: get the automation working at the lowest cost and the fastest timeline, with the least disruption to the business.
I'll look at what you have, run the scorecard with you, and give you a straight answer on whether to fix it or start over. No proposal until you have a clear picture of your options.
Book a consultation Take the AI readiness assessment