From hypothesisto evidence.

A Lean UX canvas gave the starting problem structure. The specific belief: data that lived in Salesforce was not reaching the people who depended on it. Customers had to ask the team for information about their own accounts. The team had to pull, format, and resend data that already existed elsewhere. That loop created compounding effort on both sides.

The canvas separated what the team knew from what they assumed, and forced one question before anything else: what is the riskiest assumption, and what is the fastest way to test it? The most important hypothesis was not about what to build. It was about whether building was even the right answer.

Salesforce held the customer information. A client portal had been built to surface it. Before designing anything new, the existing platform was mapped systematically: every section, every path a customer could take, every point where the experience could be improved.

The findings were specific. The ticketing system displayed oldest messages first, burying the most recent ones. Key account information was missing or unfindable. When the platform couldn't surface what people needed, they chose email instead. Small friction, consistent cost. The audit made the pattern legible.

Interviews ran across two groups: active platform users and those who had chosen email instead. The finding was consistent. When information wasn't on the platform or couldn't be found, people defaulted to email. The ticketing system required scrolling past old messages to reach the newest ones. Small enough to ignore individually, significant enough to change behaviour at scale.

The sessions also surfaced what customers actually needed: the information they reached out about most, what they wished the platform offered, and where the experience had the most headroom to improve.

• ·Platform used rarely; email preferred for most client interactions
• ·Ticketing system displayed oldest messages first, causing users to move to email
• ·Key information missing or unfindable drove repeated manual requests
• ·Interviews identified priority information types and most-requested features

Rather than assume the answer, demos were booked with four market-leading platforms. Their data schemas, feature sets, and sales positioning were reviewed against what the operations actually required. Some came close. But adapting around an external tool's constraints would have introduced costs that outweighed the savings.

The data structures did not match the service model. Entity types, relationships, workflows: none of it aligned cleanly with how the business ran. The competitive analysis did not just confirm the build decision. It gave the team the evidence to defend it at board level.