Rebuilding how a sales team understood failure. From broken picklist data to real loss intelligence, and a strategy team that finally had answers.
A B2B SaaS company with a regional sales team of about 30 reps had a data problem hiding in plain sight. When deals died, sales managers required reps to log a loss reason before closing the opportunity. The problem was how they were doing it.
The team had been using a multi-select picklist field on the Opportunity object. On the surface, it looked like they were capturing data. Multi-select picklist fields are notoriously difficult to report on in Salesforce. You can't easily filter by a single value, you can't count individual selections cleanly, and you definitely can't build the kind of pivot analysis leadership needs to ask questions like: "Why are we losing to Competitor X in Q3?"
Sales leadership knew they had a problem. Win rates had plateaued and there was genuine disagreement internally about why. Some believed pricing was the issue. Others thought it was product gaps. The VP of Sales wanted data to settle the argument, and what they had couldn't answer the question.
I was brought in to design and build the solution end to end. That meant scoping the data model, making architectural decisions about how records would relate to each other, building the user-facing flow, and creating the reporting layer that would make the data usable.
I also owned stakeholder communication, translating what management needed analytically into technical requirements, and then translating the technical constraints back into something the sales team could actually live with day to day. That translation work is often where these projects fall apart. I was responsible for making sure it didn't.
The first thing I did was dig into what management actually wanted to learn — "what questions do you need to be able to answer six months from now?" That conversation surfaced three core needs:
None of that was possible with a multi-select picklist field. Each selected value gets stored as a single semicolon-delimited string in the database. Salesforce's reporting engine can't disaggregate that cleanly. So the data structure itself had to change.
I made the decision early to move away from the picklist model entirely and use a child object instead. Each loss reason would live as its own record, related to the parent Opportunity through a lookup.
From there I built the custom object, defined the fields — reason category, reason detail, and a notes field for additional context — and set up the relationship to Opportunity. The category field used a single-select picklist, so reports could filter cleanly. The detail field gave reps room to add specifics without that specificity polluting the analytics.
The data entry problem was next. I built a screen flow triggered automatically when a rep moved an opportunity to Closed Lost. The flow walked them through selecting one or more loss reasons, and each selection created a separate child record. From the rep's perspective, it was a quick guided form. From the reporting perspective, every reason was a discrete, filterable record. Before deploying, I ran the flow past two sales reps.
The finished solution had three components:
Connected to Opportunity via a lookup relationship. Each record captured the category, optional detail, and any rep notes. Configured so that deleting a parent Opportunity also deleted associated Loss Reason records, keeping the org clean.
Triggered on Opportunity stage change to Closed Lost. Allowed reps to log multiple reasons in a single session, creating one record per reason. Included basic validation to prevent blank submissions and presented category options in a clear, consistent order.
A set of reports and a dashboard built on the Loss Reason object, summarizing volume by category, breakdown by rep, and trend over time by quarter. These weren't complex builds — but they required the data structure to be right first. Clean inputs make reporting straightforward.
Management had visibility into loss patterns within the first full quarter of use. That might sound like a low bar, but it genuinely wasn't — they'd been operating without it for years.
The data surfaced things they hadn't expected. One competitor was appearing in loss reasons far more frequently in a specific product segment than leadership had assumed. A pricing objection that managers thought was the primary driver turned out to be third on the list, behind two product-related concerns. Both findings shifted how the sales enablement team prioritized their next training cycle.
Rep adoption held up. The flow was short enough that it wasn't a burden, and because the reasons were structured and predictable, reps moved through it quickly.
Whether you're scaling a CRM, rescuing a troubled implementation, or looking for a Salesforce consultant to join your team, I'd love to connect.