Digital channels are in place, but policy servicing still breaks down? See how to maintain continuity between self-service and the contact center

Key takeaways:

• Self-service adoption alone does not tell you whether policy servicing is efficient. It is also worth looking at how many cases end up with an agent and how much work it takes to take them over.
• In insurance, many of the biggest problems arise at the intersection of channels, data, and processes. This is where additional work appears that the customer never sees but the organization still pays for.
• Service continuity can be improved without replacing the core system. One option is a layer that connects existing systems around a shared case status available in the app, customer portal, agent channel, and contact center.

When does a phone call start adding cost?

EIOPA highlights an important characteristic of insurance: unlike banking, customers generally have little reason to interact with their insurer on a regular basis. Contact tends to happen at specific moments, such as policy renewal or when filing a claim. At the same time, phone, email, and in-person service remain among the most popular ways for retail customers to contact insurers.¹

There are also service needs that do not follow an annual cycle, such as updating personal information, adjusting coverage, or reconciling a premium payment. In many of these situations, the phone remains a convenient and frequently used channel even as insurers continue to expand their apps and self-service capabilities.

Some calls, however, are driven by more than customer preference. In a Capgemini study, life insurance customers were asked what made post-purchase servicing difficult. Alongside long wait times to speak with an agent, respondents pointed to the inability to make policy changes on their own. This was an issue for 20% of individual customers and 28% of group customers.² In these cases, the phone becomes a workaround for a process that could not be completed online.

For that reason, moving from a digital channel to the contact center should not automatically be treated as a failure of self-service. It is more useful to understand why the customer decided to call — for example, whether they had difficulty with the app or website — and, above all, what happens to the case after the channel changes. If the agent can see its status, previous actions, and information the customer has already provided, the process can continue without creating additional work. Hidden costs emerge when the agent has to reconstruct the context, verify information again, or piece together the history of the case across several systems.

Why do organizations lose case context across channels?

For years, expanding digital service primarily meant launching additional customer touchpoints: apps, customer portals, online forms, and chatbots. In many organizations, each new channel was added as another layer on top of the existing architecture and processes. The customer-facing experience changed, but operationally, work often remained much more fragmented.

In practice, an agent may have access to all the information needed to handle a case, but that information may be spread across several systems:

• customer data and interaction history in the CRM,
• policy information in the policy administration system,
• payments in a separate system,
• the status of a service request or policy change in a workflow tool,
• documents and correspondence in additional repositories.

What happens when one case spans multiple systems?

Consider a single service request. A customer submits it through the app on Monday, and the case enters a queue in the workflow system. On Tuesday, the customer calls because the portal still shows the old information. The agent checks the CRM, policy administration system, and workflow tool. The request is waiting for validation, but the agent cannot tell whether this is a normal stage of the process or whether the case has stalled, so a second case is opened. By Wednesday, the operations team has two requests relating to the same policy and needs to determine which one is current.

The delay comes from moving between systems and from the lack of a single place that shows the current case status. As a result, the employee has to gather the information manually and determine what has already happened and what should happen next.

This is why digital service maturity is difficult to assess based solely on the number of channels an organization has launched. A much better indicator is its ability to carry a single case across different channels without losing its history, status, or context.

How can insurers improve information flow across existing digital channels?

Insurers have already spent years investing in portals, apps, CRMs, and customer service tools, so it can be difficult to justify another major transformation simply to improve the flow of cases between channels. What is needed instead is a layer that allows existing solutions to work together as part of a single service process.

In our insurance platform, Altkom Insurance Suite, this role is performed by the Policy Center module. We designed it as a shared access point for the data and processes involved in policy servicing, from customer and policy information to payments, documents, activity history, and changes made throughout the policy lifecycle.

Creating a shared access point is not enough, however, if the data flowing between systems is incomplete, outdated, or does not clearly indicate what is happening with the case. Even where such a hub is already in place, it is worth starting by identifying what information each channel and team actually needs to continue the process without having to reconstruct its context.

• Which system is the authoritative source for the current case status?
• Is it clear when the data was last updated and which action has already been completed?
• Can the next employee see not only the outcome so far, but also what is still required to complete the process?

This type of review helps determine whether the information available in the systems actually enables the employee or the next channel to understand the case and take the next step.

How does Policy Center connect data and processes?

Policy Center supports the policy lifecycle and connects it with information about the customer, policy changes, documents, and billing. Events that occur during servicing can trigger the appropriate operations and tasks, allowing subsequent stages of the process to use the same context regardless of the channel the customer uses.

At the same time, Policy Center does not need to replace every system already operating within the insurer. Altkom Insurance Suite uses a microservices architecture and integrates with its surrounding environment through APIs, allowing the module to connect with existing channels, core systems, and financial systems. This makes it possible to improve servicing incrementally and build on previous technology investments instead of starting with a replacement of the entire IT environment.

How does shared context across channels reduce servicing costs?

Policy Center is one way to address the problem, but depending on the insurer’s architecture, a custom-built integration or service layer can serve a similar purpose. At a minimum, such a layer should connect data from existing systems, maintain the current case status, and make it available to every service channel.

The goal, then, is not necessarily to implement a specific product. It is to create a place where the information needed to manage a case remains available regardless of where the customer first initiated contact.

What does this change?

For the contact center: less time spent reconstructing customer history

Previously, a customer who could not see the status of a change in the portal would call the contact center. The agent would check the policy, interaction history, and service request in several places, sometimes asking the customer to provide information again or transferring the case to another team. Once the process is connected, the agent can immediately see what the customer has already done, where the case stands, and what is still missing. Instead of reconstructing the history, the agent can continue the process.

For operations teams: less manual work and fewer duplicate cases

The impact on operations is similar. Information that previously had to be re-entered or reverified after a channel change can be reused in the next stage of the same process. This reduces manual activities, handoffs between teams, and cases that require additional clarification.

For customers: less repetition

Customers feel the difference as well. If they can continue a case regardless of channel, they do not need to reconstruct its history, explain the same issue again, or provide the same information multiple times. The experience becomes smoother, and moving from the app to the contact center no longer means starting the process over.

For IT: simpler development of new channels

The impact is also visible on the IT side. Each new channel no longer needs to build its own integrations and policy servicing logic from scratch. Instead, it can use a shared data and process layer, reducing point-to-point connections and simplifying future development.

What comes next for policy servicing across channels?

Consistent policy servicing depends less on the number of available channels than on whether they all work with the same case context. When data, activity history, and process status remain available regardless of the point of contact, further investment in digital service can genuinely reduce operational work instead of simply shifting it between teams.