Insurance Broker Software Problems: The 7 That Cost Agencies Real Commission, and How to Avoid Them

Why does scope creep into replacing the agency management system happen so often?

Because the boundary feels arbitrary once you start. The submission tracker needs the account, so it reads accounts from the agency management system. Then someone asks why an account manager updates an address in two places. Then a producer wants commission on the same screen as the pipeline. Every step is individually reasonable and the destination is a rewrite of Epic.

It happens more in insurance than in other industries for a specific reason: your management system genuinely is incomplete. Applied Epic, Vertafore AMS360, HawkSoft, EZLynx and Nowcerts hold the policy record, take the Ivans download, run direct bill and agency bill accounting and produce ACORD forms. None of them run the actual work of a brokerage. So the frustration is real, and it is easy to mistake incompleteness for replaceability.

The fix is to draw the line in writing before the first sprint and treat it as a constraint rather than a preference. The management system remains the record of policy and the accounting engine. Your build owns the pre bind pipeline, renewal triage, the document intake pipeline, the service layer and the reporting your leadership reads. Anything that requires you to reproduce carrier download or agency bill accounting is out of scope by definition, not by negotiation. Write that sentence into the statement of work, because it is the single decision that determines whether the project ships in four months or dies in fourteen.

What goes wrong when you migrate fifteen years out of Epic or AMS360?

Structured account and policy data usually moves cleanly. The pain is everywhere else, and agencies consistently underestimate it because the export ran fine in a test.

Attachments are the first problem. Fifteen years of scanned dec pages, loss runs, signed applications and email printouts, many filed against records that no longer exist, some duplicated three times because three people saved the same PDF. The second problem is activity history, which is where the institutional memory lives and which nobody can specify a rule for, since an activity is sometimes a task, sometimes a note and sometimes a system event. The third is the accounting ledger, which cannot be migrated one to one into a system that is not doing the accounting, and should not be.

The pattern that works is to stop trying. Leave history in the management system as the record of policy, and sync forward only what the new system needs to function: current accounts, in force policies with terms, open renewals, and the documents attached to anything active. Expect a full historical extraction to add four to eight weeks if you insist on it, and ask honestly who will read a 2014 activity note. Whatever you decide, agree the identifier strategy first. If your new system keys on a policy number that changes at renewal, every historic join will break quietly.

Why do carrier and AMS integrations break after launch?

Because most of them were never integrations. They were email parsing, a portal login and a scheduled job, and each of those has a different failure mode.

Carrier email is the workhorse and it is fragile in a particular way: a carrier changes their quote letter template, the parser keeps running, and it silently extracts the wrong premium or misses subjectivities entirely. Nothing errors. A market row shows quoted when it should show quoted with three open subjectivities, and your marketer trusts it. Portal jobs break more honestly, because a login page change stops them dead. And management system access through the Applied or Vertafore partner programs runs on the vendor's timeline and terms, so a credential or contract lapse can cut the feed off entirely without anyone in your building being told.

Three defences. Every parser carries a confidence score and anything below the threshold routes to a human review queue with the source document beside the extracted field, so a wrong answer becomes an eight second confirmation rather than a silent error. Every feed reports its own freshness, and a carrier that has sent nothing for longer than usual raises an alert rather than reading as a quiet week. And parser maintenance is a named, priced line in the support agreement, because carrier templates change and somebody has to own that.

What happens when certificate wording verification is not covered?

Certificates look like a convenience feature and get pushed to phase two. They are actually your errors and omissions exposure with a self service button on the front.

The failure is specific. A general contractor asks for an additional insured with a named blanket endorsement form number and a waiver of subrogation. Somebody issues an ACORD 25 because the request looked like the last forty. Nothing on the policy actually supports that wording. Two years later a claim lands, the certificate says one thing, the policy says another, and the conversation is about your professional liability rather than the carrier's.

Epic and AMS360 issue certificates and hold holder lists, so this is not a missing feature in their products. The gap is that nothing checks the requested wording against the endorsements on file. A build that adds a portal without that check has made the exposure faster and more frequent, which is worse than the manual process it replaced.

What to require instead: the system pulls the bound policy, verifies the additional insured and waiver wording against the endorsements actually on it, and issues in under a minute with a full audit trail when supported. When it is not supported, it refuses and opens a task naming the exact gap. That refusal record is your defence later. While you are in this area, settle the rest of the compliance work at the same time, because retrofitting it costs several times as much: encryption of nonpublic personal information at rest, record level audit logging, role separation so producers cannot pull each other's books, and documented retention and purge rules under the insurance data security laws your states adopted from the NAIC model, plus NY DFS Part 500 if you write New York.

Should you build custom or configure what you already own?

If you are under roughly $2 million in commission, mostly personal lines, one or two locations, configure. EZLynx or HawkSoft plus Indio or Broker Buddha for applications will beat anything you commission and will keep beating it for years. Buy it, enforce one process, and spend the difference on producers. We turn this work away regularly and would rather say so now than four months in.

Before you commission anything, exhaust the configuration you have already paid for. Most agencies are running a fraction of what Epic or AMS360 can do because nobody has owned configuration since implementation. Custom fields, activity templates, workflow automation and the reporting module are usually underused, and a fortnight with a good consultant is cheaper than any build.

Custom starts to win when the gap is structural. More than a quarter of your revenue sits in excess and surplus lines, program or specialty business where Ivans download does not reach. Three or more people exist mainly to move data between systems. You cannot answer which submissions went quiet in under a day. Or your combined annual spend on management system seats, rater, certificate tool, electronic signature and workflow bolt ons already crosses six figures, at which point you are funding a build without owning one.

How do hidden costs get into the quote?

A focused first release covering submission tracking, carrier email parsing, the renewal workbench and a read only sync from your management system runs $60,000 to $130,000 and ships in 12 to 16 weeks in Digital Heroes delivery experience. A full platform adding documents, certificates, commissions, a client portal and two way writeback runs $150,000 to $400,000 phased over 6 to 12 months. The trouble is what sits underneath those numbers.

Commission accounting is the single most underestimated module in every estimate we have seen. Thirty carriers, thirty statement formats, fuzzy matching on named insured plus policy number plus effective date, then producer splits that change retroactively when a mid term endorsement moves premium. Ask any developer to walk that path out loud before you accept their number.

Surplus lines filing and stamping office rules are the second. Each additional state is real work, not a configuration toggle, so the quote must name the states in scope. Third is management system API access, where the partner program timeline and fees are calendar time you cannot compress and should start in week one. Fourth is migration, which belongs in its own workstream with its own number. And fifth is the security and audit work described above, which is cheap at design time and expensive later.

What separates a build that works from one that fails here?

Make the developer draw the data model before you sign. Account, policy, policy term, line of business, coverage, endorsement, market, submission, quote, claim, certificate, holder, transaction. If policy is one flat row with no terms and no endorsements, they have not shipped in this industry. Then ask how a mid term endorsement that changes premium flows through to commission and then to producer compensation, retroactively, without a manual journal entry, and watch what happens.

Ship the carrier email parser first. It needs nobody's permission, it works while the partner program paperwork is still moving, and it removes more daily friction than anything else in the build. If your first release does not produce a visible answer to which markets have gone quiet past four business days, it has not changed how the agency works.

Design the exception queue as a feature, not a fallback. Nothing extracts at full accuracy and any vendor claiming otherwise is selling. Target straight through processing on clean, machine generated carrier documents and route the rest to a person with the source beside the field.

Measure two numbers before you start and again ninety days after go live: hours per week spent re keying carrier documents, and the count of submissions with no carrier response past four business days. Those two are the entire business case. If neither has moved, the software is decoration.

And settle ownership on day one. Source in your repository, infrastructure in your cloud account, a documented data model, and a handover document good enough that another firm could pick it up in a week. Ask to see the handover document from the developer's last engagement. If it does not exist, you are renting a dependency.