How Real-Time Shipment Tracking Should Reduce WISMO, and Why Most Implementations Don’t

What WISMO actually costs

The visible cost is ticket volume, and it is the smallest part.

Underneath it sit repeat contacts on the same order, because a customer who receives no new information contacts again. Escalations, when the second contact produces the same non-answer as the first. Refund and cancellation requests driven by uncertainty rather than by an actual failure. And the loyalty cost, which is the largest and the least visible.

That last one has a measured shape. Gartner research on customer effort found 96 percent of customers who have a high-effort service experience become disloyal, against 9 percent of those with a low-effort experience, and that customers are four times more likely to leave a service interaction more disloyal than when they entered. A WISMO contact is high-effort by definition: the customer wanted information, could not find it, and had to work to get it.

The commercial consequence follows. PwC research indicates 42 percent of consumers cite the reliability of logistics delivery as a top factor in choosing a brand or retailer, and approximately 32 percent say one bad experience would stop them buying from a brand they otherwise liked.

One note on benchmarks before going further. You will find figures for WISMO as a share of support volume and cost per contact. They trace to customer-service and post-purchase software vendors rather than to research firms or government sources, and none carry a stated methodology. Your own rate, measured the way described later in this article, is both defensible and more useful.

Why tracking alone does not reduce WISMO

Here is the mechanism most implementations miss.

A tracking platform surfaces status. The question is to whom. Most implementations surface it to operations teams, on an internal dashboard, so the operation now knows where every shipment is. That is valuable and it does not change the customer’s situation at all, because the customer still has no information they did not have before.

Where a customer-facing view exists, it is usually a portal the customer has to visit. That changes the channel and not the behaviour. The customer still initiates, still spends effort, and still contacts support when the portal shows something ambiguous, which it frequently does. Contacts move from phone to portal to phone again, total volume holds, and the implementation is judged a disappointment for reasons nobody can articulate.

The underlying error is treating WISMO as an information availability problem. It is an information delivery problem. A customer contacts you when their expectation and their knowledge diverge and nothing has closed the gap for them. Making the information available somewhere does not close it; sending it does.

This is also why “out for delivery” fails as a status. It is accurate, it is real-time, and it answers a question the customer did not ask. They want to know whether to be home at three, and “out for delivery” is compatible with arrival at any point in the next nine hours.

The three things that actually reduce it

1. Proactive notification at customer-meaningful milestones

Not carrier events. Carrier scan taxonomies were designed for custody and billing, and most of their events mean nothing to a recipient. Departed facility, arrived at sort, in transit: these are internal states that generate anxiety rather than resolving it, because a customer reading them concludes that something is happening and cannot tell whether it is going well.

The milestones that matter to a customer are few: your order is confirmed for this date, it is arriving today in this window, it is arriving shortly, it has arrived, and here is what happened if it did not. Everything else is noise that increases contact rather than reducing it.

2. An ETA precise enough to act on

Precision is what makes a notification useful. A four-hour window tells the customer to stay home; a thirty-minute window tells them when to be there. The second removes the reason to check, the first creates one.

Precision has to be earned rather than declared, since a narrow window that is frequently wrong generates more contact than a wide one that is reliable. What matters commercially is that customers will trade speed for certainty: McKinsey found speed fell from consumers’ number one delivery priority in 2022 to fifth by 2024, displaced by reliability and predictability, with around 90 percent willing to wait two to three days when delivery is free and arrives within the stated window.

3. Exceptions surfaced before the customer notices

The highest-leverage intervention available. A delay communicated proactively, with a revised time and a choice, generates a fraction of the contact volume of the same delay discovered by the customer. It also produces a different emotional outcome: one is a demonstration of competence, the other is a failure the customer has to solve.

This requires the exception to be detected in execution and to trigger communication automatically, which is where most stacks stop. Gartner found that while 95 percent of supply chains must react quickly to change, only 7 percent can execute decisions in real time.

Where the pipeline breaks

The chain that has to work runs carrier and driver signals into the dispatch layer, dispatch state into the notification layer, and notification out to the customer.

Most implementations connect the first link and the third and leave the second incomplete, which produces a specific failure: the notification layer knows what the carrier last scanned, not what the driver is currently doing.

That distinction determines everything downstream. A last scan tells you the parcel left a facility this morning. Driver progress tells you it is stop fourteen of nineteen on a route running forty minutes behind, which is the only input from which a useful ETA can be produced. A notification layer fed by scans can send timely messages containing nothing actionable, which is a fast way to train customers that your notifications are not worth reading.

Three requirements follow.

Driver progress has to reach the notification layer, not just carrier milestones. Where the final leg is subcontracted, this means the carrier has to expose progress at a granularity most do not by default, which is a procurement conversation as much as a technical one.

Notification has to be generated from the dispatch decision, not from a status field updated afterwards. Otherwise a revised time can be sent that the operation has already superseded.

Exception detection has to sit in execution, since a notification layer cannot detect what the dispatch layer has not yet concluded.

How to measure whether your implementation worked

Total WISMO volume before and after is the wrong measurement, because volume moves with order volume, seasonality, and channel mix, and any of those can hide or fake an effect.

Measure contacts per thousand deliveries, split by notification coverage.

Cohort A: orders that received a proactive notification at each intended milestone, including an exception notification where an exception occurred.

Cohort B: orders that did not, whether through a failed send, a missing channel, or a gap in the trigger logic.

Every implementation has both cohorts, usually with more in B than anyone expects, and the difference between their contact rates is the effect of your implementation isolated from everything else. It is also a number your CFO will accept, because it is a within-period comparison rather than a before-and-after claim.

Three refinements make it sharper. Segment by whether an exception occurred, since the effect concentrates there. Track repeat contacts separately, because a single contact resolved is a different outcome from three contacts unresolved. And measure notification coverage itself as a metric, since most teams discover coverage is materially below what they assumed once they look.

That coverage figure is usually the finding. Implementations rarely fail because notifications do not work. They underdeliver because notifications reach a smaller share of orders than anyone realised.

Where Locus fits

Locus, the world’s first Decision-Intelligent, Agentic TMS, sits in the dispatch layer, which is where driver progress originates rather than where carrier scans arrive.

Within DiSCO, the Dispatch agent plans and re-sequences against 250+ real-world constraints on live events, and the Customer agent generates the notification and the revised commitment from that decision rather than from a status field. Because the two sit in the same layer, an ETA sent to a customer reflects the resequencing that just occurred rather than the plan as it stood at departure. Control Tower gives operations and customer service one view, so a support conversation and the operational reality do not diverge.

The relevant capability is not notification delivery, which any messaging platform provides. It is that the content of the notification is produced by the system that made the decision.

Locus has been recognized by Gartner for seven consecutive years, featured in the 2026 Hype Cycle for Supply Chain Execution and Logistics Technologies, named a Leader in TMS by QKS Group (SPARK Matrix), and ranked #1 in Route Planning on G2’s 2026 Best Software Awards. In October 2025, Ingka Investments, the investment arm of Ingka Group, the world’s largest IKEA retailer, acquired Locus. Locus continues to operate independently.

Two deployments show the mechanism producing the outcome. A leading ASEAN apparel retailer had been showing only a rough lead time at checkout, because no accurate date could be computed across a fragmented carrier mix, and every carrier reported events in its own status codes. That produced hundreds of thousands of delivery and returns complaints in a single half-year. With a network-aware delivery date at checkout, harmonised carrier statuses, and every shipment tracked to its promise on the retailer’s own site, WISMO and returns queries fell more than 40 percent while delivery SLA held above 99 percent.

A leading Canadian grocery brand had the exception half of the problem: status scattered across carrier portals, support hunting for updates ticket by ticket, and with no delay alerting the first signal of a late order was usually the customer, after the freshness window had closed. With one view, live status, audit history, and real-time SLA alerts, support resolution became 10 to 20 times faster.

The check to run this week

Pull last month’s WISMO contacts and match each one to whether that order received a proactive notification.

If contact rates are similar across both groups, the notifications are not carrying useful information, and the problem is content or timing rather than coverage. If they differ substantially and coverage is low, the mechanism works and the problem is reach.

Those two findings lead to entirely different remediation, and most teams cannot currently tell which one describes them.