Automating Service Requests in the Book of Business: How Insurance Brokers Handle Recurring Inquiries With AI

Tuesday morning, just after ten. A customer writes by email that she has moved and wants the new address recorded in three contracts. Two minutes later a commercial customer asks via WhatsApp why his premium on the commercial liability policy has gone up. At 10:20 someone calls and wants to change their bank details. Three channels, three requests, one back office. None of these service requests is technically difficult.

That is exactly where the problem lies. The effort in portfolio service does not come from the difficult cases, but from the volume of the easy ones. Every one of these requests costs collecting, assigning, looking up and typing before any professional decision is even made. Anyone who wants to automate service requests therefore starts not with the answer, but with everything that happens before the answer. Brokers rarely have a demand problem. They have a capacity problem.

In short: yes, recurring service requests in the book of business can be prepared automatically. An incoming message is recognized by case type, assigned to the customer and their contracts, enriched with the relevant context, and a draft reply is ready. What is automated is the preparation, not the decision. The broker reviews and approves. Around 20 recurring service process types are covered this way, from an address change to a premium adjustment.

What Portfolio Service Really Means Day to Day

Portfolio service is everything that happens after the contract is signed. Not sales, not advice, but the ongoing servicing of what is already in the book of business. In an office with 5 to 25 employees, it is the largest single block of work, and it breaks down into surprisingly few types.

Address changes and master data. A move, new bank details, a changed company address, a new contact person. Technically trivial, but every change affects several contracts and several insurers.

Premium adjustments and premium invoices. The customer gets a letter from the insurer, does not understand the increase and asks the broker. The answer requires the contract, the previous year's figure and the insurer's justification.

Cancellations and contract changes. A switch, an adjustment to the sum insured, an exclusion. These cases have deadlines, and deadlines are the reason they stay in your head until they are done. How this class of cases runs in a structured way we described in Automating contract changes.

Annual reports and standard information. "Which contracts do I have with you?", "Is that covered?", "Please send me the policy." Requests that are not advice, but information from your own system.

On top of that, these requests arrive over whatever channel the customer happens to have to hand. Anyone using WhatsApp in customer contact should know the data protection requirements for messenger communication in the brokerage: using it requires consent, and specially protected data under Article 9 GDPR demands additional safeguards.

How expensive this block is, we have measured in-house. We run a brokerage ourselves, with around 2,000 commercial customers and three to four people in the back office. In our own analysis, service requests tie up around 18.6 hours per month there, with pure email processing accounting for a further 15.7 hours. That is an observation from our operation, not an industry statistic. Portfolio service thus ties up exactly the capacity that is missing for portfolio growth and new business.

How Automating Service Requests Works

The decisive point is the order. It is not the answer that gets automated, but the path to it. In six steps it looks like this.

1. The request comes in over any channel. Email, WhatsApp, BiPRO documents, appointments and telephone all converge in one inbox. The customer keeps writing however they like. The back office still only looks in one place.

2. The case type is recognized. Is this an address change, a premium query, a cancellation or a policy inquiry? This classification happens on arrival, not on reading. In live demos, classification by process type reaches 99.8 percent accuracy. That systems in the insurance industry classify requests automatically and decide what runs by machine and what goes to a human is also described by the GDV in its overview of how the insurance industry is already using AI.

3. The customer and contracts are assigned. The request no longer hangs on a sender address, but on the customer and the affected contracts. Related cases are recognized and linked, so that a response to an ongoing case lands there and not as a new, context-free entry.

4. The context is loaded. A summary says in two sentences what it is about. History, documents and the state of the last contact are attached. Nobody reads the thread from the bottom up.

5. A draft reply is created. Composed from the request and the customer context, not from a boilerplate library. From the same communication, the case and the associated tasks arise at the same time.

6. The broker reviews and approves. This step does not fall away and is not meant to. The AI never sends messages automatically. Nothing goes out without approval. The broker confirms in seconds what has been prepared, or corrects it.

This changes the question at first opening. Before, it was: "Do I have time now to pull this together?" Now it is: "Is this correct, and do I approve it?" How this turns into a way of working in which every message is touched exactly once is set out in Inbox Zero in the brokerage.

Before and After: What Changes in the Back Office

The last line is the most telling. An address change or a policy inquiry classically takes 10 to 25 minutes, depending on the number of affected contracts and the search time in the management program. Prepared in structured form, it is 1 to 2 minutes, because the assignment, the context and the draft are already there when you open the request.

Over the day this adds up. In our own operation and with design partners, even in the introduction phase a visible 1 to 2 hours per employee per day are freed up. Up to 3 hours is the upper limit of what we have observed, not a promise. How much it becomes for you depends on the share of recurring cases in your book of business.

A look at the alternative shows why that matters. When capacity is short, the reflex is an additional back-office position. Except that is hard to fill: according to current figures on the skills shortage in the back office, filling an open position takes 63 days on average and requires around 32 applications. Two months of lead time plus onboarding is no answer to a book of business that is growing today.

What Matters When Automating Service Requests

Not every automation holds up. Four points decide whether it lasts in daily practice.

Structure comes before automation. An unstructured process is not made better by automation, just faster and wrong. Only once case types, responsibilities and states are clear is the step onto it worthwhile. The rollout therefore begins with one channel and one case type.

Integration into the management system is mandatory, not optional. A solution that stands next to the broker management system creates a second truth. Modus is integrated into the management system and Outlook and does not replace them, with concrete connections to AMEISE and VEMA. Modus is pool-independent in doing so, so its use is not coupled to any pool dependency. Anyone wanting to place the provider landscape in a broader context will find the overview in AI software for insurance brokers.

Traceability is not an add-on feature. Every step is documented on a timeline: what came in, what the system prepared, who approved what and when. That is the difference between a case you can explain and one where you have to hope. On top of that comes data protection: you must name AI tools in your privacy policy and review the data processing agreement including sub-processors. The data protection requirements for AI in the brokerage are an ongoing task, not a one-off check.

Approval before sending remains the anchor. Also from a regulatory standpoint: the transparency obligations of the EU AI Act require, under Article 50, that customers can recognize when content was generated with AI, and classify the broker as a deployer with their own training obligations. A process in which a human reviews and approves is therefore not only operationally sensible, but also the clean control point.

On the cost question that comes up here regularly: the meaningful calculation is not the list price, but the time that comes back per employee per day, and what you do with it. You work that out against your own book of business, in a session with your figures.

Frequently Asked Questions

Which service requests can be automated?

Around 20 recurring service process types can be prepared: address changes, changes to payment data, cancellations, annual reports, premium adjustments and standard information on existing policies. What they have in common is that they follow a fixed pattern and their answer arises from data already in the system. Advice-intensive cases remain untouched. There, automation only creates the time to handle them.

How reliably does the AI recognize the case type?

In live demos, classification by process type reaches 99.8 percent accuracy. More important than the figure, though, is what happens with a misclassification. Since nothing is sent without approval, a wrong assignment is not damage but a two-second correction. The classification decides the preparation, not the outcome. The broker's review step always stays in between.

Does the AI send answers automatically?

No. The AI never sends messages automatically. Nothing goes out without approval. Drafts are prepared and placed in the queue, the broker reviews and approves or adjusts. This rule applies to all case types. What is end-to-end is the system connection, that is, the path without a media break between channel, case and management program. What is end-to-end is not the sending.

Is it worthwhile even for small teams?

Especially there. In an office with 5 to 25 employees, every saved hour hits the bottleneck directly, because no reserve steps in. Two things are decisive: the solution must fit cleanly into the existing broker management system and into Outlook, and it must be usable without project effort. One channel and one case type are enough to start.

What does automating service requests cost?

Prices depend on team size and scope and therefore belong in a conversation, not a blog article. The more meaningful calculation you run against the other side anyway: how many hours per month do service requests tie up in your back office today, and what would 1 to 2 recovered hours per employee per day be worth? That figure can be worked out concretely against your own book of business, best done together in a demo.

Who is liable if the AI makes a mistake?

The deploying company. An AI has no legal personality of its own, so responsibility stays with the broker. The question of who is liable for AI errors in the brokerage is sharpened further by the EU Product Liability Directive, which from the end of 2026 explicitly classifies software as a product. That is exactly why the approval principle and a seamless timeline are not a convenience but the core of the safeguard.

Conclusion

Service requests in the book of business are not a technical problem. They are a volume problem, and volume problems are solved through structure, not through more staff. Anyone who prepares the 20 recurring case types cleanly once gains capacity without touching the quality of service.

Modus is built as an operational level on top of the broker management system. All channels converge in one inbox, the case type is recognized, the customer and contracts are attached, cases and tasks arise automatically, the draft reply is ready. Approval comes from you. This shifts the role in the back office: from doing the work yourself to reviewing and approving it.

The book of business keeps growing. The only question is whether it grows with headcount or with structure.