Most companies do not have a voice problem. They have a workflow problem. Voice data sits everywhere, but insights fail to reach the people who need them. Shankar Krishnan, a product leader at AWS working on voice AI and conversational analytics products, has seen this pattern repeat across contact centers, healthcare, and field operations. This column lays out a practical approach to bring conversational analytics into your company without turning it into another underused tool.
Where voice is already critical, and who your ICP really is
Voice is the most natural medium for high-stakes conversations in enterprises, the moments where misunderstandings cost money, where customer sentiment changes outcomes, and where compliance risk is real. You typically see voice as mission-critical in customer support, back office operations (insurance claims is a classic example), front office functions (sales and marketing), and field support (equipment repair, maintenance, on-site service). That “where” immediately points to “who.”
There are usually two primary user groups for a Voice AI or conversational analytics product:
- Knowledge workers who live inside conversations: contact center agents, doctors, wealth management advisors, field support specialists. For them, the promise is direct productivity gains, better customer experience, and fewer compliance mistakes.
- Supervisors and business leaders who need aggregated insight. It could be department heads, QA managers, operations leaders, product owners. They care less about individual calls and more about trends, recurring issues, coaching opportunities, and product-level insights that can change strategy.
If you don’t name the primary ICP early, you’ll end up building a product that tries to satisfy everyone, and delights no one. The best teams choose one “hero” persona first, and only then expand.
Separating the platform layer from the product layer
A major reason conversational analytics initiatives stall is that teams blur two different things:
- Voice AI infrastructure (the platform capabilities): speech recognition, speaker diarization, channel identification, text-to-speech (TTS), real-time processing, latency and reliability controls.
- Conversational analytics as a product layer: insights, workflows, dashboards, integrations, and the UX that turns signals into decisions.
Voice AI infrastructure has broad reuse across the enterprise. The same core primitives, transcription, diarization, channel identification, TTS, can power customer support, sales enablement, clinical notes, and internal meetings. That’s why the most scalable approach is typically a centralized platform team that offers these building blocks as a flexible internal service.
Also Read: How Shopify Uses AI to Power Growth for 2 Million Businesses
Then individual business functions, customer support, sales, operations, build their own UX and workflows on top: dashboards, coaching tools, alerts, quality programs, and automation triggers that match their domain.
This separation gives you two advantages that show up quickly in practice: you avoid reinventing the same audio pipelines in every department, and you deliver a more consistent experience across the company (the same quality of transcription and diarization, the same privacy baseline, the same reliability).
Choosing the first use case and the metrics that matter
Your first use case should be concrete: persona plus workflow plus problem. A strong starting point is improving contact center agent productivity, because it’s measurable, high-frequency, and has clear operational KPIs.
There are three early product moves that often create value fast:
- An AI-powered voice agent for routine questions, reducing the burden on human agents.
- Real-time assistance for agents, helping them respond faster and more accurately while the call is still happening.
- Reducing after-call work by automatically generating call summaries and structured notes.
These map to metrics that most support organizations already track and care about:
- Deflection rate (how many interactions never reach a human)
- Average handle time (AHT)
- Average time spent on after-call work
- Customer satisfaction score (CSAT)
- Cost per call
- First call resolution (FCR)
Pick a small number of these upfront and commit. Conversational analytics becomes “real” inside a company when you can say: we reduced after-call work by X% and improved FCR by Y%, without increasing cost per call.
Defining the minimal scope, and what comes next
A lot of teams want to start with full GenAI summaries, suggested actions, and real-time agent assist. In practice, the minimal scope that gives you a stable foundation is usually speech transcription.
Transcription is the backbone for almost everything else: post-call analytics, summarization, sentiment, topic clustering, coaching signals, and real-time assistance. It also gives you an important product advantage: you can add “heavier” capabilities on demand, instead of paying for expensive processing on every single call.
From a product sequencing point of view, a common path looks like this:
- Start with transcription (real-time and/or batch)
- Add post-call analytics
- Add GenAI summaries and recommended actions
- Add real-time agent assist
- Add voice agents
Technically, there are two viable approaches for post-call insights and summaries: either analyze call recordings directly with a large language model, or transcribe first and then send the transcript to an LLM for processing. For real-time agent assist, the system streams transcription increments to an LLM along with well-designed prompts, so the agent receives timely cues that improve productivity and reduce mistakes.
The product point is simple: begin with the layer that is foundational and controllable, then add value on top in a way that keeps costs predictable.
Data, redaction, and governance that compliance can approve
Conversational systems touch some of the most sensitive data an enterprise has. If your data policy is vague, the project dies in procurement and security review.
A solid baseline looks like this:
- No storage by default without permission. Customer data should not be stored without explicit authorization.
- No training without explicit consent. Processed data should not be used to train models unless the customer has clearly opted in.
- Encryption everywhere. Audio recordings and real-time audio streams should be processed and stored with strong encryption.
A clean operational model that compliance teams tend to support is: store audio, transcripts, and insights in the customer’s own account. That gives the customer control over retention duration, access permissions, auditability, and internal policies.
This also pushes you toward a thoughtful data model: what objects exist (call, segment, speaker, transcript chunk, summary, insight), which roles can access which fields, what gets redacted, and what the audit log needs to record. If you map this early, you prevent costly re-architecture later.
Making adoption feel natural through workflow integration
If conversational analytics becomes one more dashboard, adoption stays low. Put insights in the tools your teams already use. Send summaries and action items into your CRM and ticketing system. Write structured outputs into your data lake for BI reports. Stream real-time cues to the agent desktop during calls. Make the workflow seamless so your users do not switch screens.
A practical integration plan is a two-step pipeline:
- Receive audio plus metadata from communication systems (contact centers, telephony, meeting platforms), including identifiers like customer ID, agent ID, queue, call reason, timestamps, and channel info. Audio may be processed in real time or as a recording.
- Send structured insights into downstream systems (CRM, ticketing, BI, data warehouses). Use schemas and formats those systems already accept.
For real-time features like agent assist, insights need to be available instantly. That usually means writing outputs into a fast store (often a NoSQL database) so they can power low-latency applications during the call.
For post-call use cases, a structured data lake with a well-defined schema enables on-demand querying, reporting, and batch exports into CRM and analytics tools. The product decision here is not “database choice,” but “how do insights become usable in the tools that already run the business?”
Running a focused pilot that de-risks both market fit and technical risk
The point of a pilot is not to prove that the model works in a lab. It’s to prove that the product works in a real workflow — with real stakeholders, real constraints, and real variability in data.
A good pilot is specific:
- Clear success metrics
- Defined duration
- A controlled feature set
- Implementation support plan
- A pricing approach (typically free access during beta)
For B2B products, keeping the pilot to a manageable set of customers (often no more than ~50) is a practical constraint: it’s hard to support more and still get timely, high-quality feedback. A time-boxed window (for example, 30 days) creates urgency and focus.
During the pilot, capture every friction point: integration challenges, latency spikes, mismatches between outputs and supervisor expectations, edge cases that break accuracy, and the “trust gaps” where users ignore or override AI recommendations. Those are not minor issues, they are your roadmap.
When the pilot ends, you should be able to answer two questions with confidence:
- Did we move the operational metrics we promised (deflection, AHT, after-call work, CSAT, cost per call, FCR)?
- Can we scale this with predictable performance, controllable cost, and a governance model that legal/compliance will approve?
If you can answer “yes” to both, you’re no longer experimenting with conversational analytics. You’re bringing it into the company as a product that can actually grow.
