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, connecting InPost, DPD or DHL, fees and volumetric weight at courier brokers — is a separate topic, covered in our article on ecommerce logistics in Poland. 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 — a statutory 14-day deadline in Poland

A complaint, unlike a status question, has a statutory response deadline in Poland: 14 days. Article 7a of the Consumer Rights Act (ustawa o prawach konsumenta, consolidated text Journal of Laws 2026, item 1244) says that, unless separate provisions state otherwise, the business must answer a consumer's complaint within 14 days of receiving it (para. 1). Silence has a legal effect: if the business does not answer within that time, the complaint is deemed accepted (para. 2) — so silence after 14 days means acceptance, not rejection. The answer must reach the consumer on paper or another durable medium (para. 3), for example by email or in the customer's account panel; a verbal answer over the phone that leaves no record is not enough. Paragraph 1 opens with a reservation, "unless separate provisions state otherwise", so for some contracts a sector-specific rule may set a different deadline — if you sell products under special regulation, check it for your industry.

The 14-day complaint deadline is a different thing from how long a customer has to cancel a purchase under the right of withdrawal (14 days, art. 27, based on EU Directive 2011/83 — covered in our article on returns and the right of withdrawal) and from the 14 days the seller has to refund the payment after a withdrawal (art. 32). In the ticket queue these are three different cases with three different clocks, and they shouldn't be conflated: one is about how fast you must respond once something has gone wrong, the others about whether the customer can walk away from the purchase and when the money goes back.

Besides the statutory answer, acknowledge a complaint immediately, even if you can't resolve it on the spot, and put the response itself in writing, on a durable medium. A complaint that drags on past the deadline is the version that damages trust the most, and in Poland, once the 14 days have passed, it is also deemed accepted.

From a support-organisation standpoint, this has one practical consequence: 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 has a 14-day clock 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 the 14-day deadline counts from.

Chatbots — where they help, and what Polish shoppers say

Before you deploy a chatbot, it's worth knowing what Polish shoppers themselves say about it. Fewer than a third of Polish online shoppers report having talked to a shop's chatbot, and their ratings are mixed. The data comes from a survey of the customers themselves, not from chatbot vendors' materials: Gemius, in its "E-commerce w Polsce 2026" report (CAWI method, fieldwork 14–22 July 2026), asked three questions on the subject.

Have customers talked to a shop chatbot at all? Among people who have ever bought online (N=1,825): yes 29%, no 49%, don't know 22%. The report explains the high "don't know" share with a hypothesis of low recognition of automation in shop interfaces or ambiguous labelling of whether the user is talking to AI, a bot or a human — exactly the issue the AI Act regulates (below).

How do those who did rate the experience? Among people who had contact with a shop chatbot (N=525), on a scale from -2 to +2: very positive 19%, +1 22%, neutral 30%, -1 14%, very negative 14%. The report sums up: 41% report a positive experience (the two top categories), 28% a negative one, and adds that merely deploying a chatbot is not a sufficient measure of success — its value depends on the accuracy of answers, access to current product and order data, handling of exceptions and a quick handover to a human.

What do shoppers find chatbots useful for? Among shoppers from the last 12 months (N=1,768): 43% find chatbots especially useful for quick answers to simple questions such as opening hours or delivery status. 35% point to help comparing products and giving detailed information, 32% to finding products by needs. Problem-solving functions rank lower: support with returns and complaints 24%, reaching a live consultant 22%, payment problems 14%. 21% see no particular usefulness in any of these areas.

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". The duty already applies, so if your bot is running without a label, fix that now.

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.