We Built an AI Feedback Loop for Our Client’s SDR Team. Here’s What It Taught Us.

When your SDR is making calls every day on a new service line, the intelligence you need is already being recorded. AI sales call analysis makes that data extractable. The problem is almost never the data. It's that no one built the system to use it.

When a company launches a new service, the usual feedback channels are slow. Market research takes weeks. Competitive analysis tells you what others are doing, not what your specific customers think. Win/loss reviews only happen after enough deals have closed to see a pattern. And SDR performance assessments rely on a manager listening to enough calls to form a meaningful opinion: at two or three calls reviewed per week, that can take months to be useful.

The problem is that the information you actually need is already being generated. Every day your SDR is on the phone with prospects, you’re collecting live intelligence: how people react to the price, whether they understand the service, what objections come up repeatedly, where the conversation breaks down. It’s all there. It just lives in call recordings that are too numerous and too time-consuming to parse manually.

AI changes that calculus. What was previously too much unstructured data to work through systematically is now extractable, analyzable, and actionable, provided you build the right system around it.

That’s what we did for a client launching a new service line. They had an SDR working through inbound and outbound MQL conversations, generating real call volume from day one. We built a system to capture and parse that data, designed specifically around what they needed to know at that moment: how prospects were reacting to the new offering, where the SDR needed coaching to sell a service they were still learning themselves, and whether the pipeline was generating the right kind of leads in the first place.

This article is a walkthrough of what we built and what it showed us. We’re not presenting a finished product. We’re documenting what we learned from a system we’re still refining.

The underlying revenue data architecture question (when does a company need a system like this) is worth asking before you build anything. But this article is about the build and what it taught us.

The Situation: A New Service Line, an SDR, and No Feedback System

Our client, a multi-location healthcare company, launched a new service line in late 2025. The service was high-consideration, relatively high-cost, and required real SDR involvement to convert inbound leads into booked consultations. The SDR was making and receiving calls every day.

Those calls were happening. Transcripts were being captured by the VOIP call provider. Lead records were sitting in the CRM. But the two data sources weren’t connected to any analysis layer. The SDR’s manager had no systematic way to know: Is the pricing framing landing? Are prospects understanding what this service actually is? Where are the calls breaking down?

This is exactly where our earlier conversion work with this client had taught us something important: you can’t optimize a sales motion you can’t measure. The broader operational build had given the team strong infrastructure. What it didn’t have was a feedback loop running from the SDR’s conversations back into the strategy.

The standard answer to this problem is a conversation intelligence platform. There are good ones. They’re also built for large SaaS sales teams, priced accordingly, and designed around generic dashboards that don’t ask your specific questions. For a single SDR on a new service line, they were overkill and off-budget.

So we built something purpose-built instead.

What We Built: The Workflow

The system has three components. They run sequentially, and each one matters.

Component 1: Data extraction

A workflow automation tool pulls two data sources on a defined cadence. The VOIP call provider supplies the call transcripts: raw conversation text, speaker-labeled, with timestamps. The CRM supplies the associated contact and deal records: lifecycle stage at the time of the call, call type (initial outreach, follow-up, inbound inquiry), and any subsequent status changes.

Both sources are required. The transcript tells you what was said. The CRM record tells you what happened to the lead afterward. Without both, you’re analyzing conversations in isolation from their outcomes.

Component 2: JSON conversion

This is the step most people skip, and it’s the most important one. Before any AI analysis runs, the raw transcript data gets converted into structured JSON. Speaker turns are labeled consistently. Timestamps are normalized. Call metadata (type, lifecycle stage, call number in the sequence) gets appended to each record. Topics get pre-tagged where identifiable.

The reason this matters is covered in the next section. The short version: unstructured prose fed into an AI LLM produces inconsistent output. A structured schema produces comparable, repeatable output. The JSON conversion step is what makes the analysis a system rather than a one-time experiment.

Component 3: Prompt architecture

We wrote a set of AI prompts designed to extract specific, bounded outputs from each structured call record. Not “summarize this call.” Specific questions with defined output types: What is the primary objection category in this call? Was financial discovery completed before pricing was discussed? What is the prospect’s comprehension level of the service offering? Did the call end with a defined next step?

Each prompt runs against every call. The outputs are structured, consistent, and directly comparable across the full call set. The system now runs automatically on new calls as they come in.

The CRM data quality feeding this workflow matters as much as the workflow itself. A poorly maintained CRM instance would have broken the outcome linkage at Component 1. Garbage in, garbage out applies to AI analysis as much as it does to any reporting system.

Why Structuring the Data First Is the Real Unlock

What is the best way to get reliable output from AI call analysis? Structure the data before the AI ever sees it. This is the step that separates a useful intelligence system from an inconsistent experiment.

If you’ve tried using AI to analyze sales calls, you’ve probably done something like this: copy a transcript, paste it into an AI tool, ask it to summarize the key points or identify the main objection. You get a response. It’s probably reasonable. But do it with five calls and compare the outputs. The inconsistency becomes obvious. The AI interprets unstructured prose differently each time. The outputs aren’t directly comparable. You can’t spot patterns across a call set because every output is shaped differently.

This isn’t an AI capability problem. It’s a data structure problem.

When you convert transcripts to JSON first, you give the model a predictable schema. Speaker A is always labeled the same way. Topic categories are consistent. The call type field is always in the same position. The model stops spending its interpretation capacity figuring out the structure of the input and spends it entirely on the substance of the content. Output quality improves. More importantly, output consistency improves.

Bounded prompts compound this effect. When every call runs through the same set of specific prompts, the outputs are directly comparable across the full dataset. You start to see actual patterns: this objection category appears in most of the lost calls; calls where financial discovery happens before pricing end differently than calls where it doesn’t; inbound calls start from a different baseline than outreach calls.

The insight we kept returning to: the quality of AI output is a direct function of the quality of the input structure. If you want consistent intelligence from a system like this, invest in consistent inputs. That’s not a prompting problem. It’s a data architecture problem, and it’s the part of AI deployment that most teams underestimate.

What the Analysis Revealed

We ran the system across 104 calls covering a 42-day period. Here’s what stood out.

The SDR Was Covering Less Than Half of What a Good Call Requires

We scored each call against 8 discovery and execution areas defined in the prompt architecture. The average completeness score across 104 calls was 3.6 out of 8.

The gaps weren’t random. Objection handling appeared in only 32% of calls. Medical history, a critical qualifier for this specific service, was missing in 55% of calls. Financial discovery was absent in 42% of calls before pricing came up.

What surprised us was that the problem wasn’t effort or rapport. The SDR was building genuine connection with prospects: 78% of calls showed logical progression, and the 8 calls that reached 6 or higher on the completeness score all ended in positive sentiment and concrete next steps. The issue was the absence of a repeatable structure. High-performing calls followed a consistent sequence: rapport, discovery, value proposition, objection handling, then CTA. Most calls were skipping two to four of those steps, not out of carelessness, but because nobody had made the sequence explicit.

This is where the coaching insight became specific rather than general. Instead of “the SDR needs to handle objections better,” the data produced a concrete framework: financial discovery before pricing, scripted responses for the five most common objections, a medical history checkpoint early in discovery. Measurable targets followed: 75% positive sentiment rate, a 4.5+ average completeness score, 85% clear next-steps agreement within 90 days. The SDR now had a playbook built from their own calls rather than a generic training module.

The Selling Sequence Was Broken

In 23% of calls, pricing came up before the SDR had built adequate value proposition. That single pattern was the strongest predictor of negative outcomes in the dataset. Cost shock, specifically the reaction when patients discovered the service wasn’t covered at no charge, drove 43% of all negative sentiment.

The pricing wasn’t wrong. The sequence was wrong.

When we cut the data by call flow pattern, a clear split emerged. Calls that moved through Rapport, then Discovery, then Value Proposition, then Objection Handling, then CTA converted at a materially different rate than calls that jumped from Introduction directly to Pricing and into Objection. The second pattern typically ended in a hang-up or a vague “I’ll think about it.”

This finding directly reshaped the SDR’s selling motion: a mandatory financial discovery checkpoint before any pricing discussion, and a tiered framing approach to surface budget expectations before quoting a number. Small structural change. The connection to broader conversion work is direct: most conversion problems aren’t creative or messaging problems. They’re sequencing problems.

The Marketing Was Setting Up Calls to Fail

One pattern in the data wasn’t a sales problem at all. Inbound inquiries, which should be the warmest call type, had the lowest positive sentiment rate at 56%. Initial outreach ran at 66%. Follow-ups ran at 65%. The gap pointed somewhere specific: inbound callers were frequently arriving with expectations set by advertising that didn’t match the actual service offering.

Misconceptions about coverage, pricing, and eligibility appeared repeatedly in calls that opened with correction rather than qualification. The SDR was spending the first portion of calls undoing damage created before the call started.

Two additional patterns reinforced the diagnosis. A government assistance program that represented a genuine competitive differentiator for price-sensitive prospects was invoked in only 31 of 104 calls. Success stories and social proof, high-trust signals for a high-consideration purchase, appeared in zero calls.

The marketing fix wasn’t a campaign overhaul. It was two things: ad creative that set accurate expectations upfront, reducing the volume of correction-mode inbound calls, and equipping the SDR with specific positioning language and proof points as standard tools rather than afterthoughts. The lead generation strategy question and the sales execution question turned out to be more connected than the team had recognized before the call data made it visible.

What This Means for Revenue Teams Running New Lines or Ramping Sales Motions

You don’t need an enterprise conversation intelligence platform to do this. The approach we used is accessible to most mid-market teams. The build takes time and requires someone who can architect the workflow and write structured prompts. But the ongoing cost is a fraction of an enterprise contract, and the output is calibrated to your business, your call structure, and your specific questions.

This approach is most valuable in three situations:

• When you’re launching a new service or product line and don’t yet have a selling playbook: the call data builds the playbook from real conversations rather than assumptions.
• When you’re ramping a new SDR or account executive and want structured coaching data rather than manager intuition.
• When your pipeline data shows a conversion problem but doesn’t explain why: calls are often the explanation.

The feedback loop is the point. Individual insights are outputs. What you’re building is a system where every future call contributes to the intelligence base. It compounds. The 42-day dataset we analyzed was useful. A 6-month dataset will be more useful. A 12-month dataset will show seasonal patterns, service evolution, and SDR development over time. We’re only beginning to understand what continuous intelligence like this makes possible.

We built this as operators embedded inside the business, not as a software vendor shipping a dashboard. That’s the RevOps capability question most teams need to answer before they build: who owns this, who maintains it, and who acts on what it produces?

We’re still learning what this system can do. But what it’s already shown us is enough to say: your call data is not a compliance record. It’s an intelligence asset. Build the system to use it.

Frequently Asked Questions

How can AI be used to analyze sales calls?

AI analyzes sales call transcripts to identify patterns across objection types, sentiment, call structure, and conversion outcomes. The most reliable approach converts raw transcripts into structured data before analysis, then uses bounded prompts to extract specific, comparable outputs from each call rather than open-ended summaries.

What is a sales feedback loop?

A sales feedback loop is a system that continuously captures data from sales conversations and routes actionable insights back to the people and processes that can act on them: the SDR, the sales manager, the marketing team, and the pricing function. The goal is for every call to contribute to the selling system rather than disappear into a recording archive.

Do you need an enterprise tool like Gong to get insights from call data?

No. Enterprise conversation intelligence platforms are well-built but expensive and designed for large SaaS sales teams. A custom workflow connecting your call recording tool, CRM, and an AI LLM can deliver comparable analytical output at a fraction of the cost, with the added benefit of being purpose-built around your specific call structure and business questions.

How do you get consistent output from AI call analysis?

Consistency comes from data structure, not prompt sophistication. Converting transcripts to structured JSON before analysis, with consistent speaker labeling, call type metadata, and topic pre-tagging, gives the model a predictable schema to work against. Paired with bounded prompts that ask specific questions with defined output types, this produces results that are directly comparable across a full call set.

What does a sales call analysis workflow actually look like?

At a basic level: a workflow automation tool pulls transcript data from your call recording platform and deal data from your CRM on a defined schedule. That data gets converted into a consistent structured format. A set of specific AI prompts then runs against each record, extracting defined outputs. Those outputs are compiled into a reporting layer the team can act on. The architecture can be as lightweight or as sophisticated as the team needs.

Want more like this from Foes?

Subscribe to our newsletter for frameworks, playbooks, and lessons from inside mid-market growth companies. No fluff. Just the operating knowledge that actually moves the needle.