Insurance · Insurance operations capacity
Where Broker and MGA Capacity Really Goes: Repair, Waiting and Manual Effort
Broker and MGA capacity is often consumed before judgement starts — in chasing, completeness checks, re-keying, repair, reconciliation and waiting between hand-offs.
When a broker or MGA says it has a capacity problem, the first instinct is usually to look at headcount, offshore support or automation.
But “capacity” is an output.
The more useful question is what the capacity is being consumed by.
In insurance operations, a surprising amount of experienced human effort can sit around the decision-making work rather than inside it: gathering missing evidence, repairing schedules, re-keying data, reconciling differences, chasing third parties, moving information between systems and waiting for the next hand-off.
The expensive part of the workflow can happen before broking or underwriting judgement begins.
What’s normal
The normal responses are rational:
- add operations capacity;
- offshore or centralise administration;
- automate email and spreadsheet tasks;
- introduce a submission or workflow platform;
- use OCR/IDP or AI to extract document data;
- measure how many cases move straight through.
All of those can help.
But if the real workload is generated by incomplete inputs, inconsistent schedules, process variation or repeated cross-system repair, those interventions can make individual tasks faster without changing the reason the work exists.
Why it fails
Automation programmes naturally find the clean, repeatable cases first.
That is often the right place to start technically.
Economically, it can create an awkward second-order effect: the easy cases disappear and the human team is left with a denser population of exceptions.
Automation rate improves.
Average human handling effort does not necessarily improve with it.
The same problem appears with waiting. A five-minute task can create a two-day turnaround if it sits between multiple inboxes, teams or systems. Looking only at touch time makes the workflow appear efficient while the customer or underwriter experiences delay.
And repair is particularly deceptive. The person fixing a submission is visible. The upstream condition that created the repair may not be.
So the organisation optimises the repair team rather than removing the source of the repair.
What I do differently
I start with the end-to-end economics of getting a piece of work into a genuinely usable state.
For a submission, that may be “ready for broking/underwriting”. For servicing, it may be “complete and correctly recorded”. For fiduciary work, it may be “reconciled without further investigation”.
Then I distinguish three things that are often blended together:
judgement, which you want skilled people doing;
necessary control, which you need to perform efficiently;
and failure demand, where people are fixing something that should not have arrived broken.
Only then do I want to choose the intervention.
Some failure demand should be prevented. Some variation should be standardised. Some system hand-offs should be integrated. Some repetitive preparation should absolutely be automated or AI-enabled.
But the order matters.
Diagnostic
What this looks like in practice
For one broker or MGA workflow, I would want to see whether leadership can answer:
- What proportion of incoming work is usable first time without chasing or repair?
- Where is information being re-keyed, reformatted or reconciled between systems?
- Which exception categories consume the most total handling time — not simply the highest case count?
- How much elapsed time is work, and how much is waiting between teams, inboxes or third parties?
- Are brokers, underwriters or senior operations staff doing preparation that could be prevented or moved?
- Has automation removed total cost-to-serve, or mainly removed the easiest cases?
Those questions tend to expose whether the capacity constraint is genuinely volume — or the operating model around the volume.
insurance · Leania
See how Leania approaches this workflowEvidence from the work
At a major insurance broker, I led process improvement and automation analysis across policy servicing, fiduciary work and other operational workflows.
The end-to-end discovery produced an initial set of 10 opportunities equivalent to roughly 30 FTE, with a further backlog behind them. Across the wider portfolio, we identified a future savings pipeline equivalent to around 45,000 hours.
The important point is not the size of the automation list.
It is that the value appeared in different forms.
Some work involved client-payment processing and avoidable manual input. Some involved tens of thousands of emailed invoices needing to reach the CRM. Some involved carrier-query reconciliation across bureau risks. Other improvements delivered thousands of hours of saving, while changes to aviation certificate processing improved throughput by around 30%.
One technology would not have solved all of those problems.
The work required process analysis, governance, benefit tracking and the discipline to stop unsuitable projects as well as progress attractive ones.
That experience is why I am cautious when a capacity problem is immediately translated into “we need more automation”.
Capacity is where the symptom shows up.
The value is in understanding why the work exists.
The questions worth asking
If submission or servicing volume rose 20% tomorrow, would operational workload rise by roughly 20% too?
What proportion of specialist time is genuine judgement versus preparing or repairing the case?
Which defects repeatedly create chasing and rework?
Where does a case spend most of its elapsed time waiting rather than being worked?
Have we measured the human workload left behind after our existing automation?
Could we remove the source of an exception for less than it costs us to handle that exception every year?
Those are operating-economics questions, not automation questions.
The point
Broker and MGA capacity does not disappear only because there is too much business.
It disappears in the friction around the business.
If you can see where repair, waiting and manual effort accumulate, you can distinguish genuinely valuable automation from activity that should be prevented, simplified or standardised first.
That is a much better starting point for releasing capacity without simply adding another layer of technology.