Česká pojišťovna: claims and customer data, unified.

The challenge

Claims are where an insurer's promises get tested — and where its systems show their age. Claims engines are optimised for adjudication: reserves, coverage checks, payments. They were never designed for communication, and they sit on top of customer data that accumulates fragmentation with every product launched and every migration survived. The same person can exist as several unconnected records across motor, property and life lines; a claims handler sees one sliver of the relationship, the contact centre sees another.

The cost is practical. Handlers work without context and ask customers to repeat themselves. Follow-ups land in the wrong place. Duplicate identities make consent management and GDPR obligations harder than they should be, and they blunt any attempt to spot patterns across lines of business. None of this is caused by one bad system — it is caused by decades of individually reasonable decisions that were never reconciled.

The published scope of our work with Česká pojišťovna names the target directly: claims and customer data unified across the platform. As with all our case studies, the specifics of systems, volumes and sequencing stay out of public material; the pattern is what we can usefully show here.

Our approach

Discovery for a unification engagement starts with data reality, not process diagrams — the same ground an architecture review covers: where customer identity actually lives, which attributes each system considers authoritative, and how claims flow between intake, adjudication and payment. We are explicit about the boundary from the start. Salesforce does not replace a claims engine. It unifies what surrounds the engine: intake, tracking, tasking, communication and the single view of the customer.

From there, a phased plan — the Discover, Design, Build, Run method described on our services page. Unification programmes fail most often by attempting everything at once, so we sequence: establish the unified customer record first, prove one claims journey on the platform end to end, then extend line by line. An MVP early, steady releases after, built by the senior engineers who scoped the work.

Architecture

Every insurer's estate differs, so what follows is pattern-level — the shape of the build rather than a client-specific diagram.

One customer, one record

The unified view rests on identity resolution: matching rules that decide when two records are the same person, survivorship rules that decide which attributes win, and a golden record that downstream processes can trust. Consent and preference data are modelled alongside identity from day one, because a unified record that mishandles consent is a liability, not an asset. This is the same class of problem Salesforce now addresses natively with Data Cloud, and the pattern transfers directly.

Claims on the platform, adjudication behind it

Intake, status tracking and customer communication run on Salesforce; the claims engine keeps doing the adjudication it was built for. Status changes flow as events from the back office to the platform, so handlers and channels always show the current state without polling. Historical claims arrive by batch with reconciliation checks, so the platform's history can be trusted from the first day of operation.

The integration seam

Between the two sits an explicit integration seam: idempotent operations, retries with backoff, and a fallout queue for anything a human must inspect. Failures become visible work items rather than silent data loss. The full menu of trade-offs — events versus polling, replication versus read-through — is laid out in our integration patterns article.

Data quality as an ongoing process

Unification is not a one-time migration. New records keep arriving from every channel, and each arrival is a chance to fragment again. The pattern therefore includes matching at the point of entry — new contacts are resolved against the golden record before they create a duplicate — plus scheduled quality checks that surface drift instead of letting it accumulate. A unified view that is only accurate on migration day is not unified; it is a snapshot.

Outcome

No performance metrics are published for this engagement, and we do not invent numbers for marketing pages. What we can state is the published result: claims and customer data unified across the platform.

Qualitatively, the pattern changes how the organisation operates. Every interaction has a single customer record to attach to, so context stops being something handlers reconstruct by hand. Claims status reads the same in every channel. And consent lives in one place instead of several, which makes regulatory obligations something the data model supports rather than fights.

Related reading