OPERATIONS · RETENTION · ANALYTICS · 13 JANUARY 2026 · 6 MIN READ
Support volume as a product signal
Every ticket is a customer paying you in their own time to report a defect. Most stores treat that as a cost to reduce rather than the cheapest research they will ever get.
Which parts of your store failed to answer a question the customer needed answered. A ticket is not a random cost; it is a specific person telling you, at their own expense, that something on the site was missing, wrong or not believable. Categorised by the question rather than by the channel, support volume points directly at product page gaps, delivery information you are not showing, sizing guidance you do not have, and payment or checkout defects that analytics records only as an abandonment. The stores that get value from this treat volume as a measurement; the ones that do not treat it as a cost and buy a chatbot.
IN SHORT
- A support ticket is a defect report from someone motivated enough to file it, which makes it higher-signal and cheaper than almost any research you could commission.
- Categorise tickets by the question the customer was asking, not by the channel they asked it through — the channel breakdown is a staffing report, not a product one.
- Normalise by orders, not by month: tickets per hundred orders is the only figure that stays meaningful when volume changes.
- Shopify’s return reasons are a closed set — colour, defective, not as described, size too large, size too small, style, unwanted, wrong item, unknown and other — and size too large and size too small being separate values makes sizing problems directly readable.
- The "other" return reason requires a note, which is where the information that does not fit your categories actually lives.
- Self-serve returns and cancellations from the order status page reduce the tickets you receive without reducing the reasons people had for sending them — so instrument the self-serve path or you lose the signal.
- The most expensive tickets are the ones that never arrive, because the customer left instead of asking.
Volume is a measurement wearing the costume of a cost
Support is budgeted as an expense, staffed against volume, and measured with operational metrics — first response time, resolution time, tickets per agent. All reasonable, and all of it answers the question "are we handling this efficiently?" rather than "why is there this much of it?".
The second question is the valuable one, because inbound volume is a survey nobody had to design and customers self-selected into. They were motivated enough to stop what they were doing and write to a company. Compared with a usability test on five recruited participants, or a survey with a response rate you would rather not publish, that is exceptionally good data, and most stores throw it away by resolving each instance and recording nothing.
The change required is small and organisational rather than technical: a taxonomy, someone whose job it is to read the aggregate monthly, and a route from that reading to the development backlog. Without the third, the first two become a report nobody actions.
Categorise by the question, not by the channel
Most helpdesks are organised around handling: channel, agent, priority, status. That organisation cannot answer a product question. The categorisation that can is the one that records what the customer wanted to know.
A workable starting taxonomy, deliberately short — a scheme with forty categories is a scheme nobody applies consistently:
- Where is my order? Delivery status, timing, and anything about tracking.
- Will this work for me? Sizing, compatibility, materials, specification — questions the product page should have answered.
- How do I change or cancel it? Post-purchase edits, address changes, cancellations.
- It went wrong. Damaged, missing, wrong item, faulty.
- I want to return it. Process questions, not the return itself.
- It would not let me. Payment failures, discount codes rejected, checkout errors, account problems.
- Something else. Kept genuinely small, and read carefully, because this is where next year’s category is hiding.
What each category is actually reporting
The point of the taxonomy is that each bucket maps to a different owner and a different fix.
"Where is my order?" is rarely a logistics problem. It is usually an information problem: the customer was not given a date they believed, or the tracking they were sent does not update in a way that reassures them. The fix is almost never faster delivery — it is a delivery date shown before purchase and a post-purchase experience that keeps the promise visible. This category is also the one most inflated by a store that hides its shipping policy until checkout.
"Will this work for me?" is a product page audit with the answers already filled in. Every one of these tickets names a specific piece of information a specific page failed to provide, for a customer who cared enough to ask. The ones who did not ask bought elsewhere. Read a month of these against the product pages they refer to and the backlog writes itself.
"How do I change it?" is a self-service gap and generally the cheapest to close, because the capability largely exists. Shopify supports self-serve returns and cancellations from the order status page, and customer accounts let a buyer track orders and submit return requests.
"It would not let me" is the most urgent and the most under-reported. For every customer who writes to say their card was declined or their code was rejected, an unknown number simply stopped. These tickets are the only direct evidence you get of a class of failure that analytics records as an ordinary abandonment, and they deserve a route straight to engineering rather than a macro.
Return reasons are a closed vocabulary, which is exactly why they work
Returns carry a structured signal that support tickets do not, because Shopify constrains the vocabulary. The documented return reasons are colour, defective, not as described, size too large, size too small, style, unwanted, wrong item, unknown, and other — with the "other" value requiring an accompanying note.
That list is worth reading as a diagnostic key rather than an admin field. Size too large and size too small are separate values, and the split matters: a product returning consistently as "too small" is a sizing guidance problem with an obvious fix, while returns spread evenly across both directions suggest inconsistent manufacturing or a fit that is genuinely hard to communicate. "Not as described" and "colour" are photography and copy problems. "Defective" is quality or packaging. "Unwanted" is the one you can mostly do nothing about, and knowing which of your returns are that is worth as much as the rest.
The caveat is that the reason is chosen by whoever creates the return, which means the data quality depends on your process. If agents default to "other" because it is quicker, you have a free-text field pretending to be a category. If they default to "unwanted" because it avoids a conversation, you have a diagnostic that says nothing is ever your fault. Both are common, both are fixable in an afternoon of agent guidance, and both quietly waste the only structured return data you have.
And read the "other" notes. They are unstructured, nobody enjoys them, and they are consistently where the problem you have not named yet is described in a customer’s own words.
Running it so it survives contact with a busy quarter
Three habits are enough, and each of them fails without the others.
Normalise by orders. Tickets per hundred orders, not tickets per month. Raw volume moves with trading and tells you nothing; the ratio tells you whether the store is getting better or worse at answering its own questions. Track it per category, because the total hides the interesting movement.
Review the aggregate monthly, with a named owner. One person, one hour, reading a month of categorised volume and the free-text of whatever was unclassifiable. The output is a short list of candidate changes with the ticket count attached, which is the form in which support insight actually competes for development time.
Instrument the self-serve path. This is the one people miss. Every self-service improvement removes tickets, and removing tickets removes the signal. If customers are cancelling orders themselves from the order status page, that is a better experience and a silent one — so count those events alongside the tickets, or you will conclude that a problem went away when in fact you stopped hearing about it.
What we would talk you out of
Buying a chatbot to reduce volume. Deflection is not resolution. A bot that answers "where is my order?" quickly is genuinely useful and is also a device for not fixing the reason people ask — and once it is in place, the signal you would have used to fix it is gone. Deploy the automation after you have read the volume, not instead.
Making deflection rate a target. Measure it, do not incentivise it, because the fastest way to raise it is to make asking a human harder. That improves the metric and worsens the business.
Treating support as a department rather than a research function. The practical version of this: if nobody on the product or development side has read actual tickets in the last quarter, the categorisation exercise is already pointless.
The honest summary is that support volume is the cheapest research most stores own and the least read. It requires no tooling investment, no research budget and no experiment design — only a short taxonomy, a monthly hour, and a willingness to treat the resulting list as a backlog rather than an anecdote.
Questions this raises
What can support tickets tell you about your store?
Which questions your store failed to answer. Categorised by the customer’s question rather than by channel, tickets point directly at missing product page information, delivery expectations you did not set, sizing guidance you do not have, and checkout defects that analytics only records as abandonment. It is the cheapest and most specific research most stores already own.
How should support tickets be categorised?
By the question being asked, in a deliberately short taxonomy — where is my order, will this work for me, how do I change it, it went wrong, I want to return it, it would not let me, and something else. Channel and priority breakdowns are staffing reports. A scheme with forty categories will not be applied consistently enough to be readable.
What do Shopify return reasons tell you?
More than most merchants use. The documented set is colour, defective, not as described, size too large, size too small, style, unwanted, wrong item, unknown and other. Size too large and size too small are separate values, so a consistent skew in one direction is a sizing guidance fix, while "not as described" and "colour" point at photography and copy.
Is falling ticket volume a good sign?
Only if you know why. Self-serve returns and cancellations from the order status page remove tickets without removing the reasons customers had for raising them. Count self-service events alongside tickets, or you will read a change in how people contact you as a problem being solved.
How do you measure support volume meaningfully?
Tickets per hundred orders, tracked per category. Raw monthly volume moves with trading and hides everything interesting; the ratio shows whether the store is getting better or worse at answering its own questions, and the per-category split shows where.
Should we install a chatbot to reduce support volume?
Read the volume first. Automation that answers repetitive questions well is useful, but it also removes the evidence you would have used to stop the questions arising — and deflection rate is a metric you can improve simply by making it harder to reach a person. Fix the causes, then automate what remains.
NEXT STEP
Free store audit
A senior Shopify engineer reviews your storefront, theme performance and checkout, then sends a prioritised list of fixes.