How to connect Gong call feedback to the Zendesk tickets from the same account
Gong ties a call to an account through Salesforce, matching the moment a participant's email belongs to a known contact or lead. Zendesk ties a ticket to an account the same way, matching the requester's email domain against a list of domains you set on the organization record. Both matches happen automatically, and both happen without any awareness that the other one exists. A renewal call with an account and a support ticket from that same account can sit in two systems that each correctly identify who it's from, with nothing that ever compares the two.
So the honest answer is that no native connector does this for you. What connects a Gong call to the right Zendesk tickets is a person who already knows the account name, searches for it in Zendesk, and reads what comes back, or a habit of writing the account name into whatever the call gets logged as so a later search finds it. Below a certain volume of calls and tickets, that habit is enough. Past it, the two records of the same account drift apart, and whoever needs both has to remember to go looking for the one they don't have open.
Where each tool already does its job correctly
Neither tool is careless here. Gong's Salesforce export documentation describes activity syncing "when at least one external participant matches a Salesforce contact or lead," which is the entire matching mechanism: no participant match, no linked record. Once matched, installing the Gong for Salesforce app adds a dedicated Gong Conversation object, carrying the recording, a transcript when available, and Gong's own topic and tracker analytics, per Gong's documentation on the Salesforce app.
Zendesk does the equivalent with organizations. The Organizations API reference is explicit that you can "manually assign customers to an organization or automatically assign them to an organization by their email address domain," using the domain_names field on the organization record. A ticket then carries an organization_id describing "the organization of the requester," per the Tickets API reference, which is likely why, once a requester's email domain matches an organization, their tickets tend to show up as that organization's tickets in views, in Explore, and on the ticket itself.
Both mechanisms work well for what they were built to do. Gong resolves the sales side of an account. Zendesk resolves the support side. Neither one was built with the other in mind, and nothing downstream fixes that gap either: Linear's Customer Requests documentation lists Intercom, Zendesk, Front, Salesforce cases, Slack, and Linear Asks as sources that can create a request automatically. Gong isn't on that list. A request pulled from a Gong call has to be created by hand, with the customer picked from a dropdown, which means it inherits the exact problem it was supposed to solve: it only happens if the person on the call remembers to do it.
How the connection gets made without a connector
The workable version of this, before you're reaching for another tool, is small and specific: whenever a call surfaces something worth flagging, whoever writes it up searches Zendesk for the account's domain or organization name before posting anywhere. If open or recent tickets turn up, the write-up names them. If Zendesk turns up nothing, the write-up should say that directly: a request with no matching ticket history reads differently than one where three customers already complained about the same thing in support.
Wes Faulkner has carried the Halcyon Freight account through two renewal cycles at Fernbridge, and by now he knows the account's quirks better than most of the support queue does. Halcyon runs its fleet dispatch on Fernbridge, so when something breaks for them it usually surfaces first on a call, not a ticket. On this renewal call, Halcyon's ops lead brings up something that's been bothering their team for a while.
Halcyon Freight (ops lead): Every time a driver reassignment happens mid-route, the old stop list doesn't clear. Dispatch has to manually zero it out or the ETA math gets thrown off for the rest of the day.
Wes: That's the first I'm hearing it phrased that way. Let me check what's already open on your account before I write this up.
Wes searches Zendesk for organization:"Halcyon Freight" and finds ticket #5188, filed six weeks earlier by a different Halcyon dispatcher, describing the same stop-list behavior in less precise language: "ETAs looked wrong after we swapped a driver." Nobody had connected the two, because the support agent who closed #5188 as "needs more info, no repro" had no reason to know a renewal call would later describe the identical bug more clearly. Wes reopens #5188, adds the call's description as an internal note, and links both in the account's shared doc: one call, one ticket, one bug, instead of two half-formed reports that each read as unconfirmed.
That reopening only happened because Wes thought to search before writing anything up. The system didn't do it, and there's no guarantee the next account manager checks Zendesk before posting, or that a support agent thinks to search Gong transcripts before closing a vague ticket as unreproducible.
The point where this habit breaks down
The habit works as long as one person can reasonably hold the account in their head: a handful of calls, a handful of tickets, one or two people who touch both systems. It stops working for three predictable reasons as volume grows.
- Nobody owns both sides of every account. A support agent triaging fifteen tickets a day has no reason to check Gong for a renewal call that happened last week, and an account manager reviewing a call has no standing reminder to check Zendesk before writing anything up.
- Search only works if the account name matches exactly. Halcyon Freight, Halcyon, and HF Logistics are the same customer to a person and three different strings to a search bar.
- The connection, once made, lives in one place. Wes's note in the shared doc helps Wes. It doesn't surface for the next support agent who reopens a related ticket for Halcyon Freight three months later, unless they happen to read the same doc.
Past a few dozen accounts, the habit that held at ten stops holding, and the failure mode is specific: a renewal call flags something that's already a known, recurring support issue, and the account team finds out only when the customer brings it up again, annoyed that it wasn't already on someone's radar.
How Modem changes this
This is the exact seam we built Modem to close. Modem watches connected Gong calls and Zendesk tickets, resolves the people on each side into the same company record instead of two separate ones, and groups what they say into topics that carry every mention regardless of which tool it came from. A renewal call mentioning Halcyon Freight's stop-list bug and a Zendesk ticket describing the same thing land under the same topic and the same company automatically, without anyone searching for a domain name first. Full disclosure: Modem is our product, so read this section with that in mind. The manual habit above works fine as long as an account team can hold every account in their head; once that stops being true, automatic rollup starts earning its cost, and not much before.
Two related guides worth reading alongside this one: how to keep the customer account attached to a feature request after it leaves Gong covers the same drift on the sales side alone, and how to connect Zendesk tickets to Linear issues without losing customer context covers what happens once a ticket needs to reach engineering.
One habit to add this week
Pick the handful of accounts your team cares most about, and add one step to the renewal-call write-up habit. Search Zendesk for the account's organization name before posting anywhere, and name any matching tickets in the write-up. Add the mirror step on the support side too: when a ticket looks like it might be a repeat, check whether a recent Gong call mentioned the same account. Neither step takes more than a minute, and the first time a reopened ticket saves someone from re-diagnosing a bug that was already described on a call, the habit sticks on its own.
