“Does this run small.” “Is the blue one back in stock.” “Will this fit a 32-inch waist.” Every one of these lands in most ecommerce teams’ inboxes as a support ticket. None of them are actually support tickets. Each one is a shopper standing at the register, ready to buy, waiting on one piece of information to commit. Treat that message as a cost to deflect and you miss the moment it actually is.
Why this gets miscategorized so consistently
The mislabeling is not a mistake so much as an artifact of how most teams built their tools. A ticketing system tracks volume, first response time and resolution time. Those are the right metrics for a genuinely broken order or a billing error. They are the wrong lens entirely for a shopper asking whether a jacket runs true to size, because that shopper is not reporting a problem. They are asking permission to spend money.
A shopper asking whether a jacket runs true to size is not reporting a problem. They are asking permission to spend money.
Industry research puts the pre-sales share of inbound ecommerce support messages as high as 60 percent. That is not a rounding error in how support volume gets classified. It means a majority of what shows up in the ticket queue at many stores is demand, not damage control.
of inbound ecommerce support messages are pre-sales questions, not service issues.
Industry research
The whole purchase waiting on one small piece of information.
What happens when the answer is slow
A support queue is built around a reasonable question: how quickly do we need to resolve this. For a genuine complaint, an hour or a day might be fine. For a shopper deciding whether to complete a purchase, the tolerance is much shorter, because the moment of intent does not wait in a queue. A shopper who does not get a fast, accurate answer to a sizing or fit question does not usually file a follow-up. They leave and buy the same category of product somewhere else, and the store never logs that as a lost sale, because it was never logged as a sale opportunity in the first place.
This is also where the training research on physical retail lines up almost exactly with what happens online. Half of shoppers say they are actively looking for expert advice the moment they engage with a brand, and most say product knowledge is what they need most from whoever is helping them, according to Wharton School and Marshall Fisher’s research. That expectation does not lower online. If anything, a shopper typing a question into a chat window has already decided to ask rather than guess, which makes them a more qualified lead than a shopper silently browsing.
of shoppers are actively looking for expert advice the moment they engage with a brand.
Wharton School, Marshall Fisher research
The sale that completes, or the one that quietly does not.
Why the fix is not “answer support tickets faster”
Speeding up a support queue treats the symptom. The actual fix is recognizing that a pre-sales question is a different kind of message that deserves a different kind of handling, grounded in live catalog and inventory data rather than a general script.
Our AI Shopping Assistant treats a fit or availability question as what it is, a live opportunity to close a sale, not a queued ticket waiting its turn. The Product Discovery and Product Q&A agents answer from current catalog data immediately, in the same thread a shopper is already using, so the answer arrives while the intent is still there instead of after it has cooled. Because the same thread also carries Order Management and Customer Support, a shopper who gets a fast sizing answer and buys, then later needs to check that order, never has to start over to do it. That continuity is the subject of why shoppers hate repeating themselves.
The same logic extends past the initial sale. A shopper who needs to swap a size or check a return should not lose the thread either, which is why we treat order and returns questions as part of the same conversation rather than a separate escalation. We go deeper on that specific pattern in why a return shouldn’t need a whole new conversation.
If your team already suspects a chunk of the support queue is really sales in disguise, a quick tag-and-review pass on last month’s tickets will confirm it fast. Book a demo to see how the same thread that answers a fit question also carries the sale through.
Before you take this to your team
Pull a sample of recent tickets and sort by whether the shopper had already purchased at the time they wrote in. Questions about fit, compatibility, availability and specifications almost always sit on the pre-purchase side, even when they arrive in the same queue as a return or a billing issue.
Not necessarily. The core problem is architecture and prioritization, not headcount. A system that answers a fit question from live catalog data the moment it is asked solves the speed problem without adding staff to a queue built for a different kind of question.
No. The same pattern shows up anywhere a shopper needs one more piece of information before committing, compatibility in electronics, dosage or usage questions in specialty categories, and spec questions in technical and B2B catalogs.
It should. A ticket that ends in a completed sale is doing different work than a ticket that resolves a complaint, and measuring both purely on resolution time hides that difference. Some teams start by tagging pre-sales tickets separately so the revenue impact becomes visible.
Find the sales hiding in your support queue
A quick tag-and-review pass on last month's tickets will confirm it fast.