How to Avoid Filing the Same Feature Request Five Times from Five Different Gong Calls
No, not on its own, and the reason is structural rather than a missing setting. Gong's trackers and its Ask Anything search both operate inside Gong, so they can tell you a concept came up, even how many times it came up across your team's calls, but neither one has any visibility into Linear, Jira, or whatever tracker your ticket actually lands in. Nothing inside Gong knows a ticket for "mobile shift-swap approval" already exists, so nothing stops a second rep, or a third, from filing another one after their own call.
The fix has to live outside Gong. It's either a habit your team enforces before anyone opens the tracker, or a tool that reads across calls, reps, and the tracker itself to catch the collision before it becomes five open issues. Here's the mechanics of why Gong can't do this natively, what a manual habit looks like, and the volume where that habit stops holding.
Why Gong can't see this coming
Gong's Trackers do aggregate, to a point. Under Insights > Team > Trackers, Gong shows how often a concept has been mentioned across your team's calls in a given period, per the platform's own documentation on trackers. That count is real and it's useful for spotting that something is trending. What it isn't is a list of accounts with a status next to each one saying "filed" or "not yet filed." Every mention Gong counts stays a separate, unlinked occurrence at the call level; the aggregate is a number, not a working queue.
Ask Anything has the same blind spot from the other direction. It answers a question you ask it about calls and emails Gong has recorded, capped depending on scope: up to 100 calls for a broad query, 60 calls and 500 emails for a specific deal or account, or 10 calls and 80 emails for a specific contact, per Gong's Ask Anything documentation. Nothing in that documentation describes a way to create, merge, or check against a ticket in an external tracker. You can ask Ask Anything "which calls mentioned mobile shift-swap approval this quarter" and get a real answer, but the answer doesn't know whether someone already turned three of those calls into three separate Linear issues last month.
Gong's own automation options confirm the gap rather than closing it. The Gong app on Zapier ships exactly one trigger: "New Call," which fires when a call finishes processing, with no tracker-level or mention-level event to hook into. A team wiring Gong to a tracker through Zapier is working with call-level events, not "this specific concept came up again," which means even a well-intentioned automation can't check for an existing ticket before creating a new one. A call-level event carries no mention to check against.
Put together, Gong can tell you something was said, and how often, inside Gong. It cannot tell you whether that something already has a ticket, because it was never built to look at your tracker at all.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionA manual habit that holds, below a certain volume
Under maybe a dozen Gong-sourced requests a month, a team can catch this by discipline instead of tooling:
- Search the tracker before filing, not after. Before creating a ticket from a call, spend two minutes searching the tracker for the plain-language version of the ask. If something close already exists, add a comment naming the new account and stop there.
- Tag Gong-sourced tickets consistently. A single label like
source:gongmakes every ticket that came from a call groupable, so a periodic sweep can scan just that slice instead of the whole backlog. - Give trackers a home in the ticket description. If your team also runs a Gong Tracker for the concept, link it in the ticket. It won't dedupe anything by itself, but it means the next person who finds the ticket can check the tracker's mention count instead of guessing how common the ask is.
Once a duplicate is found this way, the job is to merge it without losing the account behind it, not to close it and move on; how to handle duplicate feature requests covers that merge step directly. And because a good chunk of the underlying miss is Gong's tracker matching itself, not just the filing habit, why Gong's Smart Trackers miss feature requests is worth reading alongside this one; a tracker that never fired on one of those calls is a tracker no later search would have surfaced either.
Where the habit stops working
The search-first habit depends on someone remembering to do it, on every call, every time, and on the plain-language search actually matching how the ticket was originally worded. "Mobile shift-swap approval," "approve swaps from a phone," and "can't approve without sitting at a workstation" are the same request, but a keyword search for one of those phrasings doesn't reliably surface a ticket filed under a different one. Past a couple dozen Gong-sourced tickets a month, across enough AEs that nobody has visibility into everyone else's calls, the habit starts missing a percentage every cycle, and the gap is invisible until a customer asks why something they raised twice never shipped.
Reading the calls themselves beats relying on five different people each remembering to check. Modem is built to work at the mention level, not the call level. Modem's Gong integration reads the transcripts and participants from your recorded calls and groups every mention by what was actually asked, whether that phrasing was "mobile approval," "approve from a phone," or "not at a workstation," rather than by which words the tickets happen to share. It matches the same way across Slack, support tools, and email too, so a request that came up on a call and again in a support ticket lands as one topic with both accounts attached, not two unconnected signals. Before the next ticket gets filed, the earlier mentions already sit on the same topic, each with its account and quote attached, so what a rep sees is the list of accounts that already asked instead of a blank tracker search. We make Modem, so this is not a neutral ranking. Below the volume where a search-first habit still catches everything, the manual version is a perfectly fine place to stay.
A weekly fifteen-minute sweep of Gong-sourced tickets
Pick one label, source:gong or similar, and require it on every ticket created from a call starting today. Then put a fifteen-minute recurring block on the calendar, once a week, for one person to search the tracker for every open Gong-sourced ticket's main noun and flag anything that looks like an overlap. A search for "mobile" or "shift swap" run the same week those tickets get filed surfaces the overlap in days, instead of whenever someone next happens to search the right word; the one phrasing the search still misses is exactly the kind of gap a weekly sweep can't close on its own.