Programmable call analysis: a new category for revenue teams
Conversation intelligence solved capture. Programmable call analysis is the missing layer above it — where you define the criteria and the system applies it across every call in your pipeline.
By Ahmet Nuri Ozcelik · Product Marketing Leader & GTM Engineer · 9 min read
Quick answer: Programmable call analysis is the missing layer of the revenue stack — where you define the analysis criteria in plain language and the system applies that brief across every call in your pipeline, not one call at a time. It's what sits between conversation intelligence (which solved capture) and CRM reporting (which solved deal aggregation). Callmine is the programmable call analysis product, running on top of your existing Gong recordings.
Callmine is the programmable call analysis layer for Gong. The rest of this post defines the category, walks through why per-call AI is not the same thing as cross-call analysis, and shows the workflow on your own calls. If you only want the operational version, jump to How to run this in Callmine.
Programmable call analysis is the process of applying user-defined analysis criteria across many sales calls to identify patterns that would be impossible to find by reviewing calls one by one. It's the analysis layer above conversation intelligence — where capture, transcription, and per-call summaries already exist, but cross-call pattern analysis does not. This post defines the category: what it is, what it isn't, why it didn't exist before, why it needs to exist now, and what changes for revenue teams that adopt it.
The modern revenue stack has three layers. Two are mature. One is missing.
The first layer is capture — the systems that record what your sales team says and to whom. Gong, Chorus, Fireflies. This problem was largely solved between 2014 and 2018. Most B2B companies above a certain size now have full transcripts of every call their sales team has had for the last several years.
The second layer is reporting — the systems that aggregate deal-level data into pipeline, forecast, and conversion views. Salesforce. HubSpot. The BI tools that sit on top of them. This problem has been solved for decades, in some form.
The third layer is the one nobody has built — until now. It's the layer that connects the first two. It's the layer that lets you ask a question of your sales conversations and get a structured answer back, applied across every call in your pipeline.
It doesn't have a clean name yet. The name I think fits is programmable call analysis.
This post is an attempt to define the category. What it is, what it isn't, why it didn't exist before, why it needs to exist now, and what changes for revenue teams that adopt it.
What "programmable" means
Two things distinguish programmable call analysis from the tools that came before it.
First: the criteria are defined by the user, not the vendor
Conversation intelligence tools ship with predefined scorecards, sentiment models, and dashboards. You can use what's there or you can't. If you want to evaluate calls on something the vendor didn't anticipate — a specific objection-handling pattern, a discovery framework you've built internally, the way your reps respond to a particular competitor's pricing model — the tool can't help you. The criteria are baked in.
In a programmable system, the user writes the criteria. In plain language. The way you'd brief a senior analyst. The system applies that brief to every call in the selected set, individually, with the rigor of a domain expert who'd read 500 calls without getting tired.
This is the same shift that has happened in adjacent categories. Spreadsheets are programmable; calculators are not. Notion is programmable; the document templates that came before it weren't. Clay is programmable data enrichment; the static enrichment vendors that came before it weren't. The pattern is consistent: when the criteria become user-defined instead of vendor-defined, the category usually expands and the previous generation gets repositioned underneath it.
Second: the analysis is applied across many calls, not one
Conversation intelligence reviews one call at a time. That's its design. Programmable call analysis runs across hundreds or thousands of calls at once and aggregates patterns. It's a fundamentally different unit of analysis. You're not asking "what happened on this call." You're asking "what happened across all these calls, and where are the patterns."
The shape of the distinction:
| Dimension | Per-call summary (e.g. Gong AI) | Programmable call analysis (cross-call) |
|---|---|---|
| Unit of analysis | One call | A cohort of calls (dozens to thousands) |
| Question type | "What happened on this call?" | "What's the pattern across all these calls?" |
| Criteria source | Vendor-defined (sentiment, talk ratio, default scorecards) | User-defined prompt, in plain language |
| Typical output | A per-call summary or score | A cohort-level report with evidence quotes |
| Comparability | Hard — every call summarized in isolation | High — same prompt, same cohort, same period |
| Reused weekly | No — each call is a fresh artifact | Yes — the prompt is the asset |
Together, those two properties — user-defined criteria, applied at scale — are the working definition of the category.
Why this didn't exist before
Three things had to happen for programmable call analysis to be possible.
Call data needed to be ubiquitous and structured. That happened with the conversation intelligence wave. By 2020, most mid-market and enterprise B2B companies had transcripts of every sales call. The dataset existed, sitting in Gong and Chorus instances around the world. It just couldn't be queried beyond keyword search.
Language models needed to read with the rigor of a domain expert. Pre-LLM systems could do extractive tasks — keyword matching, sentiment classification, simple categorization — but they couldn't reason about a sales call the way a senior analyst would. They couldn't tell the difference between a stated objection and an underlying concern. They couldn't follow a sales narrative across forty minutes. That capability emerged with GPT-4-class models around 2023.
Analysis needed to be cheap enough to run at scale. A senior analyst reading 500 sales calls is a six-figure project. The same analysis run by a model is cents per call. That economic shift is what makes programmable call analysis a product category and not just a service offering.
All three of these conditions were in place by mid-2024. The category started to be possible. Now it's starting to be built.
How it differs from what's already out there
A reasonable question at this point: how is this different from what conversation intelligence tools already do? Or what BI tools already do? The honest answer is that it's a different layer of the stack — neither replacing those tools nor competing with them.
| Layer | Tool | Job to be done |
|---|---|---|
| Capture | Gong, Chorus, Fireflies | Record, transcribe, store sales conversations. The source of truth for what was said. |
| Single-call review | Same tools, plus their built-in dashboards | Help a manager review or coach on one call at a time. |
| Pipeline reporting | Salesforce, HubSpot, BI tools | Aggregate deal-level data: stage movement, win rate, ACV, pipeline coverage. |
| Programmable call analysis | The category that's emerging — Callmine being one example | Apply user-defined evaluation criteria across many calls. Surface patterns. Connect what was said to what happened in the deal. |
The capture tools are the source of truth for what was said. The reporting tools are the source of truth for what closed. Programmable call analysis is the layer that tells you why — by reading the conversations in the context of the deals.
It's not a replacement for any of those layers. It's a layer that sits on top of them and depends on them.
Why now: the macro case
There's a structural argument for why this category needs to exist, beyond the fact that it's now technically possible.
Revenue teams have more data than ever and less understanding. This is a widely felt problem. Every revenue leader I've talked to in the last year has some version of "we have all this Gong data but we don't know what to do with it." That's the user-facing symptom of a missing category. Capture solved itself. Analysis didn't keep up.
The cost of not understanding is rising. Sales cycles are longer. Buying committees are bigger. Pipeline conversion is harder. The blast radius of a bad positioning call or a missed objection pattern is much larger than it was five years ago. Teams that can read their conversations at scale will outperform teams that can't, and the gap will widen.
The traditional alternatives don't scale. Win/loss interviews, manager call reviews, anecdotal coaching, sampled deal reviews — all of these are linear-cost activities that compete with everyone's actual job. They worked when revenue teams were small. They don't work at the scale revenue teams now operate at.
The shape of the problem is exactly the shape that gets a new category built around it. Existing tools are insufficient. The need is widely felt but unsolved. The technical conditions for a solution are recently in place. The economic argument is clear.
What changes when this layer is in place
Three things change for revenue teams when they adopt programmable call analysis.
Win/loss analysis becomes continuous. Most teams run win/loss as a quarterly project on a small sample of memorable deals. With programmable analysis, win/loss becomes a recurring report on every closed deal. The findings are larger-N, more honest about underlying reasons (vs. stated ones), and updated on a cadence that lets you see whether your interventions actually shift the pattern. (We wrote a step-by-step playbook for running this if you want the operational version.)
Coaching becomes evidence-based. Sales managers stop coaching on the three calls they remember from this week and start coaching on the patterns visible across all calls in the period. The conversation shifts from "I noticed in your call yesterday" to "across the last 30 calls, here's what's working and here's what isn't."
Marketing teams get access to a research dataset they've never had. This is the under-discussed implication. Sales calls are customer research. Programmable call analysis makes them readable as research. Personas, messaging, positioning, competitive intelligence — all of these can now be built from a dataset that's larger and more honest than anything customer research has historically had access to. (We made the longer argument here.) It's a category-creation moment for product marketing as much as for sales operations.
There are second-order effects too — recurring competitive intelligence, product feedback loops fed by buyer language, sales enablement grounded in what's actually working. But the three above are the immediate ones.
What's true about every team using this layer well
A few patterns I see in the teams getting real value from programmable call analysis, even at this early stage of the category.
They start with one specific question
Not "show me everything that's interesting." A real, narrow, answerable question — "why are we losing healthcare deals in late stage" or "how are reps handling the new competitor's pricing claim." Specific questions get specific answers. Vague questions get vague reports.
They run it on a recurring cadence
A one-off analysis is a snapshot. A monthly analysis is a feedback loop. The teams who treat this as infrastructure — same questions, same cadence, same dashboards — get compounding value. The teams who run one analysis and stop get a single insight and move on.
They close the loop
They make a change in response to what the analysis surfaces. They run the analysis again. They watch the pattern shift. This is what separates a tool from a practice.
They share the output across functions
The same analysis that tells the sales leader where coaching is needed tells the product marketer where messaging is bouncing off. Teams that route the output to multiple audiences get more value per analysis than teams that keep it siloed in one function.
What this means for the broader stack
If the category I'm describing is real — and I think it is — there are predictable knock-on effects.
Conversation intelligence tools will reposition. Some will try to build programmable analysis on top of their capture layer. That's the natural defensive move. The challenge is that capture and analysis have different shapes — capture optimizes for completeness and storage, analysis optimizes for query flexibility and rigor. The companies that try to do both will struggle to do either as well as the specialized players.
BI tools and CRMs will build adjacent capabilities. They already are. But they're starting from "what's in the deal record" and trying to push into the conversation, which is the harder direction. Programmable call analysis starts from the conversation and pulls in the deal context, which turns out to be the easier direction.
A new generation of role-specific tools will emerge on top. Specialized analysis surfaces for product marketing, for sales coaching, for competitive intelligence — all built on the programmable layer. This is where the category goes after the foundational tools are established.
How to run this in Callmine
Callmine reads your Gong calls — it doesn't write to or modify Gong. Programmable call analysis is the workflow itself. Here's what it looks like end to end:
1. Pick the cohort in Gong.
Filter Gong to the calls you want to analyze. For a competitive read, that might be: Tracker = "Competitor X mentioned", Stage = Closed-Won OR Closed-Lost, Last 90 days. For a positioning read: Call type = Discovery, Persona = VP Sales, Last 60 days. The cohort is the question — narrow cohorts get sharper answers than "all calls."
2. Run the saved "Programmable cohort analysis" template. The prompt:
Across these calls, identify the two or three patterns that repeat in how buyers describe their problem and how reps respond. For each pattern, output: a one-sentence description, the count of calls it appears in, the top three evidence quotes with call IDs, and whether it correlates with won vs lost outcomes. Ignore one-off moments. Only surface patterns that appear in at least 20% of the cohort.
3. Output lands as a structured report in your Callmine workspace — patterns, counts, evidence quotes, and outcome correlation — exportable to Slack, Sheets, or a Notion doc for the next QBR or PMM review.
The prompt is the asset. Re-run it next month against the next 90-day cohort and the output is directly comparable. That comparability — same brief, same shape of output, different period — is the practical payoff of the category.
Closing
Categories aren't born by being declared. They're born when the underlying technical and market conditions converge, a useful product gets built, and a name happens to stick.
Programmable call analysis is the layer between capture and reporting. It's the answer to the question every revenue leader has been asking — "we have all this data, what do we do with it?" — and the answer turns out to be a different one than the conversation intelligence vendors have been giving.
The technical conditions are in place. The need is widespread. The market is ready.
What's left is execution.
FAQ
What is programmable call analysis?
Programmable call analysis is the process of applying user-defined analysis criteria across many sales calls — dozens, hundreds, or thousands — to identify patterns, risks, objections, and GTM insights that aren't visible in any single call. The "programmable" part means the criteria are written by the user in plain language, the way you'd brief a senior analyst, rather than baked into the vendor's product.
How is programmable call analysis different from conversation intelligence?
Conversation intelligence focuses on recording, transcribing, summarizing, and coaching around individual calls — the unit of analysis is one call. Programmable call analysis runs across many calls at once and aggregates patterns — the unit of analysis is a cohort. The two layers are complementary: conversation intelligence is the capture layer, programmable call analysis is the layer above it.
Is Callmine a replacement for Gong?
No. Callmine reads your Gong calls after they're captured; Gong remains the system of record for recording and storing the conversations. The categories don't compete — they stack. Gong sits at the capture layer; Callmine sits at the programmable analysis layer.
Who uses programmable call analysis?
Revenue leaders, product marketers, RevOps teams, competitive intelligence teams, founders, and GTM leaders use it to understand patterns across sales conversations at scale. The common thread is that they need a defensible cohort-level answer — not another per-call summary.
See programmable call analysis on your own data
The fastest way to understand a new category is to use it. The trial is free, and 100 calls is enough to run a real question.
[ Try Callmine free — 100 calls, 30 days ]
No credit card. After your trial, your workspace continues on the Free plan.