Every quarter, someone in leadership watches a demo, reads a case study, or comes back from a conference fired up about automation. The pitch is always the same: cut costs, move faster, do more with less.
So the team picks a target, builds or buys a solution, and six months later the project is either abandoned or limping along delivering a fraction of the promised value.
The automation itself usually works fine. The problem is they automated the wrong thing.
After years of building automation for both network operations and business workflows, I keep seeing the same patterns. Here is where teams go wrong and how to pick better targets.
The Shiny Problem Trap
The first instinct is to automate whatever is most visible or most annoying. That feels logical, but visibility and impact are not the same thing.
A common example in network operations: a team decides to automate firewall rule deployment because the change request queue is long and everyone complains about it. They spend months building it out. But the actual bottleneck was never the deployment. It was the approval workflow, the back-and-forth on rule definitions, and the lack of a standard template. They automated the fast part and left the slow part untouched.
In business operations, the equivalent is automating report generation when the real problem is that nobody reads the reports, or that the data feeding them is inconsistent.
The fix: Before automating anything, map the full workflow end to end. Time each step. The bottleneck is rarely where people think it is.
Starting Too Big
Another pattern: teams go after the complex, high-value process first. It makes sense on a spreadsheet. If this process costs us $500K a year in labor and that one costs $50K, obviously we start with the big one.
But complex processes are complex for a reason. They have edge cases. They have institutional knowledge baked in that nobody documented. They touch five systems and three departments. The automation project becomes a rewrite of half the business logic, and suddenly you are two quarters in with nothing in production.
In network automation, this looks like trying to build a full self-healing network before you have automated device inventory. In business workflows, it looks like trying to automate the entire sales pipeline before you have reliable lead capture.
The fix: Start with something small, boring, and repeatable. Device config backups. Lead notification emails. Data validation checks. Get a win. Build confidence. Then scale up.
Automating Without Measuring
If you cannot measure the current state, you cannot prove the automation helped. This sounds obvious, but I have seen teams deploy automation and then struggle to justify the investment because they never captured baseline metrics.
How long does a network change take today, from request to completion? How many leads come in per open house and how many get a follow-up within 24 hours? How many hours per week does your team spend on manual config audits?
Without these numbers, automation becomes a faith-based initiative.
The fix: Spend a week measuring before you build anything. Track cycle time, error rates, volume, and labor hours. These become your "before" snapshot and your success criteria.
Ignoring the Human Side
Automation does not exist in a vacuum. It changes how people work, and people have opinions about that.
I have seen perfectly good automation sit unused because the team it was built for was not involved in designing it. They did not trust it. They kept doing things manually "just to be safe." Eventually the automated path and the manual path diverged, and the automation became a liability instead of an asset.
This happens in NOC environments where engineers have spent years building muscle memory around CLI workflows. Hand them a self-service portal and they will route around it unless you brought them into the process early.
The fix: Involve the people who do the work today. Not just as reviewers, but as co-designers. They know the edge cases. They know what breaks. And if they help build it, they will actually use it.
Treating Automation as a One-Time Project
The most expensive mistake is treating automation as something you build once and walk away from. Systems change. APIs get deprecated. Business rules shift. The process you automated in January may not match reality by June.
This is especially true in network environments where firmware updates, new hardware, and topology changes can break automation that worked perfectly last month. And in business workflows where CRM fields get added, team structures change, and new compliance requirements show up.
The fix: Budget for maintenance from day one. Assign ownership. Build in monitoring and alerting so you know when an automated process starts failing before your customers or your team notices.
A Better Framework for Choosing What to Automate
When evaluating automation candidates, score them on four criteria:
Frequency: How often does this process run? Daily tasks beat quarterly tasks. More repetitions mean more value and faster feedback.
Consistency: Is this process done the same way every time, or does it require heavy judgment? Consistent processes automate well. Judgment-heavy processes need a human in the loop, at least at first.
Impact of errors: What happens when this process is done wrong? High-error-impact processes (like network changes in production) benefit enormously from automation that enforces guardrails and validation.
Current pain: Not just "is this annoying" but "is this causing measurable problems." Missed SLAs, lost leads, compliance gaps, engineer burnout.
The sweet spot is high frequency, high consistency, meaningful error impact, and real pain. Start there.
The Compound Effect
The real value of automation is not any single workflow. It is the compound effect of stacking small automations that work reliably. Each one frees up time and attention for the next one. After a year of disciplined, well-chosen automation, a team operates fundamentally differently than one that swung for the fences on a single big project.
I have watched NOC teams go from firefighting mode to proactive monitoring in under six months, not by deploying one massive platform, but by automating five small things well: config backups, compliance checks, device inventory, alert enrichment, and change validation.
The same principle applies to business workflows. Automate lead capture, then follow-up, then qualification, then handoff. Each piece is simple. Together, they transform how the business operates.
Getting Started
If you are evaluating what to automate next, start with the framework above. Map your workflows, measure the current state, pick something small and frequent, involve your team, and plan for ongoing maintenance.
If you want to talk through your specific situation, whether it is network operations, business workflows, or both, I am always happy to compare notes. You can find more of my thinking at primeautomationsolutions.com.
Top comments (0)