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 data, volumetric weight, how Swiss Post prices business parcels — is a separate topic, covered in our article on ecommerce shipping in Switzerland. 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 statutory deadline, but you still need a process

Complaints are a different category of ticket from WISMO, and under Swiss law there's no statutory deadline for how fast a seller must respond to one — the Code of Obligations doesn't set a fixed response clock for complaints, the way some other countries do. That's a separate point from the fact that Switzerland has no statutory right of withdrawal for online purchases at all: returns in Switzerland rest on a shop's own voluntary policy plus the warranty rules in the Code of Obligations, not on a cancellation right — covered in full in our article on returns in Switzerland. The two points shouldn't be conflated: one is about whether a deadline exists for responding to a complaint, the other is about whether the customer can walk away from the purchase at all.

What holds regardless: 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, in a form the customer can keep — 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 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 Swiss 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: Handelsverband.swiss's market figures cover online-retail turnover, not whether shoppers used a chatbot or what they thought of it. So instead of borrowing figures from another 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

Switzerland has no AI-specific statute that spells out a chatbot-disclosure duty, and the EU AI Act (Regulation (EU) 2024/1689) is not Swiss law. Two things still point the same way. First, the Federal Data Protection and Information Commissioner (FDPIC) takes the view that the Federal Act on Data Protection already applies to AI, and that with language models that communicate directly, "users have a legal right to know whether they are speaking or corresponding with a machine" (statement of 9 November 2023 — the regulator's reading of the FADP, not a court ruling). Second, the AI Act is not confined to EU territory: under Article 2(1)(c) it also covers providers and deployers established in a third country "where the output produced by the AI system is used in the Union". If your chatbot answers customers in the EU, its transparency duty — Article 50(1), applicable from 2 August 2026 and addressed to the provider of the AI system — can reach you or your bot vendor.

In practice, the answer is the same either way: label the chatbot clearly — an "AI assistant" tag by the chat window, for instance. A practical test before you deploy one: 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".

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 selling through Galaxus or Ricardo can bring the marketplace's 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.