Ecommerce Customer Service: Fewer "Where Is My Order?" Tickets

Ecommerce customer service often drowns not in hard cases, but in questions a customer wouldn't need to ask if they'd had the information sooner. "Where is my package?" is such a repeatable category of enquiry across e-commerce that the industry has its own shorthand for it — WISMO — even though no standards body has ever formally defined it. This article looks at what actually gets ahead of that question — status communication, a clear complaint process — and where a chatbot genuinely helps, versus where it just adds another screen between the customer and the answer.

"Where is my order?" — WISMO as a category, not a standard

WISMO stands for "Where Is My Order", used across e-commerce and customer-service tooling to describe one specific, very common category of ticket. Shopify puts it plainly: "WISMO stands for 'Where is my order?' and represents one of the most common types of customer inquiries for ecommerce merchants" (read 1 October 2026). Freshworks frames it the same way: "A WISMO call is a 'where is my order' inquiry. These occur between the purchase and delivery stages, especially if an order is taking longer than expected" (read 1 October 2026).

It's worth being clear about what WISMO isn't: it's not a formally standardised term from any standards body — it's terminology that has taken hold in e-commerce and helpdesk vendor content (Shopify, Freshworks), repeated consistently enough across the industry to become a commonly understood label, without one authoritative source definition. That doesn't matter for running a store — what matters is what it describes: a ticket that isn't caused by a problem with the order, but by the customer not having the status information they need at the moment they need it.

Why it's worth carving this category out before you touch the rest of your support queue: a WISMO ticket has the property that the answer is always the same for a given status — "your order is on its way, delivery expected on [date]" doesn't change from customer to customer, only the date and tracking number do. That makes this category a strong candidate for getting ahead of the question entirely, rather than waiting for it to be asked — unlike complaints or sales questions, where the answer genuinely depends on the specific customer's situation.

Status notifications — get ahead of the question before it's asked

The mechanism that cuts down WISMO tickets is simple: the customer gets notified of every order-status change (accepted, shipped, in transit, delivered) automatically, at the moment it happens — by email, SMS or in their account panel — instead of finding out only when they ask. That needs two things at once: an integration between your order system and the carrier (so the status actually reaches your store in reasonable time) and a channel the customer actually checks (an email that lands in spam, or an SMS sent to an outdated number, won't help no matter how well the mechanism itself is designed).

The technical side of that integration — carrier APIs, volumetric weight, how pricing works across the parcel-locker networks used throughout the EU — is a separate topic, covered in our article on EU ecommerce shipping. From a support standpoint, only one thing matters: if the status reaches the customer before they ask about it, they have no reason to write in — that ticket never needs "handling" by any bot or template.

In practice, it's worth splitting this communication into specific moments in the order cycle, not one generic "status": an order-confirmation message immediately after purchase (with an order number the customer can reference), a shipping notification with a tracking number (from which point the customer can track the parcel themselves), and — less commonly implemented, and just as useful — a proactive exception alert (a carrier delay, a failed delivery attempt), sent before the customer notices something's wrong on their own. That third moment carries particular weight, because according to Freshworks, WISMO enquiries come in "especially if an order is taking longer than expected" — a customer who hears about a delay from the store doesn't have to discover it themselves by watching a tracking number stop updating.

Complaints — no single EU deadline, but you still need a process

Complaints are a different category of ticket from WISMO, and some member states put a statutory clock on the seller's answer. No EU-wide deadline exists for this specific question: how fast a seller must respond to a complaint about a problem with an order. That's a different question from how long a customer has to cancel a purchase under the right of withdrawal (14 days, harmonised EU-wide by Directive 2011/83 — covered in our article on the EU right of withdrawal), and the two shouldn't be conflated: one is about whether the customer can walk away from the purchase at all, the other is about how fast you must respond once something's gone wrong. Where a specific complaint-response deadline exists, it's set at the level of the individual member state, not harmonised across the EU — so check your own country's rules if you need a number rather than a practice.

What holds regardless of jurisdiction: acknowledge a complaint immediately, even if you can't resolve it on the spot; investigate and respond within a timeframe you define for yourself and actually hold to, rather than an open-ended one; and put the response itself in writing, on a durable medium — email or a message in the customer's account panel, not a verbal answer over the phone that leaves no record. A complaint that drags on with no deadline anywhere, internal or external, is the version that damages trust the most.

From a support-organisation standpoint, this still has one practical consequence even without a statutory clock: a complaint needs its own, visible internal timer, separate from the WISMO queue. If complaints land in the same general inbox as "where is my order" questions, it's easy to lose track of the fact that one of them needs a documented, timed response and the other doesn't — mark complaints as a distinct ticket category the moment they arrive, with the receipt date recorded unambiguously (not the date someone happened to read the message), since that date is what any internal SLA, or any national deadline that does apply to your business, would count from.

Chatbots — where they help, and the limits of what the data shows

Before you deploy a chatbot, it's worth being honest about what's actually known, rather than assumed. No EU-wide survey of how many online shoppers have talked to a shop's chatbot, or how they rated it, turned up in the research behind this article: Eurostat's e-commerce tables report whether someone shopped online at all, not whether they used a chatbot or what they thought of it. So instead of borrowing figures from a single national market, this section describes the mechanism.

The mechanism follows directly from the WISMO definition above: a chatbot has the best odds of a good experience where the question has one correct, repeatable answer that doesn't depend on the specific customer — delivery status, opening hours, the basic terms of a return policy. It has the worst odds where the customer needs judgement, empathy, or a human who can deviate from a script — a payment dispute, an unusual complaint, anything that calls for a decision rather than a lookup. Deploying a chatbot at all is not, by itself, evidence that it's working well: the only honest way to know is to measure it against your own ticket queue, split by category, rather than assume the technology is uniformly good or uniformly bad.

Disclosing that it's AI

If you deploy an AI-based chatbot, from 2 August 2026 a specific transparency duty under the EU AI Act (Regulation (EU) 2024/1689) applies. Article 50(1): "Providers shall ensure that AI systems intended to interact directly with natural persons are designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system, unless this is obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspect, taking into account the circumstances and the context of use." The duty is addressed to providers of AI systems: if you're using a third party's off-the-shelf bot, that obligation formally sits with them, but it's your customer who sees the chat window, so it's worth checking the disclosure actually displays; if you build your own bot, you may be the provider in the Act's sense yourself.

The 2 August 2026 date comes from elimination: Article 113 sets a general application date of 2 August 2026, with earlier and later exceptions for specific chapters and provisions. Article 50 sits in Chapter IV, which isn't among those exceptions, so it applies from the general date. A later amendment widened the exceptions list and added a transitional window to 2 December 2026 — but that window covers only the synthetic-content labelling duty in Article 50(2), and only for systems already on the market before 2 August 2026; it does not cover the duty to disclose that a customer is talking to an AI system at all, in Article 50(1).

A practical test before you deploy a chatbot: would someone writing to it for the first time, who hasn't read your terms, know immediately that they're not talking to a person? If the answer isn't an unambiguous "yes" — the bot has a human name, answers in the first person with no label, or the chat interface looks identical to a live-agent conversation — add an explicit label rather than relying on it being "obvious". This isn't something you can defer if you plan to run an AI chatbot after 2 August 2026.

Helpdesk and channels

Whether or not you deploy a chatbot, it's worth having one place where your team sees every ticket regardless of the channel it arrived through — email, Messenger, a web form, a message through a marketplace. The mechanism is easy to describe and harder to implement: if support has to switch between several independent inboxes and panels just to see the full history of one customer's contact, response time grows regardless of how many people you hire. One shared ticket view, with order status visible next to every conversation, removes the "let me check in another system" step from every single interaction — that's an operational difference, not a technology trick.

Channels also differ in how fast a response is expected — live chat inherently implies a real-time conversation, email doesn't — and a marketplace, if you sell through one, can have its own rules about how quickly you must respond to buyer messages, independent of whatever you've set up internally; check the specific marketplace's terms. If you handle every channel from one place, it's worth setting a target response time per channel — otherwise it's easy to treat everything by the slowest standard, which damages the experience on channels where customers expect a faster answer.

Measuring ecommerce customer service — two metrics that matter

Two metrics are enough to know whether support in a small store is working, without a corporate dashboard carrying twenty indicators:

• Response time — how long it takes from a ticket landing to the first real, substantive reply (not an automatic "we've received your message" acknowledgement). Measured per channel, since expectations differ between email and live chat.
• First contact resolution (FCR) — the share of tickets closed without needing another exchange of messages. A low FCR on WISMO tickets specifically can mean the status information you're giving the customer is incomplete or unclear — not that support is answering badly.

Neither metric can be sensibly compared to any universal "good score" without knowing the industry and the volume involved — measure your own over time, rather than against someone else's benchmark whose methodology you don't know.

A practical way to use the two numbers together: if response time is short but FCR is low, the team is answering fast but incompletely — the customer still has to send another message to actually close things out. If it's the reverse — FCR high, but response time long — the answers are complete, but the customer waits too long for them. The first pattern can point to gaps in the information support has on hand (no single view of order status, for instance); the second points to a staffing shortfall or a process that's too slow internally. Tracking both metrics together, not just one, shows which of these two problems actually applies to your store.