In a November 2024 interview with TechTarget, CallMiner CEO and co-founder Jeff Gallino was asked whether contact centers have enough conversation data, or whether more is better. His answer is worth reading closely.
He said that early in the industry, he advocated for collecting 100 percent of conversations, "primarily because at the time it was a differentiator for CallMiner." Now, he said, customers have it, and some are asking for more. Compliance use cases make 100 percent "easy to talk about."
Then this: "However, the economics of AI are going to force us to reconsider sampling beyond compliance cases." And later in the same answer: "the stark reality is that a majority of CX companies are selling tools that sample data not because of the complexity of scaling AI to that size but more because of the cost."
Read that again. The CEO of the category's longest-running vendor is saying out loud that the industry is moving back toward sampling, and the reason is not technical feasibility. It is cost.
He is right about the economics of how most conversation intelligence was built. He is describing an architecture decision, not a law of the category. The question worth asking is whether the economics have to work that way, and what 100 percent should actually mean in the first place.
Most of the industry treats 100 percent coverage as a volume claim. Every call ingested. Every call transcribed. Every call scored against a scorecard. That is a real improvement over sampling, and it is what the category spent two decades building toward. It is also not enough.
The problem is the word "coverage." Coverage says you touched every conversation. It does not say what you understood about them. A system that transcribes 100 percent of calls and runs a fixed set of keyword rules against them has 100 percent coverage, and almost no understanding. A system that scores 100 percent of calls on a QA scorecard has 100 percent coverage of one question, agent performance, and no answer to any other question the business might ask.
The right bar is 100 percent understanding, not 100 percent coverage. Every conversation read in full. Every conversation available to any question the business thinks to ask, not just the handful the vendor pre-wired into the scorecard. The simple questions and the abstract ones. Did the agent follow the disclosure script. Why are customers in this cohort churning. What is the pattern underneath the complaints coming out of a specific overflow queue. What are customers telling us about new pricing that they are not telling us in surveys. Different questions at different levels of abstraction, and the only system that answers all of them is one that understood every conversation, not one that scored every conversation.
100 percent understanding means the product can answer the question that was not asked when the system was configured. That is a different capability than coverage, and it has different economics.
Most conversation intelligence platforms were built in the pre-generative-AI era. The core pipeline was keyword spotting, phrase matching, and acoustic analysis. Those techniques scale cheaply. Running them across every call is not what makes the bill large.
What makes the bill large is bolting generative AI on top. Summarization per call. Reasoning per call. A large language model prompt per interaction. When each conversation triggers a round trip to a frontier model, 100 percent coverage stops being a product decision and starts being a line item that scares the CFO.
Vendors in that position are forced into one of two bad choices. Sample, which hides the signal. Or template, which limits the questions.
Sampling is not neutral. It systematically under-detects anything concentrated in a subset of calls, agents, or product lines. As any compliance officer who has looked at the raw data knows, that is where almost all the interesting findings live. The methodology that reduces cost is also the methodology that hides the signal.
Templating is the other escape hatch. Pre-wire a scorecard, a category tree, a set of rules, and run the expensive analysis only inside those boundaries. Full coverage on paper. The system still cannot answer a question nobody thought to template.
Gallino's quote is honest in a way the category rarely is. He is not claiming sampling is better than full coverage. He is saying the economics force it. The implicit assumption is that the architecture is fixed. It isn't.
Compass was built around modern AI from day one. That is not a feature claim. It is a different design decision at the layer where the economics are set.
Without exposing the mechanics, the relevant difference is this: Compass does not treat conversations as a stack of individual calls to be summarized one by one. It understands them in totality, as a connected body of customer signal, and the expensive compute runs where it earns its keep rather than on every interaction in isolation. The result is 100 percent understanding without the 100 percent bill.
Understanding, not coverage. Every conversation is comprehended in full, available to any question the business brings, from the narrow and operational to the broad and strategic. The system does not need to be re-templated every time the business thinks of a new question, because the understanding is already there.
This is an architecture claim with a pricing consequence. Vendors whose answer is "sampling is enough" or "the scorecard covers the important questions" are describing their cost structure and their design, not the ceiling of what conversation intelligence can do.
What conversation intelligence is actually for determines whether sampling or scoring-only is survivable or disqualifying.
If CI is a QA tool, scoring every call is survivable. If the deliverable is a scorecard, you can live with a system that only answers scorecard questions. If CI is a compliance tool, coverage of the regulated moments is partially survivable. Regulators expect visibility into high-risk disclosures, and most vendors meet that bar on a narrow slice. Beyond the compliance checklist, template-driven analysis creates the same blind spots sampling does, just shaped differently.
If CI is a customer understanding tool, both sampling and template-only analysis are disqualifying. And customer understanding is where the real value sits.
Every conversation a business has with a customer is that customer telling the business something: what they want, what is broken, what they would pay more for, what is about to make them leave. That signal exists in every call, chat, and email. It does not exist in a monthly QA sample, and it does not exist in a scorecard that only knows the questions it was configured to score. The signal is distributed across the full population of conversations and emerges only when the whole population is actually understood.
What that looks like in practice: churn signals that appear in support conversations three weeks before a customer cancels. Product gaps that show up as the same workaround request on dozens of calls but never make it into a feature backlog. Pricing objections that cluster around a specific plan transition and quietly suppress upgrades. A cohort of accounts expanding for a reason the sales team cannot articulate because the reason is sitting in service calls nobody tagged. These are retention numbers, product roadmap inputs, and pricing decisions. They belong in the C-suite, not on a QA report.
If a vendor's architecture forces them to sample beyond compliance, or to lock analysis into a fixed template, their product is permanently a contact center tool. The signal that would make it a C-suite instrument is sitting either in the 98 percent of conversations the sample never reached, or in the questions the template never anticipated. You cannot buy your way to customer understanding one summary at a time, and you cannot template your way to a question nobody has asked yet.
The useful question in a CI evaluation is not "do you cover 100 percent of calls." Most vendors will say yes, because collection and transcription are cheap. The useful questions are what analysis runs across the full set versus what runs on a subset, and what range of questions the system can answer across the full set versus only inside the pre-built scorecards.
Specifically: does the vendor's reasoning layer and pattern detection run across every conversation, or against a sample pulled out of the full set? If a new question comes up that was not configured at deployment, can the vendor answer it from the existing data, or does it require a new category, a new scorecard, and a new round of training? Does the price scale linearly with coverage, a sign of per-call generative AI costs, or does it scale differently because the architecture is doing different work?
Ask what a full-coverage deployment would cost. Ask what percentage of ingested conversations is actually analyzed end-to-end, not just transcribed. Ask what the system can tell you about a question nobody thought to configure in advance. Ask what findings the vendor can show that depend on full understanding rather than a sampled or templated view. The answers reveal the architecture.
If a vendor tells you sampling is enough, or that their scorecard covers the important questions, they are telling you what their cost structure and their design permit, not what the problem requires. The CallMiner CEO said as much, in print, in 2024. Buyers should take him at his word, and then ask whether that constraint is theirs to inherit.
If you want to see what full understanding looks like without the sampling tax, that is what we built Compass to do, and here is how it compares to CallMiner.
100 percent coverage should mean 100 percent understanding, every conversation read in full and available to any question the business brings. Sampling is a pricing decision made by architectures that cannot deliver full understanding affordably. A product built AI-native from day one changes that math.
