NN: policy servicing and customer journeys on Salesforce.

The challenge

Insurance servicing has a structural problem. Policies live in policy administration systems that are excellent at what they were built for — premium calculation, policy lifecycle, regulatory reporting — and poor at what customers now judge an insurer on: fast, coherent service. A single request can touch an address change, a beneficiary update, a coverage question and a payment issue, and each of those may live in a different back-office system with its own screens, its own data shapes and its own queue.

For service teams the result is swivel-chair work: re-keying data between applications, chasing status by phone and holding the process together from memory. For customers it is journeys that stall — a request submitted in one channel disappears into another, and nothing is visible until a letter arrives. And because insurance is a regulated industry, none of this can be fixed by casually copying data between systems; access rules, auditability and retention obligations follow the data wherever it goes.

The engagement with NN sat squarely in this territory. The published scope is deliberately short: policy servicing and customer journeys delivered on Salesforce. The specifics — which systems, which lines of business, which volumes — are the kind of detail we cover in reference calls rather than on a marketing page.

Our approach

We ran this the way we run every build: Discover, Design, Build, Run — the working method described on our services page. Discovery maps processes, data and systems before anyone touches an object, and it is where we say plainly what Salesforce should and should not own in an insurance stack. Policy administration systems remain the system of record. Salesforce becomes the system of engagement: the place where servicing work is queued, guided and tracked, and where the customer journey actually lives. Getting that boundary wrong is the most common failure mode we see in insurance CRM programmes, so we settle it on paper first.

Design turns that boundary into a phased plan sized to budget: an early MVP followed by steady releases, rather than a year-long big bang. Servicing suits this well — start with the highest-volume request types, prove the journey end to end, then widen coverage release by release.

Build and Run follow the principle our company is organised around: the senior engineers who scope the work are the ones who build it and stay to run it. Config, code and integrations ship in tested increments, with the client in the loop every sprint — never a black box.

Architecture

Every insurer's estate is different, so this section stays at pattern level — the shape of the architecture rather than a client-specific diagram.

Salesforce as the engagement layer

Servicing processes run on the platform: intake across channels, guided steps for agents, and customer journeys built as resumable processes rather than one-shot forms. Status is a first-class citizen — every request carries a visible state that both the service team and customer-facing channels can read, so nobody has to phone another department to find out where things stand.

Integration, not replication

The policy master is read live through a service layer wherever freshness matters, instead of being replicated wholesale into CRM. Changes that must flow back travel asynchronously, with idempotent operations, retries and an explicit fallout queue for the cases that need a human. The synchronised footprint stays deliberately small: only the fields servicing genuinely needs cross the boundary, which keeps the compliance surface small too. The trade-offs behind these choices — events versus polling, replication versus read-through — are the subject of our integration patterns article and our integration practice.

What stays out of Salesforce

Premium recalculation, actuarial logic and mass document production stay in the core or in specialist services. Salesforce orchestrates them; it does not re-implement them. That restraint — the same discipline we argue for in when to write Apex — is what keeps an engagement layer maintainable years after go-live.

Outcome

We publish no performance metrics for this engagement, so we will not invent any here. What we can state is the shape of what was delivered, as published: policy servicing and customer journeys running on Salesforce.

Qualitatively, this pattern gives an insurer three things. Service teams work one queue in one environment instead of many. Customers get journeys whose status is visible rather than opaque. And the integration boundary isolates Salesforce from change in the core — policy systems can evolve without the servicing front end being rebuilt around them.

Related reading