How to analyze sales call recordings alongside user interview transcripts to find product gaps that block deals

Most product teams have two rich sources of customer evidence sitting in separate places. Sales call recordings live in a call recording tool, owned by the revenue team. User interview transcripts live in a research repository, owned by researchers or product managers. Each source tells part of the story about why customers buy, stall, or walk away. Few teams look at them together.

That's a missed opportunity. Sales calls show you what buyers say they need before they commit. User interviews show you what customers actually experience after they commit. When you analyze both side by side, you can separate the product gaps that genuinely block deals from noise, loud one-off requests, and messaging problems.

This guide walks through a practical, repeatable process for doing that analysis, from gathering the right recordings to presenting findings that product and sales leaders will act on.

Why combine sales calls and user interviews?

Each source has strengths and blind spots.

Sales calls capture the buying context. You hear evaluation criteria, competitor comparisons, security and compliance requirements, budget constraints, and the specific moments when a prospect hesitates. But sales calls are also performative. Buyers posture, reps steer the conversation toward strengths, and objections are sometimes negotiation tactics rather than real requirements.

User interviews capture the usage context. You hear how people actually work, where the product falls short, and what workarounds they've built. They're generally more candid because there's no deal on the line. But interviews skew toward people who already bought, so they can miss the reasons other prospects never became customers.

Put together, the two sources let you triangulate:

• A gap mentioned in lost deals and described as a painful workaround by existing customers is very likely real and important.
• A gap mentioned in lost deals but never raised by existing customers may be a segment-specific need, a perception problem, or a sign you're selling to the wrong buyers.
• A gap raised by existing customers but never mentioned in sales calls may be a retention risk rather than an acquisition blocker.

That distinction matters, because each type of gap calls for a different response.

What counts as a product gap that blocks deals?

Before you start analyzing, agree on what you're looking for. "Product gap" can mean many things, and a fuzzy definition leads to a fuzzy analysis. Common categories include:

Missing capabilities

The product doesn't do something the buyer needs, such as a reporting view, a workflow step, or support for a specific data type.

Integration gaps

The product works, but it doesn't connect to tools the buyer already relies on. In B2B sales, this is one of the most common deal blockers.

Security, compliance, and administrative requirements

Single sign-on, audit logs, data residency, role-based permissions, and certifications. These often come up late in a deal, during procurement or IT review, and can stop it outright.

Scale and performance limits

The product works for a small team but not for the buyer's volume of users, data, or projects.

Workflow fit

The product has the right features, but they're structured in a way that doesn't match how the buyer's team operates.

Perceived gaps

The product can actually do what the buyer needs, but the buyer doesn't know that or doesn't believe it. This is a messaging, enablement, or onboarding problem rather than a product problem. It's important to identify, because building something you already have wastes engineering time.

Step 1: Define your research question and scope

Start with a specific question. "Why do we lose deals?" is too broad. Better questions include:

• What product gaps are most often cited in lost or stalled enterprise deals over the last two quarters?
• Why are we losing to a specific competitor in a specific segment?
• Which gaps prevent mid-market customers from expanding to additional teams?

A focused question tells you which calls and interviews to include, what to tag, and what decision your findings should inform. It also gives you a clear stopping point.

Agree on scope with both product and sales stakeholders up front. If the head of sales expects a report on pricing objections and you deliver a report on integration gaps, you'll lose credibility even if your analysis is excellent.

Step 2: Gather and prepare your data

Select sales calls deliberately

Don't just pull the most recent calls. Build a sample that covers different outcomes:

• Lost deals, to see what blocked the purchase
• Stalled deals, to see where momentum died
• Won deals, as a comparison group. If won deals mention the same gaps as lost deals, that gap may not be the deciding factor.

Within each outcome, focus on the calls where gaps are most likely to surface: discovery calls, technical deep dives, demo follow-ups, and procurement or security reviews. Early intro calls are often too high-level to be useful.

Select user interviews that match

Pull interviews with current customers in the same segment, role, or use case as the prospects in your sales calls. If you're studying enterprise deals, interviews with small-business users won't tell you much. If you don't have relevant interviews, consider running a short round of new ones focused on the themes emerging from sales calls.

Attach metadata

Context turns transcripts into analyzable data. For each sales call, record:

• Deal outcome (won, lost, stalled, open)
• Deal stage at the time of the call
• Deal size or potential annual revenue
• Company size and industry
• Competitors involved
• Buyer role (economic buyer, end user, IT, procurement)

For each interview, record the participant's role, company size, tenure as a customer, and plan tier.

Handle consent and privacy

Confirm that your recording and consent policies cover using sales calls for research. Remove or limit access to sensitive details like pricing negotiations or personal information where they aren't relevant to your question.

Centralize everything

Analyzing transcripts across three different tools is slow and error-prone. Bring your sales calls and interviews into a single workspace where they're transcribed, searchable, and taggable with the same framework. A customer context platform like Dovetail is built for this: you can import recordings from different sources, transcribe them, and analyze them together in one project.

Step 3: Build a shared coding framework

A coding framework (or tag taxonomy) is the backbone of the analysis. Using the same framework across both sources is what makes cross-source comparison possible.

A useful framework for this analysis usually has a few layers:

Gap type: missing capability, integration, security/compliance, scale, workflow fit, perceived gap

Specific gap: for example, "Salesforce integration," "SSO via Okta," "bulk export," "custom roles"

Severity signal: dealbreaker, strong concern, nice-to-have, workaround exists

Context: who raised it (buyer role), when it came up (deal stage), and what job they were trying to do

Start with a draft framework based on what you already know, then refine it after coding your first five to ten transcripts. Expect to add, merge, and rename tags. Keep a short definition for each tag so that anyone coding later applies them consistently.

Step 4: Code both sources

Now work through the transcripts. Highlight passages where a gap, need, or workaround comes up, and apply the relevant tags.

A few practices make this step more reliable:

• Tag the evidence, not your interpretation. Highlight what the person actually said, and save interpretation for synthesis.
• Capture the job behind the request. When a buyer asks for "a Jira integration," note why. They may need to share findings with engineering, which could be solved in several ways.
• Note severity cues. Phrases like "we can't move forward without," "that's a requirement from our security team," or "we'd need to see that on the roadmap" signal a hard blocker. "It'd be nice if" signals something softer.
• Note how reps respond. If a rep explains that the product already does something and the buyer moves on, tag it as a perceived gap.
• Code in pairs at first. Have two people code the same few transcripts and compare. Disagreements reveal unclear tag definitions.

AI-assisted tagging and summarization can speed up this step considerably, especially with large volumes of sales calls. Treat AI output as a first pass that a human reviews, not a final answer, particularly for severity judgments.

Step 5: Compare patterns across sources

With both sources coded, you can start looking for patterns. A simple comparison matrix is one of the most useful tools here. List each specific gap as a row, with columns for:

• Number of lost or stalled deals mentioning it
• Number of won deals mentioning it
• Number of user interviews mentioning it
• Total deal value associated with it
• Segments where it appears
• Most common severity signal

Then read across each row. Patterns tend to fall into a few groups:

Confirmed blockers: Frequent in lost deals, rare in won deals, and described as painful by existing customers. These are your strongest candidates for investment.

Acquisition-only gaps: Frequent in lost deals but absent from user interviews. Check whether these come from a segment you don't currently serve well, or whether they're perceived gaps that better messaging could fix.

Retention risks: Frequent in user interviews but rarely raised in sales calls. These may not block deals today, but they could hurt renewals and expansion.

Table stakes: Mentioned in both won and lost deals at similar rates. Buyers expect them, but they don't decide the outcome on their own.

Counts are useful, but don't let them replace judgment. One gap that kills three six-figure enterprise deals can matter more than a gap mentioned in twenty small deals that closed anyway.

Step 6: Separate real gaps from objections and perception problems

This is where cross-source analysis earns its keep. Before declaring something a product gap, pressure-test it:

• Did the issue actually affect the outcome? Check the deal notes, the final calls, or ask the account executive. Buyers often list concerns that don't end up mattering.
• Does the product already address it? If so, you have an enablement or messaging gap. Share these findings with marketing and sales enablement, not just product.
• Is there a workaround? If existing customers have built a reasonable workaround, the gap may be less severe than prospects perceive, or it may be an onboarding opportunity.
• Is the buyer in your target market? Gaps raised only by companies outside your ideal customer profile may be signals to stay focused rather than to build.

Step 7: Prioritize with commercial and user context

Once you have a validated list of gaps, help stakeholders prioritize them. Combine the evidence from your analysis with factors like:

• Revenue impact: total value of deals blocked or stalled
• Frequency: how many deals and customers are affected
• Strategic fit: alignment with the segments and use cases the company is targeting
• Effort: rough engineering cost, which product and engineering partners can estimate
• Alternatives: whether a partnership, integration, or documentation change could close the gap faster than a new feature

Present gaps in tiers rather than a single ranked list. Teams can debate the order within a tier, but tiers make the overall picture clear.

Step 8: Share findings with evidence attached

The most persuasive research findings are grounded in customer voices. For each priority gap, include:

• A clear statement of the gap and the job it prevents customers from doing
• The supporting numbers from your comparison matrix
• Two or three short video or audio clips, or direct quotes, from both a sales call and a user interview
• The recommended next step, whether that's building, partnering, updating messaging, or investigating further

Hearing a prospect say "we can't sign without this" alongside a current customer describing the workaround they've built for the same problem is far more convincing than a bullet point. Tailor the format for each audience: product leaders want prioritization and trade-offs, sales leaders want to know what to say on calls today, and executives want revenue impact.

Common pitfalls to avoid

Letting the loudest rep set the agenda. Sales teams often have strong opinions about what's blocking deals. Those opinions are valuable hypotheses, but your analysis should test them against the recordings.

Only analyzing lost deals. Without won deals as a comparison, you can't tell whether a gap actually separates wins from losses.

Treating feature requests as requirements. Buyers describe solutions. Your job is to uncover the underlying problem, which may have a simpler or better solution.

Running the analysis once. Markets, competitors, and your product change. A one-time analysis gets stale within a quarter or two.

Making this analysis ongoing

The biggest gains come from turning this into a continuous practice rather than a one-off project. A few ways to do that:

• Set up a regular cadence, such as monthly or quarterly, for importing new sales calls and interviews into your research repository.
• Keep your coding framework stable so that findings are comparable over time, and version it when you make significant changes.
• Track how often each gap appears across periods. A gap that's growing is more urgent than one that's fading.
• Close the loop. When the product team ships something that addresses a gap, check whether it stops appearing in lost deals.

When sales calls and user interviews live in the same searchable place, such as a customer context platform like Dovetail, anyone on the team can search for a gap and immediately see every mention across both sources. That makes it much easier to answer questions as they come up, not just during formal research cycles.

Final thoughts

Sales calls and user interviews describe the same customers at different moments. Analyzing them together gives you a clearer, more honest picture of which product gaps genuinely block deals, which are perception problems, and which are quietly putting existing revenue at risk.

The process doesn't need to be complicated: define a focused question, gather a balanced sample, code both sources with a shared framework, compare patterns, pressure-test your conclusions, and share findings backed by real customer voices. Done consistently, it gives product and sales teams a shared foundation of evidence, and makes roadmap debates about what customers actually said rather than who argues loudest.

There's no fixed number. A practical starting point is 20 to 40 sales calls across won, lost, and stalled deals, plus 8 to 15 user interviews with current customers in the same segment. Keep adding sources until new calls stop surfacing new gap themes, a point researchers call saturation. If you're comparing segments, such as mid-market and enterprise, you need enough calls in each segment to see patterns, not just enough overall.

A real product gap shows up consistently across multiple deals, is tied to a specific job the buyer needs to get done, and often appears in user interviews as a workaround or frustration among existing customers. An objection is often a negotiation tactic or a reflection of unclear messaging. It tends to disappear once the rep explains the product better, offers a discount, or shows a demo. Look for whether the deal actually stalled or was lost because of the issue, and whether current users who have the product face the same problem.

It works best as a shared effort, with a researcher or product manager owning the method and sales or revenue operations providing access, deal context, and outcome data. Researchers bring rigor in coding and synthesis. Sales teams bring knowledge of which deals mattered and why. Without both, you risk either a methodologically sound analysis that ignores commercial reality or a list of anecdotal feature requests from the loudest reps.