Insurance agency back office support is usually compared on price. It is more useful to compare on unit, because the unit you buy decides what you are able to see afterwards.
There are two units on offer. You can buy a seat, which is a person or a fraction of one, available for a period. Or you can buy a task, which is a completed piece of work. The price difference is the obvious part. The difference in what you learn is the part that compounds.
This piece covers what a seat hides, what a task measurement gives you, what per-task data lets you decide that per-seat data cannot, and what buying by task does not fix.
A seat is a bet on volume
When you buy a seat, you are committing to a fixed amount of capacity before you know how much work is coming. There are only two ways that resolves, and both cost something.
If the volume comes in under what you bought, you are paying for idle capacity, and it is invisible because a person who is not busy still looks busy. If the volume comes in over, the overflow goes back to your own team, which is the situation you were trying to fix. A seat prices the availability of work, not the completion of it.
The subtler problem is that a seat gives you one number a month. That number cannot tell you which request types are expensive, which are getting slower, or which are worth moving next, because it was never broken down. You end up managing a relationship on a feeling about whether it is going well.
A task is a measurement as well as a unit
When the unit is a completed task, the invoice and the operational record are the same object. Every request has a type, a duration, an owner, and a cost attached to it, because those are the things that produced the number.
That changes the conversation from whether the arrangement feels worth it to which specific work is worth sending. You can see what every task costs. You can see which types are stable and which vary. And you can see the direction of travel: across the agencies we operate, cost per task has been cut roughly in half since launch, because the work is measured well enough for that to be improvable at all.
It also removes the utilisation problem in both directions. You pay for work you sent, so a quiet month costs less and a heavy one does not bounce back to your team. That is the same shift described in moving service from a fixed cost to a variable one, applied to the unit of purchase rather than the staffing model.
What per-task data lets you decide
Three decisions become answerable, and none of them are available from a monthly seat invoice.
- What to move next. Sequencing the offload stops being a judgment call when you can see which request types carry the most volume and the most variation.
- Where your own process is the problem. If one request type costs consistently more than its peers, the usual cause is ambiguity in how your agency defines it, not the people doing it. That is worth fixing regardless of who does the work.
- What the peak actually cost. Comparing a busy month against a quiet one in the same units turns a stressful quarter into a number you can plan against next year.
For multi-office groups there is a fourth. Tasks defined the same way everywhere make offices genuinely comparable, which is the thing that usually makes the numbers add up in consolidating service operations.
What buying by task does not fix
It is worth being straight about the limits, because per-task pricing gets oversold.
It does not work on undefined work. A task can only be priced and measured if there is agreement about what it is and when it is finished, so the first request type you send has to be one you can describe. That is why certificates and endorsement processing are the usual starting points and claims support is usually last.
It also does not remove the need for judgment on your side. Knowing that a request type costs more than its peers tells you where to look, not what to do. And it does not, by itself, make quality good. Measurement tells you when something went wrong faster, which is worth a lot, but the controls that keep it from going wrong are separate: routing by license and skill, an escalation rule for uncertain work, and every action logged with actor, timestamp, and reason.
COVU runs on top of your AMS, not instead of it, with 8 AMS integrations live. Your own staff stays the default, and this is extra capacity when you need it. Nothing is carved out, the book stays yours, and you decide request by request. The insurance agency back-office support page sets out how the model is scoped.
What the production data shows
Across the agencies we operate:
- About 40,000 tasks a week are classified and routed with no manual intervention, which is the volume the per-task measurement is built on.
- AI triage filters about 68% of inbound as noise, at a 98% triage success rate, in under 10 seconds per item, so you are not paying attention to things that were never work.
- Roughly 44% of completed service tasks are executed by AI, with the rest routed to people by license and skill.
- Median handle time on a task is 3.8 minutes, down 16% from 4.5.
- Escalations, meaning a task where someone is stuck and has to hand it on, are down 20%, from 435 a day to 348, and still declining.
S&G Mitchell went from 17.9% to 60%+ EBITDA in 12 months. Same agency, same customers, same book of business. What changed was the operating model underneath.
How to test it without committing to anything
Pick one request type you can define, send a month of it, and then ask three questions of the data rather than of your impression.
What did a task cost and how long did it take, distribution rather than average, because the tail is where the problems are. How many came back for correction. And what your own team did with the hours that came off their desk, which is the only number that tells you whether the money was well spent.
If those answers are good, the next decision is which type to add, and you will be making it from your own book rather than from a proposal. Starting with certificates is the usual first move, and auditing where the service week goes is the usual way to pick the second.
Frequently Asked Questions
What is insurance agency back office support?
Completing the administrative work behind policy servicing: certificates, endorsements, renewal administration, new business intake, and claims support. The distinction that matters commercially is whether you buy it as capacity available to you, meaning a seat, or as work completed, meaning a task. The capacity page covers the transaction types.
Is per-task pricing cheaper than hiring?
Not automatically, and it depends on your volume and how well defined the work is. What per-task pricing reliably gives you that a seat does not is visibility: you can see what every task costs and which types are expensive, so the comparison stops being a guess. Cost per task is measured, and across the agencies we operate it comes down over time.
How is this different from an FTE or a dedicated resource?
A dedicated resource is a seat, so you carry the utilisation risk in both directions and you manage the person. Buying completed tasks moves that risk and that management to the other side. Your own staff stays the default, and this is extra capacity when you need it rather than a replacement for anyone.
What happens in a quiet month?
You send less work and it costs less, which is the practical difference from a seat, where the cost is the same whether the volume arrived or not. That is the same logic as moving service from a fixed cost to a variable one.
Which work should we send first?
A high-volume request type you can define clearly, usually certificates or endorsement processing. Work that is ambiguous inside your own agency cannot be priced per task until the ambiguity is resolved, so defining it is the prerequisite rather than an afterthought.
How do we know what we are being charged for?
Every action, human or AI, is logged with actor, timestamp, and reason, so the invoice and the operational record describe the same events. If a provider cannot reconstruct a specific request on a specific day, the per-task number is an assertion rather than a measurement.