The Gong transcript is not the insight

Every sales call your company runs is recorded now. Gong sits on the line, transcribes it, files it. A year of that is thousands of conversations with the people who pay you, fully searchable, sitting in a system. And your product team still cannot tell you what customers asked for last week.

The gap has a familiar shape. Someone in product wants to know how often a competitor comes up, or which objection is spreading, and the only way to find out is to ask the data team, who go and read calls. Retool's data team wrote up exactly this: the recurring question, the manual dig, the answer that lands days later as a number no one can check. So they built the obvious thing. A self-serve app over the Gong API: pick a date range, search a keyword, get the matching calls with counts, click through to the transcript, ask a model to summarize. Real progress. The data team stopped being the help desk for "how many times did someone say X."

A search box only answers what you already suspect

Look at what that app can answer. It answers the questions you already know to ask. You have to walk up to it holding "competitor X" or "pricing objection" in your head. The insights that actually move a roadmap are the ones nobody thought to search for: the phrase three enterprise accounts started using this month, the objection that only shows up in deals that later stall, the feature request quietly changing shape. A search box is a mirror. It shows you what you brought to it.

That is the ceiling of search, and it is a low one. The most valuable customer signal is definitionally the signal you were not looking for, so a tool that requires you to name it first can never surface it. You do not know to search "procurement is now asking for SOC 2 in the first call" until it has already cost you a quarter.

Put simply: a keyword search only returns what you already suspected. Fund the insight nobody thought to query, or you will keep confirming your priors and calling it customer research.

The Gong API hands you rubble

The reason this stays hard is not the model. Ask the Gong API for a call and it does not give you an insight. It gives you rubble to rebuild.

POST /v2/calls/transcript returns a transcript as a list of sentence fragments, each tagged with a speakerId and a timestamp, in an order you have to trust. Concatenating them into something a person can read is step zero, and mapping speakerId to an actual human, on a known side of the table, is a join you do yourself. The account, the deal, the stage, the dollars: none of that is in the transcript. It lives in your CRM, Salesforce for most teams, and Gong only points at it. A separate POST /v2/calls/extensive call carries the CRM associations behind GET /v2/calls/manual-crm-associations, the tie between a call and the Salesforce account or opportunity it belongs to.

Even the verbs tell you what the thing is for. Transcript and extensive are POSTs that take a body of filters and call IDs, not GETs you point at one call:

POST /v2/calls/transcript
{ "filter": { "fromDateTime": "2026-07-01T00:00:00Z",
              "toDateTime":   "2026-07-31T23:59:59Z" } }

The API expects you to pull a month at a time and process it downstream, not to look up a single conversation. It is a firehose you are expected to catch, structure, and keep.

So the raw material of voice of customer is exactly that: raw. A pile of speaker-tagged sentences on one side, a CRM on the other, and nothing joining them.

Put simply: the Gong API is a bulk firehose, not a lookup desk. Build a scheduled pull that reassembles, keys, and stores every call, not a query box you visit when you remember to.

Four moves from voice to signal

Turning that rubble into "accounts worth six figures in renewal are raising the same objection, and it started three weeks ago" is not a summarization job. It is a data job, and it has four parts.

Reassemble and resolve. Stitch the fragments into whole turns, attach each turn to a named person, and label whether that person is the customer or your own rep. This sounds mechanical and it is, but skip it and every downstream number counts your own team's words as customer voice. Filter to the other side of the table first, or you will report your own objections back to yourself.

Code the free text. A transcript is unstructured on purpose; people do not talk in schema. The work is turning "it's just gotten too pricey for what we actually use" into a labeled thing: topic pricing, type objection, in the customer's own words. This is the part that does not exist in the structured world of dashboards and SQL. It is a taxonomy problem, and the taxonomy has to be adaptive, because the objection that matters next quarter is not on today's list. A fixed set of keywords is the mirror again. The point is to catch what you did not name.

Key every line to the money. A labeled objection with no account behind it is a tweet. The same sentence means one thing from a churning trial and another from your largest renewal. Joining each utterance to the account, the ARR, the deal stage, and the segment, all of which live in Salesforce and none of which live in Gong, is what turns a quote into a weighted signal. It is the join the transcript endpoint pointedly does not do for you.

Historize it. The most useful question in voice of customer is "what changed," and you cannot answer it from a snapshot. You answer it by keeping every call keyed and dated, so you can watch a topic climb, or a phrase appear, or an objection cluster inside the deals that later go dark. A model summarizing this week's calls on demand is a search engine crawling at question time: slow, expensive, and different every time you ask. The answer that lands in a standup is the one computed ahead of time, from data that was structured before anyone asked.

Put simply: turning talk into signal is four data jobs, not one model call. Resolve the speaker, code the text, key it to the ARR, and historize it, or your insight is an unweighted snapshot nobody can act on.

The pipeline is a cascade of summaries

Clean keyed rows are the foundation. The system you build on them is a cascade of model calls, each one summarizing the level below, landing in two tables.

Start at the call. A model reads each transcript once and writes a structured summary: the use cases, the objections, the competitors named, the sentiment, each in the customer's own words and each carrying the quote that backs it. Regenerating that summary is expensive and reading it is cheap, so you store it rather than re-derive it.

Then you blend, and this is the record that did not exist before. One row per call in a reporting mart, joining three things that normally live in three systems: the raw transcript, the model summary, and the Salesforce quant, meaning the account, the ARR, the stage, and the eventual win, loss, or churn. A single row now holds what the customer said and what the deal did. Embed the transcript and the summary into the same table and it is a vector index too, so you can query it by meaning, "who sounded nervous about implementation time," not just by keyword.

Then you roll up, and this is the move that makes it scale. You do not re-read ten thousand transcripts every morning. You summarize the summaries. A model reads the day's call summaries and the day's quant deltas and writes one daily row: what changed, weighted by dollars, with the receipts underneath. That row lands in the second table, one per day. A week of daily rows rolls into a weekly, a month of weeklies into a monthly. It is a map-reduce over time, and it is lossy on purpose: each level is a summary of summaries, trading completeness for signal, so a wrong summary early poisons everything above it. That is exactly why the next part is not optional.

Put simply: summarize each call once, blend it with the Salesforce quant into a vector-indexed call-level mart, then roll daily summaries up into weekly and monthly. You summarize summaries, not transcripts, which is the only way it scales to thousands of calls.

An agent writes the digest

The two tables are inert until something reads them and decides what matters. That is an agent, and it runs on a schedule: daily, weekly, monthly. It reads the aggregate row for the period, pulls the quant it needs, picks the few things worth anyone's attention, and writes them as short, punchy posts, closer to a tweet than a report, into the Slack channel where the team already works. Every claim links down to the calls that produced it, so the receipts are one thread away.

It earns its keep on the blend. On its own, "customers keep mentioning onboarding" is a vibe. Joined to the quant it becomes "onboarding friction is up this week, in three renewals worth $520k, and two of them just slipped a stage." The daily catches the live one. The weekly ties what customers said to what they did: the deals won, lost, and churned, and the net win rate. The monthly shows the trend and what to do about it. One agent, one channel, holds go-to-market, product, and the executives to the same high-signal picture, and none of them has to open a dashboard.

I build this at Funston. Here is the daily digest catching a live one, keyed to the account and grounded in the calls, with the receipts one thread away:

And the weekly, rolling four dailies into what customers said and what they did:

Put simply: the last mile is an agent that turns the aggregate tables into short, grounded, Slack-native posts on a daily, weekly, and monthly cadence. It holds the whole company to one customer reality at a signal-to-noise ratio a dashboard never reaches.

The shortcut that fails

By now the tempting version is obvious, and it is the one most teams reach for first. Skip all of this. Connect an AI agent straight to the Gong API, or to the Gong integration, and just ask it what customers are saying. Point a capable model at the calls and let it work the rest out. Plenty of tools are sold on exactly that promise.

It fails for every reason this post has laid out. The agent inherits the same rubble the API hands anyone: fragmented sentences, unresolved speakers, no Salesforce join, no taxonomy, no memory of last week. So on every question, at question time, it has to reassemble the transcript, guess who was talking, hunt for the account and the ARR, invent a category on the spot, and it still cannot tell you what changed, because nothing was kept. It is the search box again in a smarter accent. It answers what you knew to ask and stays blind to the rest.

And it fails for a deeper reason I have written about on its own: an agent answering from raw calls is doing just-in-time what the pipeline should have done ahead-of-time. Resolving speakers, keying to Salesforce, coding a taxonomy, rolling up thousands of calls: none of that is work you want a model improvising fresh on every prompt. Done live it is slow, it burns tokens by the thousand, and it returns a different answer each time you ask. Done ahead of time, the agent has almost nothing left to do but write the sentence. That is the whole trick. The agent is the last mile on top of a warehouse that already did the heavy lifting, not a way around building one.

Put simply: you cannot shortcut the pipeline by wiring an agent to the Gong API. It inherits the rubble and does the structuring just-in-time, which is slow, inconsistent, and blind to the past. The good answer was computed ahead of time; the agent only delivers it.

The part you cannot skip

Two things keep this honest, and no model gives you either for free.

The first is grounding. Every claim the system makes has to carry a link back to the utterance that produced it, so a skeptical PM can click and hear the customer say it, the way the Retool app deep-links every match back to the Gong call and the Salesforce account. An insight you cannot trace is a rumor with a chart.

The second is evaluation. The danger with a taxonomy over free text is not the obvious wrong label, which anyone catches. It is the confident, plausible miscount that quietly steers a roadmap. So you need golden question-and-answer pairs, run against the taxonomy every time it changes, the same eval discipline any serious agent needs. Change one prompt or add one competitor to the list and last quarter's numbers can move underneath you. The taxonomy is code. Treat it like code.

None of this is Gong's job, and none of it is the model's. The recording is a commodity and the summary is a commodity. What compounds is the layer in between: the structured, keyed, historized, grounded record of what your customers actually said, accruing in your own systems where a competitor with a bigger model still cannot copy it. It rhymes with the bottleneck moving off the code, and with the context layer being the product. The voice was never the scarce thing. The structure around it is.

I work on data tooling at Retool, so I watch teams hit this wall in a specific order: they buy the recording, they build the search, and then they find the search only answers what they already suspected. The wall is always the same one, and it is never the model.

Put simply: link every number to the sentence that made it, and test the taxonomy like code. An insight an exec cannot click into is a rumor, and a taxonomy without evals quietly rewrites last quarter.

The receipt

So the next time someone says the customer told us what they wanted, ask the smaller questions. Told whom, worth how much, and starting when. A company that records every call and cannot answer those does not have a recording problem. It has a structuring problem, and the recording was the easy part.

Put simply: if you record every call, you have already bought the data. Structuring it costs less than the tool that captured it, and it is where the answer actually lives.