Broker Analytics Software: What Brokerages Need in 2026

A commercial lines principal asks a plain question on a Monday morning: which accounts renewing in the next ninety days are at risk, and who owns them. On Thursday an operations manager delivers a spreadsheet. It was built by exporting an expiration list from the agency management system, opening the shared inbox to see who had gone quiet, checking two carrier portals for pending audits, and asking three producers what they knew. The answer was good. It took most of a week, and it will be stale by the following Monday. That gap, between a question any principal can ask and an answer that takes four systems to assemble, is what broker analytics software is supposed to close. Most of the products sold under that name close only part of it, and the part they close is usually the part you already had.

This guide is for insurance and commercial brokerages: retail agencies, wholesalers, program administrators, benefits shops. It maps the questions that actually get asked in a brokerage, names which system holds each input, separates the real categories of brokerage analytics software from each other, and is direct about where a chat based workspace like Skopx belongs and where it does not.

Why brokerage data is harder than it looks

A brokerage is not a company with messy data. It is a company whose core record, the policy, is written and maintained by somebody else. The carrier owns the policy. The brokerage owns a representation of it. Every number a broker reports on is downstream of a document, a download feed, or a statement that arrives on the carrier's schedule and in the carrier's format.

That creates four structural problems that no visualization layer solves.

The system of record is split. Client, policy, and activity data live in the agency management system: Applied Epic, AMS360, EZLynx, HawkSoft, Nowcerts, or one of a dozen others. Sales activity for new business often lives somewhere else entirely, in HubSpot or Salesforce or a shared spreadsheet, because producers refused to work prospects in the AMS. Money lives in the accounting system. None of the three agrees on what a "client" is.

Policy data arrives late and lossy. IVANS download and carrier real time interfaces bring policy and commission data into the AMS, but not for every carrier, not for every line, and not always with the fields you need. Anything outside the download set gets keyed in by a service team under time pressure, which means the fields your analytics depend on are the fields most likely to be blank.

Revenue arrives twice, in two shapes. Agency bill premium flows through the trust account and shows up in accounting. Direct bill commission arrives as a carrier statement, often a PDF, sometimes a CSV, sometimes both for the same month. Any revenue report that does not reconcile those two streams is reporting on half the book.

Definitions are contested. Retention can be measured on policy count, premium, or commission revenue. A remarket that moves an account from one carrier to another looks like a cancellation plus a new sale in most systems, which quietly depresses retention and inflates new business production at the same time. Two people in the same agency can pull "retention" and get numbers twelve points apart, both correct under their own definition.

Any broker analytics software evaluation that skips these four problems is an evaluation of chart styling.

What broker analytics software has to answer

Skip the feature grid. Write down the questions leadership asks, then check whether a candidate tool can reach the data behind each one. In brokerages the list is remarkably consistent.

Book growth. Where did commission revenue come from this year: new business, rate, exposure change, or acquisition. Which lines and which industries grew. What is the mix between commercial, personal, benefits, and surplus.

Retention. What percentage of revenue renewed, on a definition everyone agreed to in advance. Which accounts left and why. Whether the loss was price, service, a carrier non renewal, or a producer departure.

Producer performance. New business written per producer against plan. Retention on each producer's own book, which is the number most agencies never separate from agency wide retention. Validation progress for newer producers. Aged receivables sitting on their accounts.

Pipeline and hit ratio. Quotes out, quotes bound, average account size, and how long a submission sits with an underwriter. This one lives in the CRM if it lives anywhere.

Commission reconciliation. Expected commission versus commission received, by carrier and by month, with the gaps explained.

Carrier concentration and contingents. How much premium sits with each carrier, and whether the loss ratio and growth on that book puts a profit sharing agreement in reach or out of it.

Service load. Certificate volume, endorsement turnaround, claim activity per account manager. The operational layer that determines whether the retention number holds next year.

Every one of these is a question about a business, not a request for a chart. That distinction matters when you compare product categories, and our broader field guide on business analytics software explains why teams so reliably buy the publishing product when they had the investigation problem.

Which system holds each input

Before you can judge a tool, map the inputs. This table is the single most useful artifact in a brokerage analytics evaluation, and it takes an afternoon to fill in for your own shop.

Two patterns fall out of this table almost every time. First, the AMS is necessary for most questions and sufficient for very few. Second, a meaningful share of the inputs are unstructured: statements in a shared mailbox, quote threads in email, a producer's note in Slack. That second pattern is why traditional business intelligence struggles here. A warehouse loads tables. It does not read the renewal thread where the client mentioned they were getting a competing quote.

The four kinds of broker analytics software

Vendors in this space all describe themselves as analytics for brokers. They are four different products.

AMS native reporting. The report writer that shipped with Epic, AMS360, or EZLynx. Strength: it sits directly on the system of record with no pipeline and no license negotiation. Weakness: it only sees the AMS, its output formats are rigid, and building anything beyond the shipped templates usually requires a specialist who left two years ago.

Vertical insurance BI. Products purpose built for agencies that pull from the AMS on a schedule, apply insurance specific definitions, and publish dashboards for book, retention, and producer performance. Strength: the definitions are already encoded, which saves months of arguing. Weakness: pricing assumes an enterprise brokerage, the connectors are strong on the AMS and thin on everything else, and the implementation expects an analyst you may not have.

General purpose BI. Power BI, Tableau, Looker, Sigma, pointed at a warehouse you build. Strength: total flexibility and one place for every source. Weakness: you are now running a data engineering project, and someone has to own the model that converts raw AMS tables into an agreed definition of retention. If you are considering this route, the tradeoffs in AI data modeling tools are worth reading before you commit a headcount to it.

Chat based analytics workspaces. Connect the systems you already use, then ask questions in plain language and get answers with citations back to the underlying records. Strength: no build step, and cross system questions work immediately because the tool retrieves from several sources at once. Weakness: it does not produce the polished recurring board packet a BI platform produces, and it can only see systems it can actually connect to.

Most brokerages that get this right run two of these deliberately. The AMS report writer or a vertical product for the recurring packet, and something faster for the Monday morning question that nobody built a view for.

Retention, producer performance, and the definition problem

The single highest return activity in broker analytics is not buying software. It is writing down four definitions and getting the principals to sign off.

Retention basis. Pick one primary measure and publish it consistently. Revenue retention is the honest one for a brokerage, because it captures both lost accounts and shrinking accounts. Policy count retention flatters personal lines shops with many small policies. Client retention is useful for account rounding conversations and useless for forecasting revenue.

Remarket handling. Decide, in writing, that moving an existing client from Carrier A to Carrier B at renewal is a retained account, not a loss and a win. Then make sure the report actually implements that rule, because the default in most systems does not.

New business. Is it new client only, or does it include new lines sold to existing clients. Both are legitimate. Reporting one number while producers assume the other is how compensation disputes start.

Revenue recognition timing. Booked at effective date, or recognized when the commission lands. Agency bill and direct bill will disagree here by weeks or months, and the disagreement shows up as phantom seasonality in every chart you produce.

Producer performance deserves its own caution. A producer scoreboard built on new business alone rewards the person who writes a large account and lets it lapse in year two. The useful producer view has four columns: new business written, retention on their own book, average account size, and receivables aged past sixty days on their accounts. That is a four column table, not a dashboard, and the guidance in when to use different types of graphs applies directly: precise comparison across a handful of named people is a table, every time. Charts are for trends and distributions, not for eight producers and four metrics.

Commission reconciliation is a matching problem

Ask a brokerage where analytics would pay for itself fastest and the honest answer is usually commission reconciliation, which most shops do partially or not at all. The structure of the problem is simple and the execution is grim.

Expected commission is calculable: premium multiplied by the commission rate on the carrier agreement, adjusted for endorsements, cancellations, and audits. Received commission arrives on statements, one per carrier per month, in whatever format that carrier uses. The work is matching them, line by line, and explaining every difference.

The differences have a small number of causes. Timing, where the policy booked in one month and paid in the next. Endorsements that changed premium after the statement cut. Cancellations with return commission. Audits on workers compensation and general liability that settle months late. Rate errors, where the carrier paid at a rate other than the one in your agreement. And plain omissions, where a bound policy never appears on any statement at all.

Only two of those causes represent real money left on the table, and they are the last two. A reconciliation process that finds them pays for a lot of software. The obstacle is almost never analysis. It is that the statements arrive as attachments in a shared mailbox and nobody has time to turn a hundred PDFs a month into rows. That is a document processing problem before it is an analytics problem, which is why automated data processing tools belong in this evaluation alongside the reporting tools. Get the statements into structured rows and the matching becomes a query. Leave them as attachments and no amount of insurance broker analytics tooling will help.

Where Skopx fits, and where it does not

Skopx is an AI workspace that connects to nearly 1,000 tools a company already uses, including Gmail, Slack, HubSpot, QuickBooks, Google Sheets, Stripe, and Google Analytics. You ask questions in chat and get answers with citations back to the records they came from. It sends a morning brief, runs an insights engine that surfaces risks and anomalies across connected systems, and lets you build automations by describing them in chat. It uses your own AI key for any major model, with zero markup on the model usage. Solo is $5 per month and Team is $16 per seat per month, which is a different order of magnitude from vertical insurance BI.

Here is the honest boundary.

Skopx is not an agency management system. It does not replace Epic, AMS360, or EZLynx, does not hold policies, and does not issue certificates. Your AMS stays exactly where it is.

Skopx does not scrape carrier portals. If loss runs live behind a portal login with no connector, Skopx cannot see them. Nothing honest can, short of a person downloading the file. The workaround is the same one your team already uses: someone pulls the loss run, and once it lands somewhere Skopx can read, a shared drive, a sheet, an inbox, it becomes answerable.

Skopx is not a dashboard builder. It does not produce the governed board packet. If your requirement is a polished monthly artifact with fixed definitions distributed to a wide audience, buy a product built to publish, and read live analytics for how to think about refresh cadence on that kind of surface.

What Skopx does well in a brokerage is the layer between those things. The renewal thread in Gmail, the producer's note in Slack, the receivables in QuickBooks, the pipeline in HubSpot, and a scheduled AMS export sitting in a sheet are all readable at once. So the Monday question, which renewing accounts look shaky and who owns them, becomes a chat message rather than a four day assembly job. The morning brief can lead with accounts that went quiet before a renewal. The insights engine flags a carrier whose statement came in materially under the expected commission, or a producer whose retention slipped while their new business held steady.

The practical unlock for most agencies is the AMS export. If your management system has an API or a scheduled export to Google Sheets or a database, that export becomes the bridge between policy data and everything else. It is not real time, and you should not pretend it is. For most brokerage questions a nightly refresh is entirely sufficient, and the distinction between nightly and streaming is covered properly in real-time operations analytics.

Chat built workflows cover the recurring version of the same work:

Ninety-day renewal risk brief

Monday 7:00

Weekly trigger ahead of the producer meeting

Read renewal export

Policies renewing in the next 90 days from the AMS export sheet

Scan account email

Recent threads per account contact, flagging silence or complaint language

Check receivables

Aged balances and premium changes for the same accounts

Rank the risk

Premium at stake, contact silence and receivable age into one ordered list

Post to producers

One message per producer with their own accounts and a citation for every flag

What to ask a broker analytics software vendor

Bring the input map from earlier to every demo and work down it.

Which of my systems do you connect to, natively, today. Not on the roadmap. Ask specifically about your AMS by name and version, your accounting system, and your CRM. Many products that market themselves as insurance broker analytics support two or three management systems well and the rest through a CSV upload.

How do you handle a remarket at renewal. This is the single best question for separating vendors who understand brokerages from vendors who ported a generic product. If the answer is vague, their retention number will be wrong for your shop.

Where does the commission rate come from. If the tool cannot hold your carrier agreements, it cannot compute expected commission, and reconciliation is off the table.

What happens to the fields the service team leaves blank. Every AMS has them. Ask whether the tool silently excludes those records or flags them.

Can I see the source record behind a number. A figure without a path back to the policy, invoice, or statement line it came from will not survive its first challenge in a leadership meeting.

Who operates this in ninety days. If the answer is a data analyst and you do not have one, you have found your real constraint. Buy the tool that matches your staffing, not your ambition.

Price the whole thing honestly, including internal time to maintain the export, clean the fields, and settle the definitions. The same discipline applies to marketing side spend you are evaluating in parallel, which the guide to choosing a data driven marketing platform works through in detail. If you want to see what a chat first workspace costs before committing to a vertical BI implementation, the pricing page is short.

Frequently asked questions

Is broker analytics software different from general business intelligence?

The analysis techniques are identical. What differs is the domain model. Brokerage analytics software that is worth the premium ships with insurance specific definitions already encoded: written versus earned premium, agency bill versus direct bill, remarket handling, validation schedules, contingent commission thresholds. If you buy general BI you will build those definitions yourself, which is real work but produces something you fully control. If you buy vertical, verify their definitions match how your principals actually think, because inherited definitions you disagree with are worse than none.

Can broker analytics work if our AMS has no API?

Partly. Almost every management system can produce a scheduled export, even if it is a report emailed to an address on a timer. Land that export somewhere structured, a Google Sheet, a shared drive, a small database, and it becomes queryable alongside your email, CRM, and accounting data. You lose real time freshness, and you should say so out loud rather than implying the numbers are live. For book, retention, producer, and receivable questions, a nightly or weekly refresh is almost always enough.

What about carrier portal data like loss runs?

Assume no tool reaches it automatically unless the carrier publishes an interface and the vendor has built to it. Loss runs, some claim detail, and certain policy documents commonly sit behind a portal login. The realistic pattern is that a person downloads the file on a cadence and drops it in a shared location, after which it becomes readable like anything else. Be skeptical of any broker analytics vendor implying they pull portal data universally.

How do we stop retention numbers from being argued about?

Publish the definition next to the number, every time. State the basis, revenue or policy count, state how remarkets are treated, state the measurement window, and state which records were excluded for missing data. Most retention arguments are not about the math. They are about two people using different definitions and neither one saying which.

Do we need a data warehouse?

Not to start. A warehouse earns its keep when several people need to agree on definitions permanently and query volume outgrows exports. Before that, a scheduled AMS export plus direct connections to your other systems answers most questions at a fraction of the effort. Build the warehouse when a specific, repeated failure makes the case for it, not because a vendor deck says maturity requires one.

Where does a chat workspace fit against a real BI product?

They solve different halves. BI publishes the recurring artifact with governed definitions to a wide audience. A chat workspace answers the question nobody anticipated, across systems, in minutes, with citations. Brokerages that run both keep the packet stable and stop building one off reports for every question, and the comparison in Veezoo vs ThoughtSpot is a useful look at how the natural language category itself splits.