WISMO for Dropshippers: Causes, Replies, and Risk

WISMO means "where is my order?" Customers ask it when the delivery promise no longer matches the tracking record or parcel movement. For a dropshipper, the next step depends on whether your store, the supplier, or the carrier owns the missing fact.

I've run Shopify stores and handled the chargebacks that came after customers stopped trusting what an order update said. The first fix is checking whether the supplier handed the parcel to the carrier. A useful reply gives the last verified fact, names the next check, and sets a resolution path.

Key takeaways

What does WISMO mean for a dropshipper?

WISMO is a post-purchase "where is my order?" inquiry that a dropshipper answers from verified order and shipment evidence. Shopify describes WISMO as a customer asking for an order's status through chat, email, social media, text, or phone. ClickPost distinguishes the adjacent return-stage question as WISMR. Use the same records to explain the delay, regardless of which channel the customer chose.

Check these records against one another because they may disagree:

• The order record shows the delivery date you promised.
• The supplier record shows the handoff evidence.
• The carrier record shows the latest scan.

Together, these records set the reply. A tracking link helps only when its status matches the parcel and your reply explains the next check.

A customer asking for a return, refund, or product remedy has moved beyond order status. Route that request into the relevant workflow instead of keeping it in the WISMO queue.

Use the WISMO Triage Map

Use the WISMO Triage Map to match the customer reply to the shipment event you need to investigate. Start with the promised delivery window and identify who owns the next fact. The map tells you what you can tell the customer and what to do next.

Use these five triggers in order:

1. Promise mismatch
2. Label created but not tendered
3. No recent carrier scan
4. Split shipment
5. Carrier exception

If two triggers fit, a missed promise decides the remedy. The current shipment event shows who owes the next fact.

‍

1. Promise mismatch

Use promise mismatch when shipment evidence conflicts with the promised delivery window or that window has passed. The store owns this trigger because its checkout and confirmation set the customer's expectation.

Handle the mismatch in three steps:

1. Save the delivery window shown when the buyer paid.
2. Compare it with the latest supplier or carrier event.
3. Give the buyer the next decision time and the stated remedy.

The purchase-time promise remains the standard even if your current product page has changed. I call an order on time only when the evidence still supports that window. Once it passes, I move to the written refund or replacement rule. When the promised window still matches the current evidence, use the shipment-event trigger that fits the record instead.

2. Label created but not tendered

A label-created status needs supplier handoff evidence before you can say the parcel is moving with the carrier. USPS's label-created status means a tracking number exists but the package hasn't been given to USPS.

Other carriers use their own wording, so read the event rather than relying on the tracking number alone.

Ask the supplier for the handoff record or a revised ship date. Then tell the customer that carrier possession hasn't been confirmed and name your next update date. This reply gives the buyer a true status without blaming the supplier or inventing movement.

Treat a supplier message that says "shipped" as a lead. A handoff record must show when the parcel left the supplier's control. Ask for the carrier acceptance event, pickup receipt, or similar proof.

Save the supplier's reply with the ticket. It gives the next agent the claimed handoff date. That record also stops the same question from going back to the supplier without context.

The supplier may be the only party that can prove the physical handoff. Until that proof arrives, the support agent can't confirm that the parcel is in transit.

Move to the store's remedy decision when the promised delivery window is already at risk. Once a carrier acceptance scan appears, choose the trigger that matches the new carrier record.

3. No recent carrier scan

Start scan-gap handling only after the carrier has confirmed possession of the parcel. The carrier then owns the next movement record.

Handle the gap in this order:

1. Save the last carrier event and its time in the ticket.
2. Give the customer the next check-in time you can keep.
3. Use the saved wait period and trace link for that carrier service.

Store that service's waiting period and trace link in the support rule before tickets arrive. These fields vary by carrier, service, and route, so the rule needs the exact service used on the parcel.

Review this support field when you add a new route or service. That check keeps an old trace rule from guiding a shipment it never covered.

I leave the delivery date unset until the carrier supports one. A guessed date turns an uncertain shipment into a second broken promise. Escalate when the saved carrier rule says so or when your promised delivery window passes.

4. Split shipment

When one order ships in parts, the customer needs a status for every parcel and item. This trigger fits when one box arrives or moves normally while another part is still pending.

Build the parcel view with these fields:

• Item name and quantity
• Parcel tracking number
• Supplier and carrier
• Latest event and time

The safe update names what has arrived and what remains outstanding. Keep each parcel as its own status record. An order-level "delivered" label can hide the item the customer is asking about. Follow up only on the missing parcel.

Keep the item-to-parcel match visible in every reply. This stops a delivered parcel from closing the whole ticket while another item still lacks a handoff or current scan.

Separate tracking shows which parcel is missing. Apply the remedy once its promised window passes. Tell the customer whether that choice affects the rest of the order.

Use another event trigger when every item shares one parcel and tracking number.

5. Carrier exception

Use a carrier exception when tracking names a failed delivery event and points to a next action. Read the recorded event to see who can clear it. The table above assigns the next fact without turning the carrier's wording into a guessed cause.

Translate the recorded event into plain language and say who is doing what next. Assign the case to the party that can clear it, then keep one store-side owner for the customer. This keeps the buyer from being sent between a supplier, carrier, and support inbox.

Save the event wording and time before anyone contacts the carrier or supplier. An absent exception code belongs under scan-gap handling. If a recorded exception stays open past the delivery date or policy cutoff, choose a replacement or refund. Then tell the customer.

Keep WISMO from reaching the queue

Proactive messages reduce WISMO when customers see the same promise and parcel records your agents use. Shopify also says to show clear dates, offer several contact channels, and give live tracking. Each update must match the records you can see.

Put these customer-facing facts in place:

• Show the delivery window before checkout and in the confirmation.
• Send one tracking record for each parcel in the order.
• Add an order-status button that opens a form with order and parcel IDs.
• Route an expired promise without a delivered scan to an agent.
• Route conflicting supplier and carrier records to an agent.

Use a post-purchase email sequence to repeat the promised window and send parcel updates. It also gives the buyer one place to find each message.

An AI order-tracking chatbot can repeat a verified status when its feed contains the right event. Automation can only work with the evidence it receives.

Send missing handoffs, record conflicts, and remedy decisions to a person. Supplier delays and carrier exceptions still need the five-trigger process behind each self-service answer.

Protect the order before it becomes a dispute

A late or missing delivery can support an item-not-received dispute. Visa lists goods not received by the agreed date or place as a common cause of Condition 13.1. Its guidance asks merchants to support the expected date or prove delivery when responding.

Save the records that explain what happened:

• Keep the delivery promise shown when the customer ordered.
• Store each supplier handoff record and carrier tracking history.
• Save the customer's message and every dated reply.
• Write down the fix you gave, whether a refund, replacement, or canceled order.

Together, these records show what happened. Save the order confirmation and each carrier event you used in a reply. A link may show a different status later.

Review those records to decide whether to refund, replace, or keep tracing the order.

The same records support later dispute work if the customer files. A fast reply gives you a chance to resolve the delivery issue before it reaches the payment channel.

Track the pattern, not just each ticket

Recurring trigger patterns show which supplier, promise, or tracking process needs to change. When one trigger dominates by supplier or route, it points to a process rather than agent wording.

Use a monthly review with the same sequence:

1. Sort every WISMO ticket by its map trigger.
2. Group the largest trigger by supplier, route, and promised window.
3. Read the customer outcome for that group.
4. Fix the cause named by the trigger.
5. Review the same tag after the change.

Record the change date, owner, and expected result beside the tag. That lets the next monthly review compare the same route or supplier before and after the fix instead of relying on memory.

The tags now point to one cause. Compare your store's repeat patterns because useful thresholds depend on its support access, suppliers, routes, and promised windows. A low ticket count can mislead you when buyers can't find support. Some may go straight to refunds or disputes.

A repeated handoff gap may need a new supplier rule from our sourcing, fulfillment, and operations guides. A promise mismatch calls for new delivery-window copy or planning. A scan-gap pattern calls for a new check-in rule.

I recommend fixing the largest repeated trigger first because your ticket data already shows where it occurs.

FAQ

Is WISMO the same as WISMR?

WISMO tracks an outbound order, while WISMR means "where is my return?" and covers the return, refund, or exchange stage. They need separate queues because each follows a different journey.

Can a tracking number exist before a carrier has the parcel?

Yes, a supplier can create a tracking number before the carrier confirms possession of the parcel. Read the carrier event and request supplier handoff evidence before telling the customer the shipment is moving.

Should a seller automate every WISMO reply?

Automate a reply only when the system can read a verified event and follow a clear escalation rule. Send missing handoffs, record conflicts, carrier exceptions, and remedy choices to a person.

What should a seller save from a WISMO ticket?

Save the order promise, supplier handoff, carrier scans, customer messages, replies, and outcome. Keep the times and parcel IDs so the record shows what was known when each decision was made.