Skip to content
TestimonialsGet a Free Blueprint

Case study · Insurance

Renewals that chase themselves

A US insurance provider was working renewals from spreadsheets exported each Monday. We unified policy, claim and contact data in Dynamics 365 CRM so renewals surface on their own and reporting comes out of the system rather than out of a weekly export.

Start a project like thisSee more of our work

Engagement · Implementation & automation

CRM and reporting automation over an existing policy system.

Industry
Insurance
Solution
CRM & reporting automation
Platform
Dynamics 365 CRM
Engagement model
Dedicated product team
Integration
Policy administration system
Scope
Implementation, automation, reporting
Users
Agents, service, management
Region
United States

Outcomes

What changed once the data was in one place

Insurance retention is won or lost in the weeks before a renewal date. Everything here is about not missing that window.

  • 40% More renewals worked before expiry

    Renewals surface on an agent's queue by date and value rather than appearing in a spreadsheet somebody had to open, sort and distribute.

    Measured across renewal cycles after go-live

  • 90% Less time producing management reports

    Reporting runs against live CRM data instead of a Monday export reconciled by hand against the policy system.

    Measured against the previous weekly reporting cycle

  • 1 View of a policyholder

    Policies, claims, payments and every contact in one record, so an agent taking a call is not assembling the picture from three systems.

    By design: policy system synchronised into CRM

Context

The situation before the implementation

Why insurance teams end up working from exports.

The business

A US insurance provider selling and servicing personal and commercial lines through its own agents.

The starting point

Policies lived in a policy administration system, contacts in a CRM nobody trusted, and the working list was a spreadsheet exported each Monday.

The trigger

A renewal missed by a week is usually a renewal lost. Working from a weekly snapshot meant the team was always operating on stale information.

What they wanted

One record per policyholder, renewals that appear when they are due, and reporting that does not require anyone to build it.

Constraints

The policy administration system is the system of record and is not being replaced · agents work by phone and will not tolerate extra clicks · reporting has to reconcile to the policy system exactly · US insurance data handling requirements.

System

What it runs at today

The implementation as it runs today.

  • 1 Policyholder record

    Policies, claims, payments and contacts together

  • 2 Systems synchronised

    Policy administration and CRM, one direction of truth

  • 4 Automated renewal touchpoints

    Staged by days to expiry

  • 0 Weekly exports in the working process

    Queues come from live data

The engineering problem

Four problems with CRM over a policy system

The policy system stays. The CRM has to make it usable without pretending to replace it.

  1. Two systems will disagree unless one is the truth

    A CRM that lets agents edit policy data creates two versions of a policy and an argument about which is right. Insurance cannot tolerate that ambiguity.

    What we did

    The policy administration system stays the system of record. CRM holds a synchronised copy that is read-only for policy fields, and writes back only through defined actions.

  2. Renewals are a date problem, not a list problem

    A spreadsheet of expiring policies is a snapshot. By Wednesday it is wrong, and nobody knows which rows have been worked.

    What we did

    Renewals modelled as records with their own state, surfacing on agent queues by days-to-expiry and value, with the work recorded against them.

  3. Agents will not accept extra clicks

    A phone-based team measures a system by whether it slows down a call. Anything that adds steps gets bypassed and the data rots.

    What we did

    The policyholder view assembled on one screen, with logging designed around what an agent does anyway rather than asking for separate data entry.

  4. Management reporting has to tie to the policy system

    A management report that does not reconcile to the system of record is worse than no report — it creates decisions based on a number finance will later contradict.

    What we did

    Reporting built on the synchronised data with a reconciliation check against the policy system, so a discrepancy surfaces as an alert rather than as a surprise in a board meeting.

Architecture

How it fits together

Simplified — the shape of the system rather than every service in it.

  1. Policy system

    • System of record
    • Policies & claims
    • Premium data

    Unchanged. It remains authoritative for everything policy-related.

  2. Synchronisation

    • Scheduled sync
    • Change detection
    • Reconciliation checks

    A one-way flow into CRM for policy data, with defined write-back actions for the few things agents legitimately change.

  3. CRM

    • Policyholder record
    • Renewal pipeline
    • Activity logging

    Dynamics 365 holding the relationship: contacts, conversations, renewals and service history.

  4. Reporting

    • Live dashboards
    • Management reports
    • Reconciliation alerts

    Built on CRM data, checked against the policy system so the numbers can be defended.

The decision that keeps this stable is that CRM never becomes a second system of record. Policy data flows one way, and the exceptions are explicit actions rather than an editable field.

Solutions

What we implemented

A relationship layer over an untouched policy system.

  • Policyholder record

    Policies, claims, payments and contact history assembled on one screen.

  • Renewal pipeline

    Renewals as records with state, surfaced by date and value.

  • Automated touchpoints

    Staged communications at defined points before expiry.

  • Synchronisation

    One-way policy sync with change detection and defined write-back.

  • Reporting

    Live dashboards replacing the weekly export.

  • Reconciliation

    Nightly comparison against the policy system, with alerting.

Key capabilities

What it does day to day

Six capabilities across the policy lifecycle.

CapabilityRunsRefreshWhat it does
Policyholder view Agent Real time Policies, claims, payments and contact history on one screen
Renewal pipeline Automatic Daily Renewals surfaced by days-to-expiry and value, with worked state tracked
Automated touchpoints Scheduled Per stage Staged renewal communications at defined points before expiry
Claims visibility Synchronised Continuous Claim status visible to the agent without opening the policy system
Management reporting Scheduled Daily Live dashboards and reports built on synchronised data
Reconciliation Automatic Nightly CRM checked against the policy system, discrepancies raised as alerts

Integrations

How the moving parts plug in

Policy data flows one way; the relationship lives in CRM.

Policy administration

  • PoliciesThe system of record
  • ClaimsStatus and history
  • PremiumsBilling position

Synchronisation layer

  • Change detectionOnly what moved
  • Defined write-backExplicit actions only
  • ReconciliationNightly, with alerts

CRM & reporting

  • Policyholder record
  • Renewal pipeline
  • Dashboards

Because reconciliation runs nightly and raises alerts, a synchronisation problem is found by the system rather than by an agent quoting a wrong premium to a customer.

Security & data

What protects policyholder data

Insurance records carry financial and often health-adjacent information, under US handling requirements.

  • Role-based access

    Agents see their book; service and management see what their roles require, enforced by the platform.

  • Read-only policy fields

    Policy data cannot be edited in CRM, which removes a whole class of data-integrity and compliance risk.

  • Activity auditing

    Access to a policyholder record is recorded, so the provider can answer who viewed what.

  • Reconciliation as a control

    A nightly check that CRM still matches the system of record, treated as a control rather than a report.

The brief

A CRM over a policy system must not become a second policy system

The temptation on every insurance CRM project is to let agents edit policy data because it is convenient. That produces two sources of truth, and within a year nobody can say which is correct.

We held a hard line: the policy administration system is authoritative, CRM owns the relationship, and the boundary between them is explicit.

  • One system of record, never two
  • Renewals as tracked records, not spreadsheet rows
  • Reporting that reconciles nightly
  • No extra clicks in an agent's call

What the implementation had to respect

  • 01A policy administration system that is not being replaced
  • 02Agents working by phone, measured on call volume
  • 03Reporting that must tie exactly to the system of record
  • 04US insurance data handling requirements

Process

We drew the system boundary first

Every subsequent argument on a project like this traces back to whether that boundary was agreed at the start.

  1. Stage 1

    Defining the boundary

    Agreeing exactly which data CRM owns, which it mirrors, and the short list of actions permitted to write back.

  2. Stage 2

    Synchronisation

    Change-detection sync built and run in parallel for several weeks before anyone relied on it.

  3. Stage 3

    Renewal model

    Renewals designed as tracked records with state, replacing the export in one cycle rather than gradually.

  4. Stage 4

    Agent rollout

    A small group of agents first, with call-handling time measured to confirm the system was not slowing them down.

  5. Stage 5

    Reporting parity

    New reports run against a historical period and checked against previously published management figures.

Technology

Dynamics 365 alongside the policy system

Nothing about the policy administration system changed, which is what made this deliverable in one quarter.

CRM

  • Dynamics 365 CRM
  • Custom entities
  • Business process flows

Integration

  • Scheduled sync
  • Change detection
  • Write-back actions

Automation

  • Renewal staging
  • Communication triggers
  • Queue assignment

Reporting

  • Dashboards
  • Management reports
  • Reconciliation alerts

Business impact

What changed for the provider

Three things the business noticed.

  • Retention worked properly

    Renewals surface when they are due, so the window is used rather than discovered after it closed.

  • Monday mornings returned

    The export-and-distribute ritual disappeared along with the spreadsheet.

  • Numbers nobody argues with

    Reporting that reconciles to the policy system ends the meeting-time debate about whose figure is right.

The result

Renewals worked on time, from one record

Agents see a policyholder in one view, renewals surface when they are due, and management reporting comes out of the system already reconciled to the policy administration system.

The weekly export that used to define the working rhythm is gone.

  • One policyholder record across policies, claims and contacts
  • Renewals as tracked records surfaced by date and value
  • Reporting reconciled nightly to the system of record
  • Policy administration system untouched
Talk about a project like this

What we would repeat on an insurance CRM

  • 01Agree the system boundary before building anything
  • 02Keep policy fields read-only in CRM, without exception
  • 03Run the sync in parallel before anyone depends on it
  • 04Treat reconciliation as a control, not a report

Verified reviews

What clients say about our Dynamics work

Verified reviews from clients of ours on similar work, published on Clutch. They are not from this project.

5.0 27 verified reviews
See All Testimonials Read All Reviews on Clutch

Related

Services we used on this project

Free discovery call

Have an idea? Let's turn it into AI-powered software.

Book a free discovery call with our experts. Share your idea and we will help you shape the scope, timeline and budget, under NDA.

  • Free consultation
  • NDA before we talk
  • Transparent estimate
Book a Discovery Call info@silverscintilla.com