How to reduce WISMO tickets on BigCommerce (2026)

The fastest way to reduce WISMO tickets — the "Where is my order?" questions that average 18% of an ecommerce store's support volume, according to Gorgias helpdesk data — is to answer the question before the customer has to ask it. That means setting a delivery expectation at checkout, sending proactive notifications at every shipping milestone, and giving customers a self-service page where they can track and fix their own orders. Merchants who combine branded tracking with proactive notifications report WISMO drops in the 60–76% range.

WISMO is not a hard problem the way fraud or chargebacks are hard. Every WISMO ticket has the same answer, the answer already exists in your carrier's systems, and the customer would usually rather find it themselves than wait hours for a reply. That makes it the most deflectable category in your queue — and on BigCommerce, most of the fix is configuration and copy, not code. Here is the playbook, in the order that pays off fastest.

What WISMO actually costs you

Run the math on your own queue before deciding how much effort this deserves. Industry benchmarks put the cost of a human-handled retail or ecommerce ticket at roughly $2.70–$5.60, with small teams and outsourced support often paying more per contact. At the 18% average, a store handling 2,000 tickets a month is paying for about 360 WISMO conversations — somewhere between $970 and $2,000 every month, or $12,000–$24,000 a year, spent answering a question the carrier's tracking API already answers for free. Self-service resolutions, by comparison, benchmark at under a dollar to about $2.37 each.

The indirect costs are worse than the direct ones. WISMO clusters exactly when your team is busiest — peak season and carrier delays — so it inflates response times for the tickets that genuinely need a human. And the demand for this information is near-universal: around 90% of consumers say they want to track their deliveries, and shoppers open tracking pages four or more times per order on average. Every gap between that demand and what you publish becomes a ticket.

Why customers open WISMO tickets in the first place

A WISMO ticket is rarely a literal "where is my package." It is one of four anxieties, and each has a different fix:

• No expectation was set. The confirmation email said nothing about timing, so day two already feels late.
• Nothing has visibly happened. The order sits in "Awaiting Fulfillment" with no update, and silence reads as a problem.
• The tracking link is unhelpful. A raw carrier page showing "label created" for three days creates more anxiety than it resolves.
• The customer wants to intervene. "Where is my order — because I need to change the address before it ships." This is the WISMO twin, and no tracking page fixes it.

Tag your last 50 WISMO tickets against those four causes and you will know exactly which of the steps below to prioritize. Most stores find the volume is concentrated in the first scan gap and the intervene case.

Step 1: set the expectation before the order ships

The cheapest deflection is a sentence. State your processing time ("orders ship within 2 business days") and a realistic delivery window in three places: the shipping options at checkout, the order confirmation page, and the confirmation email template. A customer who was told "ships Tuesday, arrives Thursday–Friday" does not email on Wednesday. Two details matter: quote ranges rather than single dates, because a missed promise generates an angrier ticket than no promise; and update the copy during peak season instead of letting January's SLA run through Black Friday. This step costs nothing and prevents the entire "day-two panic" class of tickets.

Step 2: make BigCommerce's native order status work harder

BigCommerce already ships the core machinery, and many stores simply underuse it. Orders move through visible statuses — Awaiting Fulfillment, Awaiting Shipment, Shipped, Partially Shipped — and customers with a storefront account can check their order history and current status without contacting anyone. When you create a shipment and enter the carrier and tracking number, the shipped notification carries the tracking link automatically. So the native checklist is: keep statuses current (an order stuck on Awaiting Fulfillment after it physically left reads as lost), add a tracking number to every shipment the moment it exists, and make sure your transactional emails are enabled and branded.

The native gap is the guest. A shopper who checked out as a guest has no account page to consult, so their only path to "where is my order?" is your inbox. Either nudge account creation on the confirmation page or close the gap with an order lookup that works from order number plus email — which is one of the things a post-purchase app adds.

Step 3: send proactive notifications, not just "shipped"

One shipped email is not proactive communication; it is a receipt. The notifications that measurably kill WISMO are the milestones customers actually worry about: a "we've got it, here's the timeline" message at order time, the first carrier scan (closing the label-created dead zone), out for delivery, delivered, and — most important — a proactive heads-up when there is an exception or delay. Telling the customer about a delay before they notice converts an angry "where is it?!" into a quiet "thanks for the update."

This is the lever with the strongest published numbers. LateShipment reports merchants cutting WISMO tickets by up to 72% after deploying a branded tracking page with proactive notification workflows, and phone-case brand Casely cut WISMO volume 76% by pairing Loop's tracking with automated flows in their Gorgias helpdesk. The exact figure will vary by store, but the direction is consistent across vendors and case studies: push the status to the customer and the inbound question largely disappears.

Step 4: handle the WISMO twin — "…because I need to change it"

A meaningful share of WISMO contacts are not status questions at all; they are intervention requests wearing a status costume. The customer is asking where the order is because they want to change the address, swap a size, add an item, or cancel before it ships. Answering the status question without offering the action just generates a second ticket — and if the package ships before the fix lands, a wrong address costs about $24 per package in carrier correction fees (FedEx charges $25.50 in 2026), or a full reship if the parcel boomerangs.

The deflection here is self-service order editing: a portal where the customer opens their order, sees its live status, and — within rules you define — fixes the address, edits items, or cancels while the order is still editable. Unlike a tracking page, this removes the ticket entirely instead of answering it faster, and it removes the time pressure on your team: the customer self-serves at 11pm instead of racing your warehouse via email the next morning.

Step 5: tag, measure, and keep score

You cannot manage WISMO you do not measure. Create a WISMO tag in your helpdesk (Gorgias and most modern desks can auto-tag the intent), then watch two numbers weekly: WISMO as a share of total tickets, and tickets per 100 orders. The share tells you whether deflection is working; tickets-per-order keeps the number honest while you grow. Starting from the 18% average, stores that execute steps 1–4 should expect to land well under 10% — and the published case studies above show how far the ceiling goes. Re-check the numbers each peak season, because WISMO share spikes exactly when capacity is scarcest.

Where OrderEdit.io fits

OrderEdit.io covers the two app-shaped levers in one install for BigCommerce stores. Customers get a self-service portal with their order's live status plus the ability to edit the address, change items, or cancel within the time window and rules you set — so both the status question and the intervention request resolve without a ticket. The same surface carries a post-purchase upsell slot, which is how the app pays for itself; plans start at $39/month with a 21-day free trial. Whatever stack you choose, the principle is the same: publish the answer, push the updates, and give the customer the wheel for the changes you would have made manually anyway.