Why Agency Automation Projects Stall — and How to Run One That Doesn't
Most principals reading this have already thought about automating some of the back-office grind. A fair number have tried something. And a fair number of those attempts quietly went nowhere — not because the technology didn't work, but for reasons that have very little to do with the technology at all.
It's worth understanding the pattern, because the failures are predictable, and the thing that makes a project succeed is mostly the thing the software vendors don't talk about.
The five ways it stalls
It got scoped as "automate everything." The most common killer. An agency decides to "automate our submissions" or "fix the service workflows," full stop — and then drowns in the complexity of every edge case at once. The work is judgment-laden in places; not every line of business behaves like the others. A project that tries to boil the ocean produces a long planning phase, a nervous staff, and nothing live.
It tried to fix the leak by replacing the agency management system. The re-keying that eats your team doesn't live inside Applied Epic or EZLynx or AMS360 or HawkSoft or Nexsure. [VERIFY: AMS fit varies by agency.] It lives between your system and the carrier portals — in the gap where data has to be moved by hand. Agencies that try to solve it by switching systems trade one set of headaches for another and never touch the actual leak.
The data was never ready. This is the one nobody mentions until it bites. If the client and policy data in your AMS is inconsistent — duplicate accounts, blank fields, a naming convention that drifted over fifteen years — then automation built on top of it inherits every flaw and amplifies it. Faster typing of bad data is still bad data. A serious effort checks whether the data is fit to build on before building, not after.
Nobody owned the change. A tool dropped on a service team that wasn't consulted, with no human-in-the-loop checkpoints and no one accountable for the new workflow, gets quietly routed around. People go back to the way they know. The software didn't fail; the rollout did.
The win was never measured. Plenty of projects "ship" and then no one can say whether they worked, because no one baselined the before. Without a measured before-and-after, the effort can't prove its value, can't earn the next phase, and can't survive the first budget review.
Notice what all five have in common. The easy part — software that reads a document and fills a form — gets treated as the whole job. The hard part — where do the hours actually go, is the data fit to build on, what's the contained first scope, who owns the new workflow, how will we measure it — gets skipped. That hard part is the work.
The 90-day path that doesn't stall
The discipline that avoids every one of those failure modes isn't complicated. It's three phases, and it starts with a number, not a platform.
Audit first (roughly weeks 1–3). Before anyone builds anything, establish where the hours actually go and whether there's a hard-dollar case worth chasing. Measure the workflow — certificates, submissions, renewals, policy checking — and scan the AMS data for the readiness issues that derail builds. The output is a baseline both sides sign: the agency's real hours and real dollars, showing their work. If there's no case worth pursuing, you find that out cheaply, up front. This phase kills the "data was never ready" failure and the "never measured" failure in one move, because it produces the baseline everything else is measured against.
Build contained (roughly weeks 4–9). Take the single highest-value, lowest-judgment workflow the audit identified — usually certificate issuance or submission re-keying on one defined book — and automate just that. Resell a proven engine rather than reinventing it; own the part that matters, which is wiring it around your AMS, handling the carrier-portal reality, and setting human-in-the-loop thresholds so a person reviews anything uncertain. Build the measurement harness alongside it. This phase kills the "automate everything" failure (the scope is deliberately one workflow) and the "replaced the AMS" failure (it wraps around the system you run).
Run and expand (ongoing, optional). Once the first workflow is live and the numbers hold, expand along the obvious ladder — certificates and submissions, then renewals, then receivables. A proven first win earns the right to the second. And because someone owns the new workflow and the team was brought along, this phase kills the "nobody owned the change" failure.
The teaching takeaway: agency automation almost never fails in the software. It fails in the scoping, the data, and the change management — the parts a tool can't sell you. Start with a measured baseline, scope the first build to one contained workflow, and put someone in charge of the change. Do those three things and most of the ways this goes wrong are off the table before you begin.
Start where every non-stalling project starts
Every project that doesn't stall begins the same way: with a number instead of a guess. You can't scope a contained first build, or measure whether it worked, until you know where your hours actually go.
Our free agency calculator is that first number — certificates, submissions, renewals, and policy checking turned into hours and dollars a year, with every step shown. It's the front end of the audit, and you keep it whether or not we ever talk.
If the number says there's a case, a twenty-minute call is the right next step to talk through what a contained, measurable first build would look like at your agency — and, because we tie our fee to the result, what "no fit, no fee" means in practice.
We measure it like a deal, not a demo. A defensible number, never a guess.