Ticket System for E-Commerce: Do You Need One Yet?

Strip the marketing away and three distinct jobs are left. They are usually sold as one product, they are rarely needed at the same time, and each one costs something to operate as well as to licence.

1. Routing. Deciding which human gets which message. Assignment rules, queues per team, escalation tiers, SLA timers that go red. This is the part that gives the category its name, and the part a two-person shop almost never switches on.
2. Shared state. Everyone seeing the same list, the same history and the same answered-or-not flag. This is the job most small teams are genuinely missing, and it is the cheapest of the three to solve.
3. Reporting. Volume by topic, first response time, resolution rate per agent. Worth real money when you are deciding whether to hire. Worth nothing when nobody opens the dashboard.

The operating cost is the part that gets left out of comparisons. Routing rules have to be designed, maintained and explained to every new person. An escalation tier nobody honours is worse than none, because it tells the customer a promise that no one is keeping. Before you shop, it is worth reading what Keaz actually does as a worked example of a narrow scope: a shared WhatsApp inbox with Shopify order history beside the chat, plus flows triggered by events in your own shop. That is one of the three jobs, deliberately.

Four questions, answerable from thirty days of history, none of them needing a trial account.

1. How many people answered a customer in a normal week? Not how many have access — how many actually typed. If the honest answer is one, you have no routing problem, and buying routing will add work rather than remove it.
2. How often did two people answer the same customer? Collisions are the clearest signal that shared state is missing. Count them for a month; the number is usually either near zero or embarrassing, and both answers are useful.
3. Which decision did you take last quarter from support data? A hire, a product change, a shipping-policy change. If you cannot name one, reporting is a feature you will admire and not use.
4. What happens when the person who answers is away? If the answer is "nothing gets answered", your problem is coverage, not software. Routing cannot allocate work to people who are not there.

Volume belongs in the same exercise, and it is worth counting in buckets rather than as one total — the counting method is set out here. The per-industry ranges are a sanity check on whether your volume is normal for your vertical or a symptom of something upstream.

This is where an honest answer is more useful than a confident one. A shared inbox covers one of the three jobs well and does not attempt the other two.

What it does replace.

• One list everybody reads, with an open-and-done split instead of a status field with seven values. The inbox overview shows the shape most small teams settle on.
• A workable substitute for queues: filtering. Narrowing the list by state and by label, several labels at once, gets you most of the practical benefit of a queue — one person works wholesale, another works returns — without anyone maintaining assignment rules. The inbox filter covers how the state and label filters combine.
• Context without a second tab. The customer's order history sitting beside the message is what turns a two-minute answer into a ten-second one, and it does more for response time than any routing rule.

What it does not replace.

• Ownership with teeth — a named assignee who is accountable and a reassignment trail when they are not.
• Escalation tiers and SLA timers. If you have contractual response times, you need something that measures them.
• Per-agent reporting and a public knowledge base with its own search.

Stated plainly: Keaz is a shared WhatsApp inbox, not a ticket system. If you need queues, escalation and SLA reporting across six channels, shop in that category — and which parts of a customer service platform a small store needs is a better starting point than a feature grid.

Shrink the volume first. Every vendor sizes you against the number you describe, so describe the number you will have after the obvious removals rather than the one you have today.

1. Send the status update before it is asked for. "Where is my order" is not a support question. It is a notification the customer did not receive, or received on a channel they do not read.
2. Automate the three questions you answer most. Shipping times, return windows, sizing. A keyword reply resolves those without creating anything for anyone to route.
3. Treat pre-purchase questions as sales, not support. They are time-sensitive in a way that a ticket queue actively damages: a sizing question answered in four hours is an answer to someone who has already bought elsewhere.

There is a long-standing research argument for this ordering. Across a study of more than 75,000 customer interactions, Dixon, Freeman and Toman found that reducing customer effort — repeat contacts and forcing people to switch channels in particular — predicted loyalty better than satisfaction scores did (Harvard Business Review, 2010, retrieved 2026-11-09). A ticket system is good at organising repeat contacts. It is not good at preventing them, and the prevention is where the return is.

Roughly in order of what they cost.

• Buying routing for a one-person team. Assignment rules with one assignee are pure overhead. The setup is billed once in money and every week in attention.
• Confusing a ticket number with a process. An ID makes a conversation findable. It does not make anybody answer it, and an untouched ticket with a reference number still reads as silence to the customer.
• Setting SLA timers nobody is staffed to meet. A red timer at 9pm on a Sunday informs no one and trains the team to ignore the colour.
• Measuring first response instead of first useful answer. An automatic acknowledgement fixes the metric and not the week. Grade yourself on the reply the customer can act on.
• Routing pre-purchase questions into a support queue. These are revenue conversations with a deadline. Queueing them behind returns is the most expensive tidy-up in the list.
• Migrating macros without counting them. Export the library, check which were used in the last ninety days, and rebuild only those. Most such libraries are mostly dead text.