We analyzed tens of thousands of support conversations. Here’s what customers actually ask.

Across tens of thousands of support conversations, one pattern swamps everything else: customers ask the same small set of questions, over and over, in slightly different words. Roughly a third are about orders and access — "I paid, where is my thing?" About a quarter are how-do-I questions. Around a fifth are refunds and billing. The rest is a long tail of genuine edge cases. That is the whole distribution, and once you have seen it you cannot unsee it.

We run support for creator and SMB businesses at scale, so we get to watch this play out across very different companies — a course seller, a D2C store, a SaaS tool. The surface details change. The shape does not. A support queue is not a thousand different problems. It is four buckets, and one of them is almost always overflowing.

The four buckets, in order of volume

Orders and access is the biggest bucket — call it a third of everything. This is "I paid but I didn't get access," "where do I log in," "my order says shipped but nothing moved," "the download link is broken." Notice what these have in common: they are not really questions about your policies. They are questions about one specific person's account state, right now. A generic answer barely helps; the customer wants to know about their order.

How-do-I is the next bucket — about a quarter. "How do I change my email," "how do I invite a teammate," "how do I cancel," "does this cover topic X." These are pure knowledge questions. The answer is the same for everyone who asks, it does not change hour to hour, and it almost always already exists somewhere — in an old email you sent, a Notion page, your own head. How-do-I is the bucket a good help center simply deletes.

Refunds and billing is roughly a fifth. "What's your refund policy," "I was charged twice," "my coupon isn't working," "can I pay in installments." Half of this bucket is knowledge (the policy) and half is action (actually issuing the refund). That split matters enormously, and we will come back to it.

The last bucket — the remaining quarter or so — is the true long tail. Odd bugs, feature requests, one-off complaints, the message that is three questions stapled together. This is the interesting bucket, the one that actually needs a human brain. It is also, tellingly, the smallest.

What AI resolves alone, and what it must not

Sort those buckets by "can software answer this correctly, alone?" and a clean line appears: the knowledge questions can be automated; the account questions cannot.

Every how-do-I, and the policy half of billing — call it half of your total volume — is answerable from documents you have already written. There is no judgment call, no risk, no per-person lookup. If the answer is published, an AI can serve it instantly and be right every time. In most queues we see, this knowledge slice is comfortably the largest share of volume, which is exactly why deflection is possible at all.

The account questions are the opposite. "Where is my order" cannot be answered from an article, because the article does not know the customer. Answering it needs a real lookup into your systems — and anything that changes an account (a refund, a re-send, a cancellation) needs a human to approve it, because a wrong answer here costs money, not just goodwill. An AI that invents your refund policy is embarrassing; an AI that issues a refund on its own is a liability. The right design lets the AI answer the knowledge, look things up where identity is verified, and hand the money-moving decisions to a person.

The long tail, meanwhile, should mostly go straight to a human. That is not a failure of automation. That is automation clearing the deck so your team has the time to think about the quarter of conversations that genuinely deserve thought.

It is the same thirty questions, rephrased

Here is the finding that changes how you staff a queue. When we cluster a month of conversations by meaning rather than by exact wording, the count collapses. A store handling a couple of thousand tickets a month is usually answering something like thirty distinct questions. Everything else is paraphrase.

"When will it arrive," "how long is shipping," "eta on my order," "haven't received yet," "how many days for delivery" — five phrasings, one question. Your team experiences them as five hundred separate typing sessions. They are one article.

You do not have a thousand questions. You have thirty, asked a thousand ways.

This is genuinely good news, because thirty is a number you can finish. Thirty short articles is an afternoon of writing, sourced entirely from answers you have already typed a hundred times. The reason support feels infinite is not that the questions are infinite — it is that a chat message is written once and read once, so every answer evaporates the moment you hit send. Move each of the thirty into a document that is read forever, and the queue stops regenerating from scratch every morning.

The businesses that feel calm about support are not the ones with fewer questions. They are the ones who answered each question once, in a place that remembers.

When customers write versus when you answer

Now the mismatch nobody plans for. For creator and consumer businesses, a large share of messages — often well over half — arrive outside normal working hours. People buy a course after dinner. They remember the parcel at 11pm. They check "did my payment go through" at midnight, phone in hand, slightly anxious.

Your customers write when they are shopping. Your team answers when they are working. Those are different hours.

The buying-time skew is not random; it is structural. Someone with a day job does their personal admin — the course purchase, the store order, the subscription question — in the evening, on their phone, in the gap between one thing and the next. That is precisely the window when a small team is offline. So the highest-intent messages, the ones closest to a purchase decision, land in the exact hours when no human is watching.

This is where the timing and the buckets collide into a single insight. The evening spike is heavy on two things: pre-purchase questions ("does this cover X," "is COD available") and access panics ("I paid, nothing happened"). The first, unanswered, is an abandoned cart by morning. The second, unanswered, is a refund request by morning. Silence at 11pm is not neutral — it quietly converts intent into a refund. An answer that arrives instantly, even a plain restatement of your shipping timeline, holds the sale that a six-hour delay would have lost.

You cannot fix this by working nights. You fix it by making the knowledge half of your queue answer itself around the clock, so the evening asker gets a correct, confident reply at the moment they ask — and the genuinely human conversations wait politely for morning, where they belong.

That is the whole reason we built Iris the way we did. It answers from what you have actually published — your thirty questions, your real policies — and stays silent when it is not sure, so the after-hours asker gets your knowledge instantly and your team keeps its judgment for the long tail. The distribution of a support queue is remarkably stable. Once you know its shape, you can finally build for it instead of drowning in it.