An internal account-health and feature-adoption dashboard served three different teams, but no one had documented how they actually worked, and trust in the data had slipped. I led the research that mapped the real process, surfaced the pain points, and validated the beta features, producing a prioritized set of recommendations for the product team.
Inside one of the world's largest CRM platforms, an internal account-health and feature-adoption dashboard scores each account across three dimensions, product adoption, expertise, and technical health, instead of a single blended number. Customer Success Managers, Account Executives, and Renewal Managers use it to monitor adoption, prepare client conversations, and support renewals, while a customer-facing version helps clients track their own adoption and prove ROI.
It supports a lot of decisions, but no one had documented how the three roles actually worked day to day, and trust in the numbers had broken down. Before improving anything, the team needed a clear picture of the current process, its pain points, and where the data was losing credibility.
The scores often didn't reflect how an account was actually performing, and the lack of visibility into how the model worked made it hard for users to have informed conversations with their customers.
Users independently validated the data outside the platform before facing a client, because the numbers weren't always accurate.
Account Executives had stopped sharing the auto-generated reports altogether, since system errors risked reflecting on their own professional competence.
To see unbundled product footprints and contract terms, users constantly context-switched between the scorecard, the CRM system of record, spreadsheets, and personal living documents.
Back-end re-weighting could swing a score 20 points with zero customer action, leaving teams unable to explain a "win" or a "loss."
The biggest pain point is severe data distrust. I manually verify the data outside the platform before every client meeting, because a "0" could just be a tracking error.
The team had product documentation but no picture of how the three roles actually worked, and trust in the data had worn thin. I set three goals: understand the current process and its pain points, give the organization visibility into the end-to-end workflow, and validate the beta features so the team building them could iterate. Each activity answered a different question and fed a prioritized set of recommendations for the product team.
I started by mining a full year of exported support-channel data to find the most frequent, highest-impact issues. That analysis set the priorities and shaped the interview script, so the 1:1 sessions could follow up directly on problems users were already reporting.
Product documentation existed, but the day-to-day process, challenges, and limitations of the people using the platform did not. I ran 16 in-depth 1:1 interviews (45-minute deep dives) across all three roles, and turned them into working personas built on real jobs, not job titles.
No documentation of the overall process existed. Mapped in parallel with the interviews and completed once they wrapped, an end-to-end service blueprint traced the customer lifecycle across all three roles, its actions, tools, and emotions, giving the organization a shared picture.
A screen-by-screen heuristic evaluation produced 15 findings, each scored on a 0 to 4 severity scale, mapped to a usability heuristic, and paired with a concrete recommendation, ordered by impact.
In parallel, new beta features were being built for a major client event. Collaborating with the external UX/UI team designing them, I built the prototypes and test script, recruited internal and external users, and ran unmoderated remote sessions on a third-party usability-testing platform with 19 participants (8 internal, 11 external). The qualitative and quantitative report and its recommendations were presented back across several sessions.
The blueprint traced the full account lifecycle, showing at every step which tool each role reached for, what they felt, and where the platform quietly handed the work back to them.
Routine health checks and manual tracking to cover visibility gaps, plus hunting for upsell metrics in the utilization data.
Preparing customer-facing reviews, reconciling adoption data against contracted licenses, and rewriting AI-generated decks by hand.
Modeling pricing uplifts in spreadsheets, hunting shelfware to protect the negotiation, and opening the renewal conversation 90 days out.
The blueprint became the artifact everyone pointed at: product, engineering, and leadership finally looking at the same map instead of at each other.
The expert audit produced 15 findings on a 0 to 4 severity scale, and the research analysis used the same scale. Every issue below, from the audit or the interviews, carried a severity, a heuristic, a recommendation, and a stated impact, so prioritization stayed a conversation about evidence, not opinion.
Ahead of a major client release, I validated the beta redesign with unmoderated remote sessions across internal and external users. The overall reception was positive: people grasped the core sections and welcomed more current, more actionable metrics. Testing focused on three new features.
We tested where to place the control that launches an AI-assisted action in the table. The test settled it and exposed an expectation gap: people expected static, self-serve help, so we routed AI through a single, clearly-labeled entry point instead of repeating it per row.
A full new section that recommends features to enable, tied to the business objectives each one supports. Easy to find and valued for showing the objectives a feature would impact, with clear notes on titles, terminology, and controls to refine.
A prominent alert banner with a dedicated alerts tab. The strongest-received feature of the round, easy to spot and act on without losing context, with room to extend it to consumption alerts.
Overall, the new design landed well. The report separated what could ship as a baseline from the friction still worth refining, so the team building the features could keep iterating on evidence, not opinion.
As companies grow, the product and the experience around it can't stand still, they have to keep iterating alongside the organization. What this project reinforced for me is that understanding what the three roles actually needed, rather than assuming it, is what prevented the workarounds and the mistrust that had built up around the tool. Research at this scale is a small investment next to what it protects: a product people trust enough to use as intended, and the ROI it exists to prove in the first place.