Why Brokerages Are Adding Workflow Layers Without Replacing Their AMS

This article is part of a sponsored series by Fulcrum.

The data is in the system. The work is still in email. Here is why that gap persists and what actually closes it.

Most brokerages running a well-configured AMS have the same experience. The system holds years of policy data, client history, and account detail. It is genuinely valuable. And yet when a renewal is due, the account manager is still pulling information from emails, chasing down attachments, and coordinating with a vendor for a proposal or a policy check.

The AMS has everything needed to do the work. The work still happens somewhere else.

That disconnect is the gap a workflow layer closes. And understanding why it exists is the key to understanding why adding a workflow layer is not about replacing the AMS. It is about finally making the most of it.

The Customization Trap

When the AMS becomes the default answer to every operational problem, the system accumulates workarounds. Need better renewal visibility? Build another report. Need consistent proposal output? Try to template it inside the system. Need faster policy checking? Configure a workflow and hope the team adopts it.

Over time, the system drifts far from its original design. I have seen two offices running the same AMS version with completely different renewal processes, neither of which is documented anywhere outside the people doing the work. The platform is the same. The operations are entirely different.

When those people leave, the process goes with them.

The deeper issue is that the AMS was built to store and record. It was never built to actively move work through a process. Asking it to do both creates a system that does neither as well as it should.

Where the Work Actually Lives

The tasks that consume the most time in a brokerage, building proposals, checking policies, comparing coverage, coordinating with carriers, delivering to clients, are fundamentally in-progress work. They require pulling data, generating outputs, routing steps, making judgment calls, and pushing the result back into the record when complete.

The AMS handles that last step well. The rest tends to happen in a combination of email, spreadsheets, vendor queues, and individual habits that vary by person and by office. That is where inconsistency lives, and it is why two account managers working from the same system can produce very different results.

A proposal routed to an outside vendor and returned 24 hours later still requires review, correction, and manual entry back into the system. A policy check that takes two weeks at a business processing service comes back as a report that someone has to interpret and act on. The AMS captures the outcome. The process that gets there runs in the gaps around it.

What a Workflow Layer Changes

A workflow layer sits between the AMS data and the finished work product. It takes what the AMS holds and moves it through a process: generating the proposal from the quote, running the policy comparison and flagging discrepancies, drafting the client communication, and syncing the result back to the record when the task is done.

The difference in practice is significant. A proposal that took a day to route through a vendor gets built in minutes. A policy check that ran two weeks gets done in 15, by the account manager who knows the account rather than a service team working from a report. The work that used to live in inboxes and spreadsheets moves into a process that is visible, consistent, and tied directly to the data already in the AMS.

Lexie Tonelli, Head of Strategy and Operations at Fulcrum, describes what that shift feels like from the account manager’s seat: “You’re fully in the driver’s seat when it comes to how you manage and service your accounts.” That is a different experience than waiting on a vendor queue or building a workaround inside the AMS.

Addressing the Real Objection

The hesitation most brokerages have about adding a workflow layer usually comes down to one concern: another system means another implementation, another round of training, and another tool the team may or may not actually use.

That concern makes sense when the mental model is replacement. A workflow layer operates differently because it builds on the AMS rather than alongside it. The data stays where it lives. The integrations the brokerage has built stay intact. The workflow layer handles the active work that the AMS was never designed to carry.

The brokerages that get this right tend to start with the highest-friction workflows, proposals and policy checking, where the time savings are immediate and visible. From there adoption tends to follow naturally, because the team is solving a problem they have been working around for years.

The AMS stays. The work finally has a process built around it.

Author Kathryn Lerch is Insurance Solutions Engineer at Fulcrum, an AI-powered workflow platform built for insurance brokerages. She brings 18 years of experience helping agencies improve workflows, implement technology, and scale their operations.

Topics Agencies