How to tell if the customer emailing support is your biggest Stripe account
You can't tell by looking at the ticket. Zendesk shows you a name, an email, and whatever the requester typed; it has no idea what that person pays you. The only way to know whether "hey, quick question about our export" came from a $50/month trial or the account carrying a third of your MRR is to go check Stripe yourself, or to have already wired something that checks for you.
Checking by hand takes under a minute once you know where to look, and that's the first half of this guide. The second half is what happens once your support volume makes checking by hand for every ticket impossible.
What a support ticket actually gives you
A Zendesk ticket has a requester email, a subject line, and a body. Unless your team has manually added a custom field for account tier or attached organization tags, that's the entire signal. Nothing about plan, spend, or tenure rides along with the ticket by default, because Zendesk doesn't bill your customers, Stripe does, and the two systems have no reason to talk unless you connect them.
That gap is exactly why a small market of Zendesk-Stripe connector apps exists. A Zendesk-Stripe connector app called Stripe Connector, built by eOne Solutions rather than Zendesk itself, pulls a customer's Stripe record into the ticket sidebar, showing contact and billing details, charge and refund history, open disputes, invoices, and active subscriptions without leaving the ticket. A written breakdown of the setup describes the point of it plainly, agents "stop tab-switching to the Stripe dashboard" to answer a billing question. That app is built for billing support specifically (refunds, disputed charges, subscription changes), but the same sidebar view answers the "how big is this account" question as a side effect, since the subscription and its price are right there.
Doing the lookup yourself
If you're not running a connector app, the manual version is one search. Stripe's Customer Search API supports an exact match on email:
GET /v1/customers/search?query=email:'warrick@vantagelabs.io'or the equivalent in the Dashboard's search bar, which runs the same query underneath. Either way returns the Stripe customer record for that address, and from there you expand into their subscriptions to see the plan and price they're on.
What you won't find is a single field that says "this is your 3rd biggest account." Stripe's customer object carries a balance, a subscription list, and metadata; it does not carry a running lifetime-spend total or a rank against your other customers. You're reading a plan name and a monthly amount, then holding that number against whatever you already know about your top accounts, a pinned list, a spreadsheet, a dashboard. The lookup tells you what they pay. Whether that makes them "biggest" is a comparison you're still doing in your head.
One thing worth checking before you trust the match: the email on the ticket has to be the same one Stripe has on file. A billing contact and the person who emails support are often different people at the same company, and Stripe's customer record won't cross-reference an org chart to catch that for you.
That search bar is the same tab-switch the connector's pitch above promises to remove. Fine to do once in a while; harder to justify once it's the tenth ticket that day.
The ticket that turned out to matter
Vantage Labs is a warehouse automation startup, and it runs its sensor fleet on Fielding Robotics, a device-monitoring platform billed monthly through Stripe. Warrick Doyle handles operations there. On a Tuesday morning he emailed Fielding's support address:
Warrick Doyle, Vantage Labs: Our webhook deliveries for offline-sensor alerts have been arriving 8 to 12 minutes late since yesterday. Is something degraded on your end? We're paging our ops team off these.
The ticket landed in Zendesk looking like any other integration complaint, no tier flag, no account note. The support engineer on call, Mei Sato, had never worked a ticket from Vantage Labs before and had no reason to think it was urgent beyond the content of the message itself. She pasted Warrick's email into Stripe's search bar, found the customer record, and expanded the subscription: Scale plan, $4,200/month, billed since the prior January. A quick check against the team's revenue notes confirmed it, Vantage Labs was Fielding's single largest account by MRR.
That context changed how the ticket got handled. Mei looped in an engineer immediately instead of queuing it behind two lower-priority tickets ahead of it, and replied to Warrick with a real ETA instead of a holding message. The webhook delay turned out to be a queue backup from an unrelated batch job; it was fixed within the hour. Nothing about the fix required knowing Vantage Labs' plan. The order it got worked in did.
Why this breaks down as volume grows
The one-search version above holds up fine for a five-person support team fielding a few dozen tickets a week. It breaks down for reasons that show up predictably as volume grows:
- It depends on someone remembering to check. Nothing on the ticket prompts the lookup; a busy agent skips it, especially on a ticket that doesn't read as urgent on its own.
- It's a manual step per ticket, which scales linearly with ticket volume and doesn't survive a support team bigger than the number of people who've memorized the top accounts.
- The revenue number lives in Stripe while the routing decision happens in Zendesk, so even a diligent agent is doing a context switch and a mental comparison every single time.
That's the point where teams stop relying on someone checking Stripe by hand and start pushing the answer into the ticket automatically. The Stripe Connector app covers the billing-support half of that (refunds, disputes, subscription edits). For the routing half, knowing an account's size the moment their ticket lands so it can be prioritized alongside everything else that account has said, we build Modem, and Modem's Stripe integration is built around exactly this resolution step. It matches a Stripe customer to the same person and company record Modem has already built from Slack, GitHub, and every other connected tool, so plan and revenue context sits on the account itself rather than in a tab you have to open. Billing events, new subscriptions, cancellations, a trial about to end, can also trigger automations, so a downgrade or a churn-risk signal doesn't depend on someone stumbling across it. We build Modem, and it's the option this guide is pointing toward, so the comparison should be stated plainly. Wiring the Stripe Connector plus your own tagging discipline costs less up front and asks more of your team every day after; Modem costs more to set up once and then keeps making the connection on its own.
The smallest version worth setting up
If a connector app or a context tool is more than you need today, the cheapest fix that beats checking by hand: keep a short, static list of your top 10 to 20 accounts by MRR, pinned somewhere every support agent can see it before they open a ticket. It won't catch every edge case, a new account that jumped tiers last week won't be on it, but it turns "who is this" from a Stripe search into a five-second glance for the accounts that matter most. Related reading: how the same billing events feed into product prioritization, and what happens on the other side of the portal when one of these accounts schedules a downgrade instead of emailing support.
