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

ROLE

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

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.

The engagement ran roughly two years, ending when I transitioned to a different role, not when the work concluded. Multiple teams were involved: the author's own design track, at least one peer design team pursuing a different technical approach, product management, and the feature product owners feeding them specs. The author's 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.

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.

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.

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 work stream. 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.

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 workshops, usability testing, and focus groups with independent agency office workers: 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.

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 work stream, 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.

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.

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.