Stuck shipments: spotting a delay early

The silence in the middle

Most stores watch two moments closely. The order arriving, and the customer complaining. The several days in between get very little attention, which is unfortunate, because that is when a parcel quietly stops moving.

The pattern is consistent. A parcel is scanned into the network, then scanned at a hub, then nothing. Four days later the customer emails asking where it is. At that point you are behind: you are reacting to a complaint rather than pre-empting one, you have lost four days of resolution time, and the customer has spent those four days deciding how they feel about your store.

Everything in this post is about closing that gap. It is not complicated, it is mostly a matter of deciding to look.

This is not a backorder

Worth separating clearly, because the two get conflated and they need different responses.

A backorder is stock that does not exist yet. The constraint is supply, the resolution is time, and the conversation with the customer is about a date. We covered that in backorder communication templates.

A stuck shipment is stock that exists, has left, and is not arriving. The constraint is a carrier, the resolution is chasing or replacing, and the conversation with the customer is about what you are doing right now. The response is much more time-sensitive, because a delayed parcel that gets chased on day three usually arrives, and one that gets chased on day ten usually does not.

A detection rule that costs nothing

You do not need a monitoring system. You need a definition of stuck and somebody who looks.

The workable definition is time since last scan, not time since dispatch. A parcel that moved yesterday is fine even if it shipped a week ago. A parcel that has not moved since Tuesday is a problem even if it shipped Tuesday.

Set a threshold per service. Something like: 48 hours without a scan on a domestic service, 96 hours on an international one, adjusted for weekends and for the carriers you actually use. You will get the numbers slightly wrong at first. Write them down anyway, because a written threshold can be tuned and an instinct cannot.

Then the daily check is short: which parcels have crossed the threshold? On most days the list is empty or nearly so.

Three categories, three responses

Once you have a list, the parcels on it fall into three groups, and sorting them takes seconds.

Slow but moving. The last scan is old but the parcel is progressing through a known-busy network. Response: nothing yet, look again tomorrow. Resist the urge to act on every one of these; most resolve.

Genuinely stopped. No movement, no explanation, past the threshold by a clear margin. Response: raise it with the carrier now and tell the customer before they ask.

Exception raised by the carrier. Address problem, failed delivery, held at a depot, customs. Response: these usually need the customer to do something, and every hour you sit on one is an hour they are not doing it.

The third category is the highest-return one and the one most often missed, because carrier exception emails land in a shared inbox and get read as noise.

Who owns the check

One person, daily, ten minutes. If it is nobody's job it will get done in weeks when things are calm and skipped in weeks when they are not, which inverts the value entirely.

It does not need to be a senior person. It needs to be someone who will actually do it and who has the authority to take the obvious actions without asking: contact the carrier, message the customer, and reship below a value floor. If every stuck parcel has to be escalated to make progress, the check becomes a queue rather than a resolution.

Which is the general point from escalation paths for small teams: the person who notices should usually be able to act, and where they cannot, the boundary should be written rather than assumed.

Telling the customer first

The strongest move available here is also the cheapest: contact the customer before they contact you.

The message is short and does three things. It says what you know, plainly. It says what you have done, in the past tense. And it says what happens next, with a date.

Something like: your parcel has not moved since Tuesday, we have opened a query with the carrier this morning, and we will update you by Thursday whether or not there is news. If it has not moved by then we will send a replacement.

Three things make that work. It does not apologise at length, which reads as evasive. It commits to a next contact date, which stops the customer from having to chase. And it names the fallback, which converts an open-ended worry into a bounded one.

A customer who has been told about a problem is having a different experience from one who has discovered it. The parcel is equally late in both cases.

The reship decision, decided in advance

At some point you decide to send another one. Making that decision per parcel, in the moment, produces inconsistency and delay.

Set a rule instead, on two axes. Value: below a floor, reship without asking, because the cost of the item is less than the cost of the conversation. Time: after a fixed number of days without movement, reship regardless of value, because the recovery odds have dropped and the customer relationship is decaying.

Write both numbers down and give them to whoever runs the daily check. You will adjust them. The point is that the person looking at a stuck parcel on a Tuesday morning knows what they are allowed to do about it.

Claim against the carrier separately, on your own schedule. Do not make the customer wait for your claim to resolve; those are two different processes and only one of them is urgent.

Reading the pattern, not just the parcel

Every stuck parcel is an incident. The set of them over a month is information.

Keep a minimal log: date, order, carrier, service, where it stopped, how it resolved. After a few weeks you can usually see something. One carrier that produces most of the exceptions. One service level that is not worth its discount. One destination region that is consistently slow. One of your own packaging choices that keeps generating damage scans.

None of that is visible one parcel at a time, and all of it is actionable: a carrier conversation with evidence, a service level dropped, a delivery estimate adjusted so the promise matches reality.

Peak changes the numbers, not the process

During peak, carrier networks slow down and your thresholds produce false positives. The fix is to widen the thresholds for the period, deliberately and in writing, rather than to abandon the check because the list got long.

It is also worth saying out loud to the team that a longer list is expected in November, so nobody concludes the process is broken and quietly stops running it. The check matters more during peak, not less, because that is when a stuck parcel is most likely to turn into a refund.

What this looks like in Store Huddle

A room for the daily exception check, with the order attached to each parcel under discussion so nobody has to establish which order is meant. A task per stuck parcel with an owner and a due date, so the parcel you decided to look at again on Thursday is actually looked at on Thursday rather than remembered on Friday.

The log lives in the same room as the conversation, which is the part that makes the monthly pattern visible. When the record of what happened is spread across an inbox, a spreadsheet and somebody's memory, nobody assembles it, and the carrier conversation never happens.

Alerts help with detection, but the harder half is the routing: the exception has to arrive where the person who can act is already looking. That is the argument in who should get inventory alerts, and it applies unchanged here.

Common questions