What an AI sales tool taught me about trust and adoption
MY ROLE ON THE PROJECT
I led product design on this project from early discovery through launch, working closely with Product, Sales and CSM to clarify the problem, understand how reps actually worked day to day, and define what a genuinely useful recommendation looked like. I owned the UX strategy, the interaction design, and the prototyping.
The business objective behind the project was tied directly to closing deals faster and reducing how much the sales funnel depended on SME bandwidth, both of which mattered for our 25/26 financial targets.
Sales reps closing B2B deals were losing momentum in the two weeks it typically took to move from a first conversation to an actual offer.
Three things were slowing them down. Many clients could not clearly articulate their own challenges, which made discovery calls inefficient and left reps without a structured way to turn a vague business need into a learning solution.
On top of that, a recent merger had tripled the content catalogue, and reps, especially new hires, struggled to keep recommendations consistent as they onboarded. And for most deals, reps depended heavily on subject matter experts to curate the right content, but SME availability was limited, so deals stalled whenever that support was not immediately there.
BEFORE AI CONTENT RECOMMENDER
Helping sales reps recommend learning content with less help from SMEs.
To address this, I designed a recommender that let reps capture signals like industry, role, and challenges directly from a client conversation, get relevant content suggestions in minutes instead of weeks, and put together a first learning plan while the lead was still warm.
AFTER AI CONTENT RECOMMENDER
To support different working styles, I explored three input methods:
We launched with the guided flow first, to improve input quality and reduce risk.
We launched the guided Q&A first because recommendation quality depended on the information reps entered. Starting with one structured option let us test the idea before adding the other input methods.
The early numbers (first 8 weeks) looked like validation
Usage should have kept growing. Instead, it started to slip
As usage data came in, I noticed a gap between expected and actual behavior.
At first, we thought the recommendations might be the problem. The usage data also showed that reps were entering too little information and weren’t always sure how much to trust Ela.
An SME conversation changed how I understood the problem
While reviewing usage logs and feedback, I noticed an unusual pattern from one of the curriculum specialists.
There was tension building more broadly too.
The tool was meant to remove friction from the sales funnel, but some sales and SME stakeholders experienced it as something that reduced their control, and a few sales teams had already built their own informal AI workarounds before we launched, so they were resistant to replacing something that already worked for them.
I set up a 1:1 with the SME showing this pattern
Since he had not been engaging much in group discussions with product and engineering I tried talking to him solo and he was surprisingly open to talking to me directly.
His main concern was that reps might share a recommendation without checking it carefully first.
That reframed the whole problem for me.
SMEs were mainly concerned about how reps would use the recommendations.
Trust in the tool was tied to trust in the user
Helping reps judge when a recommendation is ready to share.
That insight changed what I chose to design next.
I designed the system to check whether reps had provided enough information, then flag whether a recommendation was ready to share, needed caveats or required expert review.
The goal was to balance speed with accountability, so reps could move faster while still being guided on when their own judgment, or an SME's, needed to be in the loop.
A recommendation needs to be accurate, and people need to know when it’s ready to share or needs an expert’s review.
To move this beyond a design exploration, I organized a working session with the SME, the Product Manager, and the Engineering Manager to align on the underlying trust issue directly.
That session moved the discussion from AI accuracy alone to how reps would use recommendations and what support they needed.
Before settling on a solution, I weighed three different options for the recommednation card
Mandatory SME sign-off
The first was making SME sign off mandatory before any recommendation reached a client, which would have addressed the trust concern directly but reintroduced the exact bottleneck the project was meant to remove.
A simple confidence score
The second was simpler, just showing a match score or confidence percentage next to each recommendation. That would have been easy to ship, but it only offered surface level transparency. A number does not tell a rep what to actually do with it, and it does not address the SMEs concerns.
My choice: confidence label based on input quality
I chose the input completeness and confidence flagging approach instead because it kept reps moving quickly while still building in a real moment of judgment, rather than either blocking speed entirely or offering transparency that looked good without changing behavior.
The outcome was mixed.
The group responded well to the idea, though the team never put it into the product. Adoption kept declining as support from Sales leadership stayed inconsistent, reps continued using their own tools, and Ela didn’t fit their usual ways of working.
The project was eventually deprioritized.
What I learned: adoption might depend on people, not just the design
This project reinforced that adoption of an AI product depends as much on organizational context and user behavior as it does on the quality of the solution itself. Early positive signals were not enough, because the system relied on behavior change, structured input and less reliance on SMEs, that needed stronger alignment across teams and leadership to actually hold.
I also learned how teams can resist a shared tool when they already have their own workarounds. We needed to understand those ownership concerns and agree how Ela would fit into existing routines.
