Which orders generated a support ticket: reporting across Shopify and Zendesk

It is the second Tuesday of the month. The head of ecommerce has Shopify Analytics open on one screen: 4,180 orders last month, average order value up 6 percent, returning customer rate flat. On the other screen, the support lead has Zendesk Explore open: 610 solved tickets, first reply time under three hours, CSAT at 91.

Someone on the call asks a question that sounds like it should take ten minutes. We shipped the new packaging in week two. Did orders after the switch generate more support tickets than orders before it?

Nobody can answer. Not because either person is missing a report, but because the question spans both screens and neither screen knows the other exists. Shopify knows what was sold. Zendesk knows who complained. Neither knows which order the complaint was about, because the thing that connects them is a sentence a customer typed into an email at eleven at night.

What Shopify shows on its own

Shopify's reporting is genuinely strong on the commerce record. Sales by product, by variant, by channel, by discount code. Returning customer rate. Fulfilment timing, including how long orders sat before they were marked fulfilled. Refunds, both count and value, broken down by reason if your team fills the reason field in. Order timeline entries show every status change with a timestamp, and you can segment customers by order count, spend, tags, and location.

You can also see, per order, whether it was refunded, cancelled, or had a return created. That is real signal about problems.

Where it stops is precise: a refund is the outcome, not the cause, and most support contact never produces a refund at all. A customer who emails asking where their parcel is, gets a tracking link, and receives the parcel two days later leaves no trace in Shopify. The order is fulfilled. It looks identical in every report to an order nobody ever wrote about. Shopify's data model has no field for "this order caused a human to ask a question", because that event happens entirely outside Shopify.

What Zendesk shows on its own

Zendesk Explore is a capable analytics product. Ticket volume by channel, by group, by assignee, by hour. Resolution time, reply time, reopens, satisfaction scores. If your team applies tags consistently, you get volume by tag: shipping, damaged, sizing, returns. You can build a dashboard that shows exactly which categories are growing and which agents are drowning.

Where it stops is also precise. A ticket knows its requester's email address. It usually does not know an order number in any structured field, unless someone typed one into a custom field, and in practice that field is populated on a minority of tickets because the customer did not include one and the agent was busy. Even when a Shopify sidebar app shows the agent that customer's recent orders, that is a lookup for the agent's convenience during the conversation. It is not a stored join, and it does not flow into Explore as a dimension you can group by.

So Zendesk can tell you 610 tickets were solved and 84 were tagged shipping. It cannot tell you those 84 tickets came from 84 orders, which SKUs were in them, or what those orders were worth.

Why the gap is structural, not a missing feature

Here is the shape of it. One half of the evidence is a record. The other half is a sentence somebody wrote.

Shopify's half is a record with a primary key. Zendesk's half is free text written by a stranger under mild frustration. The order reference, if it exists at all, is inside a paragraph, sometimes as #10428, sometimes as 10428, sometimes as "the blue mugs I ordered last Thursday".

That is why this is not a reporting feature either product forgot to build. Shopify would have to read Zendesk prose to know an order caused contact. Zendesk would have to reliably extract a key from unstructured customer writing to attach itself to an order. Both products correctly draw the boundary at their own data.

It is also why the usual tools do not close it. Automation platforms like Zapier and Make are excellent at what they do, and what they do is trigger based: an event fires, a record moves forward, a ticket gets created or a tag gets applied. That machinery runs forward in time. It cannot be pointed backward at last month and asked what already happened across 4,180 orders and 610 conversations. BI tools have the opposite constraint. Looker's conversational analytics and Power BI Copilot both answer questions in plain language against databases and modelled sources, and they do it well. But a customer's sentence about a crushed box is not a modelled source. It is evidence that lives in a body of text, outside what those tools can see at all.

What the join actually requires

Two separate things, and it is worth being clear that they are different problems.

The key is email address, with order number as a stronger confirmation when it appears. Zendesk stores the requester's email as a structured field; Shopify stores the customer email on the order. That gets you from a ticket to a person, and from a person to their orders. Where a customer has one order in the window, the match is unambiguous. Where they have four, email alone gets you to the wrong order three times out of four, and you need the order number from the ticket body, or the ticket's timestamp read against the order and fulfilment dates, to pick the right one.

The judgement is what no key can do. A ticket that says "can I add a second one to my order" is not a problem with that order. A ticket that says "still hasn't arrived, this is the third time I'm writing" is a serious one. A ticket that says "love these, do you make them in green" is a compliment sitting in the same queue. Tags help when they are applied, and they are applied inconsistently, particularly on the busy weeks you most want to analyse. Deciding which tickets represent an order that went wrong means reading them, not matching them.

How you would answer it with Skopx

Skopx connects to nearly 1,000 SaaS tools, including both Shopify and Zendesk, and you ask it questions in chat. The realistic sentence someone types on that Tuesday call is close to what they said out loud:

Pull last month's Shopify orders and last month's Zendesk tickets. Match tickets to orders by customer email, using the order number in the ticket when there is one. Then read each matched ticket and tell me whether it was a problem with the order or not. Show me the ticket rate for orders placed before 12 March and after, and group the problem ones by what actually went wrong.

What comes back is a number with its working shown: contact rate before and after, the SKUs that concentrate the problem tickets, and the ambiguous matches flagged rather than quietly counted. Every figure cites the orders and tickets underneath it, so when someone disputes the packaging finding, you open the twelve tickets it rests on and read them.

Once you have asked that question three months running, you stop asking and build the console. In Skopx you describe it in a sentence and get a working internal app: orders in the period with a ticket-linked column, contact rate by SKU, the problem tickets grouped by theme, and each row expandable to the customer's actual words. Row-level permissions mean the support lead sees what they should and a regional manager sees their region. The one write action is a button an agent clicks with a confirmation, for example applying a Zendesk tag to a ticket the console has classified. Nothing is created, nothing is stored, nothing runs on a schedule.

Honest limits

This does not make Shopify or Zendesk store the link. Nothing is written back except the one confirmed button action, so tomorrow's orders arrive with the same gap and the join is recomputed when you next ask.

The matching is not perfect and should not be presented as though it is. A customer who orders on a work email and writes in from a personal one will not match. A returning customer with several open orders and no order number in the ticket is a genuine ambiguity, and the right output is a flag, not a guess. Expect a small tail of unmatched tickets in any real month, and treat the contact rate as a well evidenced estimate rather than an audited figure.

The reading step is a judgement, and judgements can be wrong. It will occasionally file a pre-purchase question as a problem or miss sarcasm. That is why the citations matter more than the summary: the number is the starting point of the conversation, not the end of it.

It is also not an alerting system. There is no scheduled run, no watcher, no notification when contact rate rises. Someone opens the console and looks, or asks the question again in chat. If you want the honest version of the value here, it is this: the answer goes from nobody has it to fifteen minutes, and then to a page you open. That is the whole claim.

Team is $16 per seat per month with 2.3 million AI tokens included. Solo is $5. SOC 2 controls are in place.