How to keep the customer account attached to a feature request after it leaves Gong
Gong already knows which account asked. It matched the call to a Salesforce record the moment a participant's email matched a known Contact or Lead, and the record it lands under, the Account or the Opportunity, carries the account name and the deal behind it. What doesn't happen automatically is the next step: someone reading the call, deciding it's worth flagging, and typing it up somewhere product actually looks. That typing is where the account and the dollar figure usually fall off, because the write-up is a sentence in Slack or a ticket description, not a link back to the CRM record Gong already built.
Keeping the account attached means making two things mandatory at write-up time: the account's actual name, not "a customer," and a number that says how much it's worth, not a vague "enterprise" tag. Below a certain volume you can enforce that by habit. Past it, you need something that carries the link forward on its own, because habits are exactly what erodes first when a rep is typing fast between calls.
What Gong keeps attached, and how
The linkage starts with plain CRM matching, not anything Gong invented for this purpose. Gong's Salesforce export docs describe activities syncing over "when at least one external participant matches a Salesforce contact or lead." That's the whole mechanism. No participant match, no linked record.
Once matched, the record can carry real detail. Installing the Gong for Salesforce app adds a Gong Conversation object, and Gong's own documentation lists what it holds: the call recording, call metadata, "Gong analytics, including topics, trackers, and interaction stats," next steps, and a full transcript when available. Sitting under that Opportunity, a rep or a product manager with Salesforce access can open the record and see exactly who said what, on which account, tied to whatever deal value lives on that Opportunity.
That's the part that works without anyone doing anything extra. The part that doesn't is getting any of it out of Salesforce.
Where it breaks: the write-up
Product teams mostly don't have Salesforce logins, and a Gong Conversation record has no reason to be forwarded there on its own. So the account and deal context makes its way out the way it always has: a person reads the call, decides it matters, and writes a sentence about it somewhere else. That sentence is where the specificity dies.
"A customer asked about bulk export again" is a perfectly normal way to phrase it under deadline, and it is also useless six weeks later when someone tries to count how many accounts have asked and how much revenue sits behind the ask. The Enterpret guide to mining Gong calls puts the underlying problem plainly: "a flag on one opportunity carries no weight until you know how often it recurs, in what words, and behind how much revenue." A flagged call and a written-up request are not the same thing, and the gap between them is exactly the step that depends on someone remembering to type the account name and a figure instead of a shrug.
Linear already built the fix. Gong isn't one of its sources.
The frustrating part is that the tool many product teams already use has a feature built for exactly this. Linear's Customer Requests attaches a request to an issue with a customer record behind it, and that customer record can carry revenue and tier, so a request shows up as more than an anonymous line: "10 requests, 4 enterprise" is the kind of count the feature is designed to produce.
The catch is how a request gets created. Linear's docs describe requests generating automatically from Intercom, Zendesk, Front, Salesforce cases, Slack messages, and Linear Asks. Gong does not appear on that list. A request pulled from a Gong call has to be created by hand, with Ctrl+R or the + Customer Request button, picking the customer from a dropdown every time. That's not a broken feature. It's a feature that was never wired to this particular source, which means it inherits the same weakness as the plain write-up: it only works if the person on the call remembers to do it, every single time, for every single mention.
The account renewal at Trestle Insurance
Trestle Insurance sells underwriting software to regional carriers, and Owen Garrity has managed the Anchor Fidelity account for two renewal cycles. On a call about their upcoming policy audit, someone on Anchor Fidelity's ops team mentions, almost in passing, that pulling every bound policy for one agent still means downloading PDFs one at a time.
Anchor Fidelity (ops lead): We're going to be doing this again for the state audit in the fall. Right now someone spends half a day exporting one agent's policies for a quarter, one file at a time.
Owen: Got it, I'll flag that for our product team.
Owen posts to the shared feedback channel afterward:
Owen: Heads up, a customer mentioned wanting bulk policy export for audits. Worth a look?
Nadira Selkirk, VP of Product at Trestle, sees it two days later. She has no way to tell from the message which account it was, whether it's a $40,000 account or a $400,000 one, or whether this is the first time someone's asked or the fourth. She replies asking Owen to confirm the account name, and by the time he does, three days have passed and neither of them thinks to open Linear and log a Customer Request against it. It sits in the channel as a message, not a count.
A month later, a different rep mentions almost the same request from a different account in a separate thread. Nothing connects the two. Nadira has two data points that should be one theme with two accounts and a combined deal size behind it, and instead she has two Slack messages that don't know about each other.
A minimum discipline that holds, for a while
Below a few dozen Gong-sourced requests a month, you can hold this together with rules instead of tooling:
- No write-up without the account name. Not "a customer," the actual name, every time, no exceptions for a quick flag.
- Attach a number, even a rough one. ARR, deal size, or plan tier. "Enterprise" alone tells you less than you think once you're comparing three requests against each other.
- Log the Customer Request in the same sitting. If Linear is where the count lives, the two-minute manual step happens right after the call, not after someone gets around to it.
This works because someone is enforcing it, which is also exactly why it stops working once volume outpaces what one person can enforce.
Where this stops working
Past a few dozen mentions a month spread across calls, Slack, and support tickets, the discipline above starts losing a percentage of requests every cycle, and nobody notices which ones until a customer asks why something they raised twice never showed up. That's the point where it's worth reading the source directly instead of relying on a human relay.
That's the category Modem works in. Modem's Gong integration reads transcripts and participants from your recorded calls and matches the people on the call to the same people and companies it already sees in Slack, support tools, and email, so the account doesn't depend on someone typing the name correctly in a Slack message afterward. When a request gets filed, it creates issues from conversations with the customer quotes and user stories included, tied to the account and any others who've raised the same thing, in one prioritized view. We build Modem, so weigh the recommendation with that in mind. If your volume is still small enough that the discipline above catches everything, it's a fine place to stay.
Two guides worth reading next: how to handle duplicate feature requests, on merging the same ask once it's arrived from more than one place without losing any of the requesters, and the complete guide to Linear Customer Requests, for setting up the native feature well for the sources it does cover.
The smallest version you can start this week
Add one line to whatever template your team uses to write up a call: account name, required; a dollar figure or tier, required. That alone stops the "a customer asked" problem cold. It won't dedupe anything and it won't catch what nobody bothers to write up at all, but it fixes the specific failure in Nadira and Owen's exchange. The account existed, and got typed as a shrug instead.
