Reframing a Mandated CRM Migration Around How Agents Actually Work

The business needed agents to move to a new CRM, but the planned experience did not reflect how they ran their offices or served customers. I introduced direct agent evidence into the migration strategy and translated it into a household-centered information model that stakeholders and users could validate.

Role

Lead Experience Architect

Org

National Home & Auto Insurance Provider

Timeline

Dec 2020 – Feb 2022

Reframing a single-workflow CRM into two platforms that agents actually needed.

Summary

Stage	Detail
Problem	A large insurer was modernizing how agents managed customer relationships, but the initial platform direction treated their work as a single workflow. Research revealed two distinct needs: serving customers during conversations and managing day-to-day agency operations. Without a clearer structure, the new system risked slowing agents down and limiting adoption.
Action	Led discovery and experience strategy for the enterprise CRM modernization. Secured and helped facilitate multi-day workshops with agents, synthesized the findings, and translated them into a customer-data hierarchy, prioritized workflows, and platform concepts showing what information agents needed at each point in a customer conversation.
Result	Established an evidence-based direction for a platform supporting both customer service and agency operations. The work gave product and business teams a shared understanding of agent needs, informed the system's information architecture and experience priorities, and created a clearer foundation for service, engagement, and adoption.

Impact

Impact	Detail
Two Platforms, Not One	Reframed a single workflow into two distinct needs, customer conversations and agency operations, sharpening product and design decisions.
Shared Understanding	Gave product and business teams a common, evidence-based view of agent needs across the platform.
Clear Foundation	Informed the system's information architecture and experience priorities for faster service, stronger agent engagement, and adoption.

Strategic Reframe: The initial direction treated agent work as a single workflow. Research reframed it into two distinct needs, customer conversations and agency operations, giving product teams a clearer path to prioritization and design.

Executive Snapshot

Challenge

The business needed independent agents and their office teams to move from a legacy CRM to a new enterprise platform. But the proposed experience was being shaped by internal feature owners and product requirements that had not been tested against the workflows of the people expected to use it.

Strategic Insight

Agent resistance was not simply resistance to change. The planned platform organized information around internal products and individual policies, while agents managed relationships at the household level. The migration would remain difficult to justify until the product reflected that difference.

Strategic Response

I introduced direct agent research into the product-definition process and translated the findings into a Hierarchy of Data framework that reorganized customer information around households, service needs, and life events.

Validated Outcome

The household-centered direction was validated by agents and stakeholders and gained support over a competing lift-and-shift approach. I transitioned off the project before implementation, so post-launch adoption and performance were not outcomes I directly observed.

Role

Design strategist and information architect leading the agent-facing experience within a multi-team enterprise CRM modernization.

This account was reconstructed from project records, prior work product, and direct project experience. Company, platform, team, and participant names have been anonymized. Because I transitioned off the project before implementation, I distinguish validated design outcomes from results I directly observed after launch.

Strategic Signals

Strategic Signal	What This Case Demonstrates
Strategic Problem	De-risk a mandated CRM migration that had been planned without direct agent input.
My Intervention	Reframed the platform around real agent workflows and household relationships.
Decision Changed	Shifted stakeholder support away from replicating the legacy experience toward a new information model.
Evidence Used	Agent workshops, usability testing, workflow research, and competing-concept evaluation.
Enterprise Constraint	The solution had to work within the organization's existing CRM investment.
Result Observed	Stakeholder and end-user validation of the household-centered direction before implementation.

What Changed: From Legacy Structure to a Validated Product Direction

Dimension	Before	Validated Direction
Agent Experience	Agents worked from fragmented, single-policy views. Understanding a household's full relationship required moving across products and records.	A household-centered experience brought relevant products, relationships, and life events into one view, giving agents a clearer basis for customer conversations.
Product Strategy	The migration was framed primarily as moving agents onto a replacement platform while preserving much of the legacy structure.	The strategy shifted toward giving agents a product experience that is meaningfully better aligned with how they manage customers and their businesses.
Information Model	Information followed the company's product structure: one policy and one product line at a time.	The Hierarchy of Data framework prioritized information according to the agent's current need, household context, and service scenario.
Decision Process	Requirements were sourced from internal product owners without direct validation from agents.	Direct agent research became the evidence used to evaluate the migration direction and compare competing concepts.
Organizational Alignment	Teams held competing views of what constituted a user-centered solution.	Agent evidence gave stakeholders a stronger basis for supporting the household-centered direction over a lift-and-shift approach.

Skimmer Takeaway

Migration trust doesn't start with the interface. It starts with whether the people being asked to move can see themselves in what they're being asked to move to.

Deep Dive

To go deep and learn more about my thinking, judgment, and reasoning expressed on this engagement, continue reading and dive deep.

Est. Reading: 8-12 Minutes

In This Deep Dive · 10 Sections

01My Scope Within a Multi-Team Modernization
02Why a Misaligned Migration Created Business Risk
03The Problem as Initially Understood: The Specifications Needed More Detail
04The Actual Problem: The Specifications Came From the Wrong Source
05Changing the Source of Truth Behind the Product
06Reorganizing the CRM Around the Household
07From Insight to Action in the Household View
08Using Agent Evidence to Challenge a Lift-and-Shift Direction
09Designing Within the Existing CRM Investment
10What the Work Changed and What Remained Unmeasured

My Scope Within a Multi-Team Modernization

The engagement ran roughly two years, ending when I transitioned to a different role, not when the work concluded. Multiple teams were involved: my own design track, at least one peer design team pursuing a different technical approach, product management, and the feature product owners feeding them specs. My scope was the customer-facing side of the modernization specifically, the household data and service experience agents used day to day, not the platform's full technical build, and not a separate, related back-office tool the business also had in flight for agents' own business management (a distinct effort, outside this case study's scope).

Worth stating plainly: this account covers what happened up to that departure. It is not a launched-and-measured story, and it doesn't pretend to be one.

Why a Misaligned Migration Created Business Risk

The business case for the migration was consolidation. Customer data lived across several systems, and the business wanted to bring it into one platform, retire older systems, and cut the cost of maintaining several at once. Moving onto the new CRM turned out to be more than a data transfer. It exposed the workarounds agents and their office teams had built to get their work done in the current system, and those workarounds were signals of needs the new platform would have to meet.

Independent agency office workers aren't a captive audience. They run their own businesses, and the CRM is the tool they use to serve their own customers. Force a migration onto a system that doesn't reflect how they actually work, and there are exactly two outcomes: the rollout stalls, or agents route around it in ways that eventually reach the customers those agents serve. Neither is acceptable when the thing being modernized is the tool people use to manage another person's insurance, their bills, and the life events attached to both.

That's the stake that made this more than an internal tooling decision. A failed migration here doesn't just cost the business money. It puts the actual service someone receives from their insurance agent at risk.

The Problem as Initially Understood: The Specifications Needed More Detail

On paper, this looked like a documentation gap. During early demos, it became clear that the specs didn't have enough detail on how the work actually flowed; screens were being built to match a described process that didn't match the real one closely enough to hold up. The initial fix was more detail: refine the wireframes, tighten the prototypes, and go back to the same spec source and ask for more.

A single-policyholder account view, showing one person's products, billing, and details with no household-level grouping. — Agents worked one account at a time. A household's full relationship with the company lived nowhere in one place.

The Actual Problem: The Specifications Came From the Wrong Source

The real gap wasn't in the level of detail in the specs. It was in where the specs came from. Product managers had been collecting requirements from feature product owners inside the company, people responsible for a product line, not people who spent their day inside an agent's actual workflow. Nobody in that chain had asked the agents themselves how they worked, what they needed in front of them first, or what a household actually looked like from their side of the desk.

That assumption wasn't unique to this workstream. Around the same time, I was separately asked to map a customer-service scenario, because, again, no one else had documented how that particular interaction actually worked. Two different requests, the same missing piece: an organization that had built a spec-review process with no seat at the table for the people the specs were about.

Changing the Source of Truth Behind the Product

Once that was visible, the fix wasn't better documentation of the old plan; it was a new source for the plan. The team ran direct end-user interviews, design thinking workshops, usability testing, and focus groups with independent agency office workers, along with customer journey mapping, a heuristic review of the existing system, and feasibility validation with the technical teams: not to validate a design that already existed, but to map how their business actually ran, what a household meant in their world, and which scenarios the platform needed to solve for that no spec had captured.

The reframe that came out of it: build the platform for how these agents do their job and run their business, not for how corporate assumed it should work, and not for how a product roadmap had already assumed it could be implemented.

Agent dashboard homepage flow diagram mapping the paths from the dashboard into the Customer Household Dashboard, household highlights, active products, and opportunity creation. — A workflow map synthesized from the research, tracing how agents actually needed to move from the dashboard into a household and back out to an opportunity.

Reorganizing the CRM Around the Household

The framework that came out of that research was Hierarchy of Data, a principle for presenting end-user information in stages that match real need, instead of surfacing everything a system holds about a customer at once. Applied to this workstream, it became the household view: instead of an agent working one policy at a time, they'd see a household's full product relationship together, with the details that mattered most, a life event, a lapsed payment, a coverage gap, surfaced first rather than buried under fields that didn't matter to that conversation.

This wasn't a framework built for the case study after the fact. It's the name I used for the framework at the time, and it's a principle the competing peer-team approach, preserving the old system's look and feel through a "lift and shift," didn't share.

Household-grouped CRM view showing all household members and products together, with a surfaced note that a household member turns 16 next month and prompting a conversation about buying a car. — A household view grouping products by line, with a life event surfaced inline instead of buried in notes.

From Insight to Action in the Household View

Seeing the whole household was only half the value. The other half was what an agent could do next without losing that context. The design aimed to shorten the steps between noticing an opportunity and acting on it: following up with a customer, adding a product to the household, and tracking an opportunity through to close.

Adding a product opened on top of the household view instead of sending the agent to a separate record. The agent could save the product or move straight into a quote from the same place.

Opportunities surfaced in the household view carried their own stage tracker, from a new lead through assignment, quote, follow-up, and submission to close. That kept the agent's next step visible alongside the household it belonged to.

An Add New Product modal open on top of the household view, with fields for available office, line of business (Auto, Fire, Life, Health, Bank, Mutual Fund), effective date, and product, plus Save and Save and Quote actions. — Adding a product stayed inside the household screen.

An opportunity detail screen with a horizontal stage tracker (New, Assigned, Quote, Follow-up, Submitted, Closed) and opportunity details including line of business, product type, probability, and sales attempts. — An opportunity's stage tracker, from first note to close.

Using Agent Evidence to Challenge a Lift-and-Shift Direction

The central tension wasn't technical. It was that another design team was already committed to lift-and-shift, keeping the existing interface's shape to minimize disruption, while this workstream's direct evidence pointed toward a structural rebuild. Both sides believed they were representing the end user. Both approaches were described as user-centered, but only one had been tested directly with the agents expected to use the platform.

Resolving that took more than a design decision. It took proving the recommendation against evidence the other approach didn't have: workshop findings, usability sessions, and a direct account of how agents' businesses actually ran. That evidence, not seniority or preference, is what eventually moved stakeholders toward the Hierarchy of Data direction.

Designing Within the Existing CRM Investment

One organizational constraint shaped what "the new platform" could even mean: the business didn't want to move off its core CRM platform outright, given the cost of a global platform change. Any recommendation had to work within that constraint, not against it. The household view had to be something the existing platform could actually support, not a clean-slate reimagining that ignored what the business had already committed to.

That's a real tradeoff, not a footnote: the strongest version of an idea is rarely the version that ignores what the organization has already paid for.

What the Work Changed and What Remained Unmeasured

Customer impact: The validated design would allow agents to see a household's full relationship with the company in one place, with life events surfaced rather than buried, meaning conversations with customers could be proactive instead of reactive. This reflects the validated design direction; I did not observe it in live use, since the transition off the project came before launch.

Business impact: The business avoided the likely alternative outcome of a forced migration built on unvalidated specs, a path that risked either a stalled rollout or agents working around a system that didn't fit their business. Adoption outcome not measured; I transitioned off the project before implementation.

Organizational impact: Stakeholders and end users validated a working example showing how direct end-user research produced requirements and design decisions that more closely reflected agent workflows. Whether that changed how the organization sourced specs going forward is not something I was in a position to confirm.

Strategic Lesson: Migration Trust Begins Before the Interface

The clearest lesson from this project wasn't about data hierarchies. It was about where trust actually gets built in a migration. Not in the interface, and not in the announcement. In whether the people being asked to move can see themselves in what they're being asked to move to.

What was genuinely surprising, in hindsight, wasn't that the specs were incomplete. Incomplete specs are common. What was surprising was how confidently a competing team believed their own assumption-based approach was already user-grounded, right up until it was tested against people who'd actually go ask. That's not a criticism of the other team's intent. It's a reminder that "we understand the user" and "we asked the user" are not the same claim, and only one of them holds up under a workshop.