Two platforms, one customer, and a seam nobody owns.
Service Cloud implementation, Workday HCM kickoffs and change-vision workshops across insurance operations. The pattern that repeats: a service platform and a core system each doing their job, with the customer experience and the data truth both living in the gap between them. Walk the five decisions, find your seat, then run the two-minute check.
Five calls that decide an insurance program
Made during design, felt by service teams and customers within weeks of go-live. Pick a decision.
Service, policy and billing systems each hold a version of the customer, and each is authoritative for something.
Name the master for each attribute of the customer record, and write it down before design rather than reconciling later.
Without a named master per attribute, the systems drift and the service team learns which one to trust for what. That knowledge is tribal, it does not survive turnover, and it eventually produces a customer conversation where two representatives give two answers. The fix afterwards is a data program; the fix beforehand is a decision.
For each customer attribute, which system is master, and where is that documented?
A change vision workshop happens early, produces good material, and then the program moves to build and the vision stops being referenced.
Make the change vision an operating document that design decisions are tested against, not a launch artifact.
Service platform adoption depends on whether the new way is faster for the person handling the call. If it is not, the workaround appears immediately and the promised benefit never arrives, whatever the training completion rate says. The vision is only useful if somebody has authority to reject a design decision that contradicts it.
Which design decisions have been changed because they contradicted the change vision?
Both platforms need work, and the temptation is to do them together for a single disruption and a single business case.
Sequence deliberately, and if both land in the same window, price what the concurrency costs in decision latency and shared people.
The same handful of people who understand how policy, billing and service fit together are named on both programs. They do not scale. Concurrency is survivable when somebody has priced it and staffed around it, and corrosive when it is assumed to be free.
Who is named on both programs, and what have we done about it?
Customer, policy and claims history carry years of accumulated variation, and conversion gets scoped by record count.
Baseline data quality before design locks and scope remediation as work with an owner.
Migrated poor data becomes visible in the service platform immediately, because that is where a person looks a customer up while they are on the phone. Unlike a ledger error, this one has an audience, and it damages confidence in the platform in the first week.
What is our measured customer and policy data quality today?
The support model is designed for corporate hours and standard severity, while the service floor runs to customer expectations.
Design support around the service floor and get the day-after-hypercare staffing in writing before go-live.
Ticket volume typically peaks after the senior people roll off. If a service representative cannot get an answer during a call, they invent one, and the invented answer becomes local practice. That is how a platform that tested well produces inconsistent customer outcomes within a quarter.
What does support look like the day after hypercare ends, in writing?
What those five mean for the chair you sit in
Insurance programs get judged on customer outcomes and on control. Each seat's exposure, the early sign, and the question worth asking this quarter.
Adoption is decided on the first call
If the new path is slower than the old one for someone with a customer waiting, the workaround wins immediately. The other exposure is the customer record: without a named master per attribute, two representatives can give two answers, and that reaches the customer rather than a report.
The change vision has not caused a single design decision to change.
Which design decisions were rejected because they contradicted the change vision?
Two programs, one bench, one business case
Concurrent service and core work shares the small group of people who understand how the whole thing fits together. Priced, that is manageable. Assumed free, it shows up as decision latency and slipped design sign-offs, which are the hardest overruns to explain because nothing visibly failed.
No one has listed the people named on both programs.
What does the concurrency of these two programs cost us in decision latency?
Service roles change more than the org chart shows
A service platform change alters what representatives do hour to hour, which affects role definitions, performance measures and training obligations. Treated as a systems rollout with a training plan attached, it produces a workforce measured against expectations the new system does not support.
Role definitions and performance measures have not been revisited alongside the platform change.
Have we updated how service roles are measured to match the new way of working?
Four failure points, ranked by what I see
Illustrative weighting from practitioner experience, not a benchmark. The ranking is the argument, not the heights.
Only the last one looks like a defect. The first three look like normal friction, which is exactly why they survive hypercare.
Five questions worth more than a readiness assessment
Answerable from memory, scored on this page, nothing captured and nothing emailed.
These five are the start of the instrument. A full review also covers integration design, role and performance redesign, migration sequencing and hypercare exit criteria. Or skip the tooling and book the program review.
Running service and core programs at once?
Pre-SOW, mid-build, or stabilizing after a rough service go-live. I sell no software and staff no builds, so these questions get asked out loud. Tell me where the program is and I will tell you what I see.