Search what customers actually say across your Gong calls

Build me an internal app my go-to-market team can open to answer "what are customers actually saying about X?" without asking a data analyst and without needing a Gong seat of their own. It reads from Gong and shares to Slack. The audience is sales, customer success, and marketing, so every screen should be readable by someone who has never seen Gong's own UI.

The main screen is a search surface. At the top: a date range picker, a keyword input, a row of saved keyword group chips, and an "external speakers only" toggle that is on by default. Tapping a keyword group chip searches every keyword in that group at once rather than making the user type them one at a time. Seed the saved keyword groups from Gong using List Trackers, so any keyword tracker or smart tracker the company already maintains shows up as a group on day one, and let the user create, rename, and edit their own groups on top of those.

Results render as a table of calls, one row per call, with a match count per call. Columns: call title, account, rep, call date, and match count. The table is sortable on every column and filterable by rep, account, and call date. Use List Calls Extensive for the call metadata and for tracker or topic matches inside the date range, and List Users Extensive to resolve the rep user IDs on each call into real human names. Show the total number of matching calls and the total number of calls in the range side by side, since the ratio is the number people actually care about.

Clicking a row opens a drawer over the table. The drawer shows the call metadata (title, date, duration, account, rep), the participant list with job titles so the reader can tell whether the person speaking was a champion or an economic buyer, and the full transcript from Get Call Transcripts with every keyword match highlighted inline. Include a jump-to-next-match control so a long call is navigable, make the transcript text selectable and copyable, and put a deep link at the top that opens the call back in Gong.

A second tab is a trends view for marketing. Chart mentions over time across the selected date range, mentions as a percent of total calls in each period (so a spike in mentions is not confused with a spike in call volume), and a breakdown by keyword group. The point is to see the moment a competitor or an objection starts showing up more often, so make the time series the hero chart and let the user switch the granularity between week and month.

Add an embedded background agent behind a "Summarize selected" button. The viewer checks several calls in the results table, hits the button, and the agent reads those call transcripts and writes a synthesis back into the app covering use cases, unmet needs, objections, and competitor mentions, quoting the customer's own language rather than paraphrasing it into corporate speak. Every point it makes should name which call it came from so a reader can click through and verify. While the agent runs, show the finding in a pending state in the app so the viewer knows work is happening and can navigate away.

Each saved synthesis stays in a Findings list in the app, with its title, the keyword or group it came from, the date range, the number of calls behind it, and who ran it. Each finding has a Share button that posts it to a chosen Slack channel using Send a Message, formatted for Slack rather than dumped as raw markdown, with a link back to the finding in the app. Populate the channel picker with List Channels so the user chooses from real channels instead of typing an ID.

Saved keyword groups and findings persist per workspace, not per user, so the team builds a shared library over time. Anyone who opens the app sees the groups their colleagues curated and the findings they already ran.

One important performance constraint: Gong rate limits API access to roughly 3 requests per second and 10,000 requests per day per company. Do not fetch transcripts on every keystroke. Debounce the keyword input, fetch call metadata for the date range first, and pull transcripts in batches only for the calls in the current result set, caching transcripts that have already been retrieved so repeat searches over the same date range are fast and cheap. Handle a rate limit response by backing off and retrying rather than failing the whole search, and show clear loading progress when a wide date range is being indexed for the first time.