Which accounts open the most tickets relative to what they pay

It is the second week of the quarter. The VP of Customer Success has a renewal forecast to defend, and someone on the exec team has asked a question that sounds simple: which of our accounts are expensive to serve?

Two people go looking. The RevOps analyst opens Salesforce and builds a report on Accounts: ARR, contract start date, renewal date, owner, tier. It runs in four seconds and it is correct. The support operations lead opens Zendesk Explore and builds a report on tickets: volume by organization, first reply time, full resolution time, satisfaction, reopens. It also runs in four seconds and it is also correct.

Then they get on a call and try to put the two things side by side. The Salesforce report has 412 accounts. The Zendesk report has 380 organizations. Roughly 300 of the names look like they match. Nine of them are some version of "Northwind", because Northwind Logistics, Northwind Logistics Ltd and Northwind (EMEA) are three separate Zendesk organizations and one Salesforce account. Somebody exports both to CSV. Somebody writes a VLOOKUP. By Thursday there is a tab called cost_to_serve_v3_FINAL and nobody fully trusts it, including the person who built it.

That spreadsheet gets rebuilt every quarter. That is the actual problem.

What Salesforce shows on its own

Salesforce knows what an account is worth, and it knows it precisely. Contract value, product mix, renewal date, upsell history, open opportunities, the owner, the segment, the health score field somebody dutifully updates. If your question is commercial, Salesforce answers it well, and the reporting is genuinely capable: joined reports, bucket fields, row-level formulas, cross filters. This is not a weak product.

Where it stops is at the boundary of its own object model. Salesforce sees support activity only to the extent that support activity has been written into a Salesforce record. If you run Service Cloud, that is a lot. If your support team lives in Zendesk, it is close to nothing. There may be a synced ticket-count field, populated nightly by an integration, showing 47. Forty-seven of what? Created this quarter or open right now? Including the eleven that were duplicate password resets? The number is in Salesforce, but the meaning of the number is not.

And there is a second, quieter limit. Salesforce can tell you an account filed a lot of tickets. It cannot tell you those tickets were about one broken data export that a single engineering fix would end. That distinction is the whole decision, and it is not in any field.

What Zendesk shows on its own

Zendesk knows what happened in support, in detail and with good instrumentation. Explore will give you ticket volume by organization, by channel, by group, by tag, by requester. It will give you first reply time, full resolution time, agent touches, reopen rate, CSAT, and it will trend all of it over time. If your question is operational, Zendesk answers it well.

Where Zendesk stops is money. It has no idea what an account pays. Organizations in Zendesk exist to route tickets and scope agent visibility, not to hold contract terms. You can push an ARR field onto the organization via the API, and plenty of teams do, but then you own a value that goes stale the moment a contract is amended in Salesforce, and no one notices until a QBR.

So Zendesk can rank organizations by ticket volume perfectly. The top of that list is almost always your largest customers, because large customers have more users, and more users file more tickets. Raw volume just re-sorts your book of business by size. The interesting number is the ratio, and Zendesk holds only the numerator.

Why the gap is structural, not a missing feature

Look at the two halves of the evidence and notice they are different kinds of thing.

ARR is a record. It is a number in a field, put there deliberately, governed, auditable. Ticket count is also a record: a row per ticket, timestamped. Both are structured, and structured data joins to structured data. That part is a data engineering problem with known solutions.

But the half that decides the answer is not a record at all. It is the description field, the agent's internal note, the fourteen-message thread where a customer explains that the CSV export has been dropping the final row since the March release. That is a sentence somebody wrote. It has no schema. It was written to be read by another human, once, and then closed.

This is why "cost to serve" is not a report that Salesforce or Zendesk forgot to build. Both products are complete within their own domain. Neither is missing a feature. The evidence for the answer is split across two systems that were correctly designed to hold different things, and one half of it is prose.

It is worth being precise about the neighbouring tools too, because they are also good and also not built for this. Zapier and Make will connect Salesforce and Zendesk reliably, and a lot of teams should use them to do exactly that. But automation platforms are trigger based: something happens, and records move forward. A trigger fires when a ticket is created. There is no trigger for "what has the last ninety days looked like across four hundred accounts", because that is not an event, it is a question about the past. Meanwhile BI tools, Looker's conversational layer, Power BI Copilot, will do a beautiful job the moment both halves are in the warehouse as modelled tables. Their honest constraint is upstream: they read databases and modelled sources, so a sentence an agent typed into a ticket at 4pm is not something they can see at all, only something a pipeline could have summarised for them beforehand, and usually nobody built that pipeline.

What the join actually requires

Two separate pieces of work, and they are not the same difficulty.

The key. The reliable join is domain based. Zendesk requesters have email addresses; the domain of the address maps to a Salesforce account far more dependably than a name match ever will. Zendesk organizations even support a domain mapping field for exactly this reason. Name matching, the thing the spreadsheet does, is what produces the three Northwinds. Domain matching handles the merged-entity case, the trading-name case and the localised-spelling case in one move. It needs care around shared consumer domains and around resellers who file on behalf of end customers, but it is a tractable, checkable rule.

The judgement. Once the two sides are joined, you have tickets-per-thousand-dollars-of-ARR, and it will tell you something you did not know. It will not tell you what to do. A logistics account at four times the median rate could be three different situations:

• One reproducible bug, filed repeatedly, which engineering could close permanently
• A team that never got onboarded properly and is using support as training
• A genuinely heavy user of a complex product, which is what usage looks like when it is going well

The first is an engineering ticket. The second is a CSM conversation. The third is not a problem at all and is possibly your best expansion signal in the book. Telling them apart requires reading the tickets. Not counting them, reading them, and noticing that eleven of the nineteen say some version of the same thing.

That reading step is the part the spreadsheet never does, and it is why the spreadsheet gets rebuilt every quarter and still does not change anyone's mind.

How you would answer it with Skopx

Skopx connects to nearly 1,000 SaaS tools, Salesforce and Zendesk included, and you ask it questions in chat. It reads across both, and the reading part is the point: it can pull ticket volume and it can pull what the tickets say.

The sentence someone actually types looks like this:

For every account with more than $20k ARR, pull ticket count and total handle time from Zendesk for the last 90 days, match Zendesk organizations to Salesforce accounts by email domain, and show me the ten with the highest ticket volume per $10k of ARR. For each one, read the ticket subjects and tell me whether the volume looks like one recurring issue or general usage.

You get back a ranked list with citations: each row links to the Salesforce account and the specific Zendesk tickets behind the number, so when the VP asks where 19 came from, you click through instead of defending a formula. The pattern reading is a summary, not a metric, and it is presented as one.

If that turns out to be a question you ask every quarter, describe it once more and Skopx will build a standing console around it, which is what Internal Apps does: you type a sentence, it builds the console. The version most teams end up with shows a ranked table of accounts by tickets per $10k ARR, a column for renewal date so you can see which of these are decisions due in the next sixty days, the recurring-theme summary per account, and a drill-down to the underlying tickets. It reads live from both systems each time it loads, so it is current rather than a snapshot. And because it can act as well as read, there is a button on each row that opens a Salesforce task for the account owner, which asks you to confirm before it does anything.

Honest limits

The console reads and it acts, and it stores nothing. There is no form, it does not create records on a schedule, it does not run overnight, it does not alert you, and it does not produce a public link you can send to someone outside the workspace. The only thing it writes is what you click a button to write, after confirming. If you want a persistent metric with history, that belongs in a warehouse, and this is not one.

The domain match is a rule, and rules have edges. Resellers, agencies filing for clients, and support addresses at parent companies will need a manual mapping you maintain somewhere. Skopx will show you the unmatched organizations rather than quietly dropping them, but somebody still has to decide what they are.

The pattern reading is a judgement made by a model reading ticket text. It is good at spotting that eleven tickets are about the same export bug. It is not an auditable classification, and you should not build a QBR slide on it without opening the tickets it cites. That is precisely why the citations are there.

And the ratio itself is a starting point, not a verdict. High cost to serve on a growing account can be a good sign. The number tells you where to look, and then someone still has to look.

Team is $16 per seat per month and includes 2.3 million AI tokens per seat. Solo is $5. SOC 2 controls are in place, and per-viewer permissions mean a CSM sees the accounts they own and not the rest of the book.