Gong Lab
Designed and built an AI-powered customer research tool that turns hours of Gong research into detailed analysis in minutes.
Client
Internal Tool
Category
Design + Development
Team
Christina Bazydlo
Year
2025
Impact
This tool fundamentally changed how I approach UX research. What previously required hours of searching and listening now takes minutes. I can input a keyword, define a date range, and receive a structured report tailored to the specific questions I need answered.
When colleagues in Customer Success saw the tool, they immediately saw applications for their own work. What began as a way to accelerate a single project is evolving into something the broader team can use. At a small startup, tools that help us work more efficiently have real impact.
The Problem
I'm the only product designer at StackHawk. Currently we are without a product manager, and we've never had a UX researcher, so much of that responsibility falls on me. I actually appreciate digging into the research side because it helps me deeply understand the problems and pain points our customers are facing.
Problem Statement
I needed a way to search Gong across all customers by keyword and analyze findings by my own parameters. Gong's AI only allowed analysis by individual customer, and manual extraction was too time-consuming.
I was in the middle of redesigning our API Discovery experience and needed direct insight into what customers were saying. The only option was to search Gong by keyword, listen to each call individually, and manually extract the relevant insights. The process was time-consuming and inefficient.
Gong does have AI capabilities, but they only operate at the individual customer level. I needed to analyze patterns across our entire customer base. A colleague in Support shared the same frustration. We kept coming back to the same question: there has to be a better way to do this.
The Process
I used Claude Code to build an application that could search by keyword across all of our Gong transcripts and generate a report based on specific criteria I defined.
An engineer helped me configure the API keys and authentication so the app could connect to Gong and retrieve transcripts. From there, I worked with Claude Code to create agents that pull the relevant data and analyze it according to the parameters I set.
Why browser-based: Claude Code initially created a terminal-based app, but I pushed for a browser interface instead. I had my Customer Success colleagues in mind as potential users, and I knew they'd be intimidated opening a terminal. A browser felt more approachable for non-technical team members and made the output easier to read and share.
Debugging the unknown: Getting the first analysis to run wasn't smooth. I hit multiple errors and had to debug the app several times. I opened a debug window, fed Claude Code the errors, and worked through each issue until it finally worked. This was part of the learning process of building something outside my usual skillset.
Key Decisions
Start with my own needs: The first version didn't have role-based presets at all. I built it purely for myself, creating a report structure based on what I wanted to know as a product designer. Only after it worked for me did I think about expanding it.
Role-based presets: Once I saw the value, I created a separate analysis template for Customer Success. The insights a designer needs differ from what CS needs. I'm still gathering feedback from CS colleagues on how they'd actually use this and what analysis would be most valuable to them.
Markdown downloads: I specifically wanted the reports to be downloadable as markdown files. This wasn't arbitrary—it's how I work. I use markdown files as context files for problem-solving in Claude Code, and I share them with engineers to give them background on design decisions and user research. Having the Gong analysis output in the same format I already use for documentation made it immediately useful and easy to integrate into my existing workflow.
Ship, then refine: Claude Code initially generated a single Python file. As the tool evolved, I worked with an engineer to restructure it properly. The priority was getting something working first, then improving the architecture later.
Learnings
My approach to AI is practical. If the tool I need doesn't exist, I'll create it. I'm a designer, but I'm also a builder. I don't see a barrier between what I do and what would traditionally fall into an engineer's lane. AI makes that possible, and I intend to keep using it that way.
Next Steps
This is still a work in progress and a side project, but I have a clear vision for where it's going:
- User-defined analysis: This came directly from feedback from a CS team member. Right now the app runs preset analyses based on role, but users want to define their own report parameters and output. The next iteration will give them control not just over the keyword search and date range, but also what type of information and analysis they get back.
- Gather more feedback: I'm still learning how CS colleagues would actually use this day-to-day. Their input will shape what presets and features matter most.
- Better UI: The current version was built purely for function. I'd like to design something more polished now that the core functionality is proven.