A DesignOps initiative built with Claude Code that transforms unstructured customer call recordings into a structured, searchable insights engine — a brass tacks capability every product-led organization should build.
Outcomes
- Cut insight synthesis from days of manual work to seconds.
- Made customer call conversations visible, structured, and actionable for the design team.
- Shifted the team from reactive shipping to evidence-based design decisions.
- Presented at a company leadership workshop as a model for customer-informed product development.
What was lacking
Product-led organizations talk constantly about being customer-centric. But most design teams have no direct line to what customers are actually saying. Customer conversations happen daily — in sales calls, onboarding sessions, support interactions — and the intelligence buried in those recordings rarely reaches the people designing the product. The gap isn't intentional. It's structural. Zoom to Insight is a brass tacks internal capability that closes that gap — and a reference implementation of something every serious product organization should build.
The Problem
The design team had no reliable way to hear the customer. Customer success calls were happening daily — rich with real frustration, real confusion, and real competitive intelligence — but none of it was reaching the people designing the product. Manual synthesis was the only option, and it required hours of work that nobody had. Worse, the insights that did surface were often filtered through whoever summarized them — introducing bias, losing nuance, and amplifying the loudest voices rather than the most important problems.
The Pipeline
Every product-led organization makes decisions based on customer feedback — but most of that feedback never reaches the people designing the product. Zoom to Insight is a brass tacks internal capability: a synthesis engine that ingests call transcripts from any recording tool and turns unstructured customer conversations into structured, prioritized intelligence. The key architectural decisions were: deliberately separating customer pain points from feature requests, surfacing the highest severity issues first, and structuring each insight around three questions — what is the problem, why should we care, and what should we do about it. Teams that build this kind of infrastructure stop reacting to the loudest voice in the room and start designing from evidence. It's not a nice-to-have. It's the foundation of informed product development.
The Interface
The screenshots below show a whitelabelled reference implementation — the same design pattern any organization could adopt regardless of their product, industry, or stack.
Principle 1 — Filters that pass the lunch test
Internal tools fail when they require users to reorient every time they return to them. For a research tool used intermittently — picked up between meetings, revisited after lunch — the interface needs to communicate its current state instantly. Zoom to Insight uses a single row of AND-logic filters with clear active states, so there's never ambiguity about what's applied. A plain-language confirmation sentence below the filters acts as a second layer of reassurance. You don't need to read the filters to know what you're looking at. The sentence tells you. This pattern is borrowed from interfaces that have validated it at scale — Airbnb's filter controls and Amazon's search results summary both use the same principle: show the user the effect of their choices in plain language, not just in the UI state.
Principle 2 — Scannable list cards
An insights tool is only useful if users can triage quickly. Each list card surfaces the most critical attributes at a glance — which product the insight pertains to, its severity score, and how many times it was mentioned across recordings. Users should be able to scan the full list and immediately identify what demands their attention without opening a single item. The specific attributes surfaced were informed by the questions internal users asked most often — and future usability testing will continue to refine what belongs on the card versus what lives in the detail view.
Principle 3 — Structured insight breakdown
The detail view is where the tool earns its keep. Each insight is broken down across four questions: what is the problem, how big is it, why does it matter, and what can we do about it. Severity scores are determined during the AI analysis phase — issues linked to high churn risk, major competitive disadvantages, or significant ARR impact are ranked highest. This scoring will be refined as the tool is used and validated over time.
Critically, the tool is honest about its limitations. Verbal customer feedback carries inherent bias — customers describe symptoms, not root causes, and the loudest voices don't always represent the most important problems. Zoom to Insight is designed as a tool for informed exploration, not definitive conclusions. It illuminates. It doesn't decide. That epistemic honesty is a design decision as much as a technical one — and it's what makes the insights trustworthy enough to act on.
Impact & Reflection
Where the design team was previously blind to what customers were discussing on calls, Zoom to Insight made those conversations visible, structured, and actionable. Insights that previously required days of manual synthesis were surfaced in seconds. The tool shifted the organizational posture from reactive shipping to defensible, evidence-based design — and demonstrated that a small investment in internal tooling can fundamentally change how a product team makes decisions. The implementation was presented at a company leadership workshop as a model for customer-informed product development.
