Why Gong's Smart Trackers Miss Feature Requests
There are two separate reasons a Gong Smart Tracker misses a request you know was said on a call, and they're not the same problem. First, the tracker might never have scanned that call at all: a Smart Tracker's reach into the past is a setting you choose, not a given, and it has real edges. Second, even for calls the tracker did scan, it's matching against a set of example sentences someone trained it on, and Gong's own activation guidance treats missing roughly one in four genuine matches as good enough to turn on.
Neither of these is a Gong bug. They're how the feature is built, documented in Gong's own help center, and worth understanding before you conclude the tracker "just doesn't work."
Smart Trackers match concepts, not literal words, which is a real upgrade with a real ceiling
Gong actually ships two kinds of trackers, and mixing them up is the first source of confusion. Keyword Trackers match exact words verbatim. Set one for "SSO" and it fires only on that string. Smart Trackers are the newer, AI-driven kind: per Gong's own docs, they "identify concepts, rather than words" and "recognize intent and surface concepts in conversations, even when people use different words and phrases," illustrated with a tracker trained on "asking for a discount" that also catches "is that the best you can do?" (see Understanding Trackers).
That's a genuine capability, and it's the reason teams reach for Smart Trackers over the keyword kind for anything as loosely worded as a feature request. It's also where the confidence in the marketing outpaces what the mechanism actually promises. A Smart Tracker doesn't understand your product; it recognizes sentences that resemble the ones it was trained on.
What "trained" means, in Gong's own numbers
Building an example-based Smart Tracker means feeding it real sentences pulled from real calls. Gong's minimum is low: "give at least 5 examples of real sentences from real calls that fit this concept." The catch is what that minimum is measured against. The concept needs to already show up in "at least 50 calls" in your dataset for the model to have enough signal, and Gong recommends 500 recorded calls as a floor, with 1,500 called out as ideal for the best results.
Before you activate a new tracker, Gong shows a sample performance overview and tells you what's fine to ship: "15 of the 20 sentences in the Performance overview match your concept." That's a 75 percent recall bar, stated as the acceptable threshold for turning a tracker on, not an edge case. A team that trains a tracker on five polished examples, sees it clear that bar on a 20-sentence sample, and flips it live has built something that, by Gong's own math, is expected to miss close to a quarter of the sentences that actually belong to the concept. The Smart Tracker FAQ is candid about the reason: "people don't always say things the way we expect them to," which is exactly the paraphrase your tracker was supposed to solve.
One practitioner backs this up from the user side. In the Smart Trackers deep dive thread on Gong's own community forum, Vik Ekambaram advises splitting a broad concept like "churn" into narrower trackers (financial churn, budget churn, product churn) because "the more calls we have, the more accurate the smart tracker." Elsewhere in that same thread, Andrew Aurilio, a new-participant member of the community, reports the opposite experience: even after building out his trackers, he's "finding the results to be a bit lower than expected (and, of course, much lower than the sales reps believe it should be)." A tracker that hasn't accumulated much matching call volume yet, or one trained on a handful of examples that all use the same vocabulary, is working exactly as designed and still leaving requests uncounted.
issue filed·
report writtenThe other reason: the tracker never looked at that call
Separate from matching quality, there's a scope question. When you first publish a Smart Tracker, Gong asks whether to "apply only to upcoming calls, or include calls from the past 1, 3, 6 months, or 1 year." That's a real backfill option, and it's easy to click past without thinking, since the default framing is forward-looking. Skip it, and the tracker's history starts at zero. Every call recorded before you hit publish is permanently outside its reach, no matter how the request was phrased.
It gets narrower still after that point. Per the Smart Tracker FAQ, when you edit a live tracker's training examples or terms to fix a known gap, "the updated tracker applies only to new conversations and to historical conversations within the backfill window you select (14 or 30 days)." So the fix you make today for a request you noticed being missed doesn't reach back and find the other times it was probably said months ago. It only helps starting now.
How Ines traced a missed request back to a publish-day setting
Ines Duarte runs product at Anchorline Dynamics, a scheduling platform for field-service teams. In a pipeline review, a sales engineer mentions offhand that a prospect asked whether technicians could reassign a job from the mobile app mid-shift, not just from the dashboard. Ines checks the "mobile reassignment" Smart Tracker her team set up two months ago. Zero hits.
She listens to the call herself and confirms it: the prospect said it plainly, twenty minutes in. So she checks when the tracker was created and how it was scoped, and finds the answer. The tracker was published with the default "upcoming calls only" setting, and the call in question happened three weeks before that date. It was never in scope to begin with; no amount of retraining would have caught it after the fact.
She fixes the scope going forward and adds two more training examples using the prospect's exact phrasing, then asks the sales engineer to flag any other calls he remembers this coming up on, since none of those are searchable by tracker either. "I assumed 'we built this two months ago' meant it covered everything since we started recording calls," she tells her team in the retro. "It only covered calls from the day we clicked publish."
Where this stops being a Gong problem and starts being a rollup problem
None of the above is a reason to avoid Smart Trackers. Scoped correctly and trained on a real spread of phrasings, they're a reasonable way to flag a known concept going forward inside Gong. Where the approach runs out is the same place most single-source tools do: a tracker only ever answers for Gong. The same request that missed the tracker because of unusual phrasing might show up cleanly, in plain words, in a support ticket two weeks later or a Slack thread with a different account entirely. Gong has no way to connect those, because it only sees what happens inside Gong.
That's the point where we'd bring up Modem, and we're upfront that it isn't a better transcript-miner. It doesn't out-parse Gong's own AI on a single call, and it isn't trying to. What Modem does is read the transcript from your connected Gong workspace as calls come in, alongside Slack, support tickets, and email, and treat every mention of a request as one more data point on a running topic, matched by what was actually asked rather than by a fixed set of trained phrasings. A request that a Smart Tracker missed because it was worded unusually can still land in the same topic as five other mentions from other channels, because the matching isn't limited to one tool's training set. It's a wider net at the cost of Gong's own call-level polish, not a replacement for it.
Two related guides worth reading: how to search every Gong call for a feature request, not just one, which covers Trackers and Ask Anything's search limits in more depth, and the six best tools to mine product feedback from sales calls, which compares Modem's Gong integration against Chorus, Productboard, and Enterpret directly.
Two questions to ask about every tracker you have
Pull up every Smart Tracker your team has built for feature requests and ask two questions of each one:
- What backfill window was it published with?
- How many training examples is it actually running on, against Gong's five-example minimum?
Most teams find at least one tracker sitting on the default upcoming-only scope with three or four examples nobody's touched since setup. Neither answer takes more than a few minutes to check, and fixing both won't recover what already went unscanned. It just stops the same gap from opening up again next quarter.
