Connecting track and trace: which carrier integration you need

In almost every webshop 'where is my order', or WISMO, is the single largest category of customer queries. In many teams it accounts for a substantial share of all incoming tickets, and that share rises the moment delivery comes under pressure. The frustrating part is that the answer usually already exists: the tracking code from PostNL, DHL or DPD knows exactly where the parcel is. The problem isn't missing information, but the distance between that information and the customer.

Many webshops do connect their carrier, but superficially: a tracking link in the confirmation email that the customer has to open and interpret themselves. As soon as anything deviates from the standard flow, the customer stops understanding what is happening. A short delay or a failed delivery attempt is enough to trigger a query. The integration exists, but it doesn't solve the problem.

That distinction between 'connected' and 'solved' is the heart of this article. An integration that only passes along a code moves the work to the customer. One that understands status, context and exceptions removes the work. Technically those two differ less than you'd think; in their effect on your inbox they differ completely.

Below is what a good track and trace integration does differently and why a link to a tracking page isn't enough. After that: how to set up shipping information so most WISMO questions never arrive as a ticket, and which questions you deliberately let reach a person.

A tracking link partially solves the problem for the customer willing to make the effort to search, click and interpret the status themselves. But a large share of customers won't do that. They want the answer directly, without visiting an external page that looks different from your webshop and is sometimes written in another language.

More importantly: a tracking link shows a status but gives no context. 'On its way' says nothing about whether that's normal or a delay. A customer seeing the same status for two days doesn't know if that's typical for this shipping partner or a sign something went wrong. Without that context, the customer sends a question anyway, even though the answer technically already existed on the tracking page.

There's a third layer underneath, and it's rarely named: a WISMO query often isn't about the parcel's location at all. The customer usually knows perfectly well that it's on its way. What they actually want to know is something else. Will it arrive in time for the birthday they bought it for? Do they need to stay home? Should they be worried? A tracking page answers the literal question and ignores the real one.

That explains why customers keep asking while the information is available. They aren't looking for a data point, they're looking for reassurance or a course of action. 'Your parcel was scanned in Duiven and will be delivered tomorrow between 2 and 4pm' does something 'in transit' doesn't, even though it's technically the same information.

One final practical point: the tracking link sits in the confirmation email, and by the time the question arises that email is often long gone. It's buried under newer messages, in spam, or in a mailbox the customer can't reach on their phone. The information has formally been provided but is practically unreachable, and the path of least resistance is a message to customer service.

A proper track-and-trace integration pulls the current status directly from PostNL, DHL or DPD. That status then appears in the customer's own channel: in chat, in an email reply or proactively as an update. The customer doesn't have to visit a separate page or retype a code. The answer is ready the moment the question is asked, with the current status instead of a snapshot from the moment of shipping.

Just as important is the proactive side. When a package misses a delivery attempt or runs into a delay, you can inform the customer before they ask about it themselves. That prevents the ticket and changes the tone of the contact. A customer who has to discover and report a delay themselves is a different conversation than one who already got an update.

The part where most integrations fall down is translating status codes. Carriers use their own terminology and their own number of intermediate steps, written for logistics staff rather than consumers. A status like 'shipment pre-announced' means only that a label has been created and the parcel is nowhere yet. A customer reading that assumes their order is on its way and gets angry when there's still nothing three days later.

A good integration translates those codes into plain language with an expectation attached. It does that per carrier, because the same words don't mean the same thing at PostNL and DHL. It's boring work you do once that permanently removes questions afterwards.

Equally important is that the integration knows what's normal. A parcel sitting at a sorting centre for a day is usually just part of the process; three days isn't. Without that distinction you are left with two bad options. Raising an alarm at every pause worries customers unnecessarily. Never flagging anything means real problems surface only when the customer calls. With the distinction you can be proactive exactly where it matters.

Once you can communicate proactively, the immediate question is how much to send. The answer is less than most webshops assume. A message for every scan turns your updates into noise customers dismiss, after which they also miss the message that mattered.

A workable rule is to communicate only at moments where the customer needs to know something or can do something. Confirmation the parcel has left the warehouse, the delivery day with a time slot, and any deviation from what you promised. The scans in between are interesting to you, not to the customer.

For deviations, form matters more than speed. Announcing a delay without a new expectation attached causes exactly the question you were trying to prevent. A message stating what happened, when the parcel is now expected and what the customer can do if that doesn't suit them, closes the subject.

The channel counts too. A half-day delay fits fine in an email. A failed delivery attempt where the customer has to arrange something today belongs in a channel that gets read immediately. Send everything through the same channel and you're too slow on urgent matters and too intrusive on routine ones.

Start by connecting your shipping partners directly to your customer service system, not just your webshop backend. Make sure the current status is available at every customer contact, regardless of which channel the question comes through: email, chat or phone. Then set up automatic answers for the most common WISMO variants, using the real status and expected delivery time, not a generic template.

After that, set up proactive triggers for deviations. A missed delivery attempt, a delay of more than a day, a package sitting at a sorting centre longer than expected. Every trigger you automate is a question that never arrives as a ticket. After rollout, measure how many WISMO tickets remain. Use that group to see whether a structural logistics problem sits behind it, one that deserves more than just an answer.

Measure the result per topic rather than as a total. The number of WISMO tickets says little while your order volume moves. What shows whether the integration works is the share of WISMO in your total volume, set against the number of shipments. A flat number of queries against a growing number of orders is a gain, even if your inbox looks the same.

Also look at what's left. Do the remaining questions cluster around one carrier, one region or one type of shipment? Then the problem is logistics rather than communication, and a better answer won't fix it. That analysis is one of the most useful by-products of a good integration: your inbox becomes a measuring instrument for your delivery process.

Automation works so well here that the temptation arises to intercept everything. That's precisely the mistake that turns a successful integration into a poor customer experience anyway.

A parcel marked delivered that never arrived isn't a status question but the start of a dispute. The customer is saying something different from the system, and an automated reply repeating the scan reads as 'you just didn't look properly'. That conversation belongs with an agent who can open an investigation and believe the customer.

The same applies to parcels missing for a while, visibly damaged deliveries, and situations where the customer needed the parcel by a specific date that has now passed. In all those cases the logistics status is known and isn't the problem; what the customer needs is a resolution and usually some form of compensation.

So set up the automation to recognise these cases and route them straight through rather than answering them. A customer who has to hunt for a human after two automated replies is angrier than one who got a human immediately. The gain from automation lies in the questions it can handle, not in the percentage you can just about push through it.