Your IT desk answers for the courier. Not because anybody decided it should, but because the thing in the box is an IT asset, so every question about where it is and why it is held arrives in the IT queue.

TL;DR

  • Shipment questions land on IT because the device is an IT asset, even though IT controls neither the courier nor the customs process.
  • Most of the volume is status anxiety rather than genuine problems, and status anxiety is solved by proactive information.
  • Send the tracking reference and a realistic transit window at dispatch, in the recipient’s language. That removes the majority of tickets.
  • Define the handoff: which questions IT answers, which go to logistics or the vendor, and who owns a held shipment.
  • A held shipment is the expensive category. Decide in advance who pays a charge and who can authorise it.
  • Never let the requester be the one chasing the courier. They have the least information and no account with the carrier.

Why these tickets reach IT at all

From the employee’s side the logic is sound. IT sent the laptop, so IT knows where it is. The fact that the shipment is handled by a procurement team, a lifecycle vendor or a courier account owned by finance is invisible and irrelevant to them.

The result is a queue absorbing a category of work it has no tools for. An agent with no visibility into the shipping platform ends up relaying questions to another team and answers back, which doubles the handling time and adds a day to every exchange.

Trying to redirect these tickets at the queue is a losing battle. Better to accept they arrive and decide deliberately what IT does with them.

Most of it is status anxiety

Sort a month of these tickets and the large majority will be variations on where is it and when will it arrive, from people who have no tracking reference and no expectation of a date.

That is not a logistics problem. It is an information problem, and it is solved before the ticket is created. Sending the tracking reference, the carrier, a realistic transit window and what to do if nothing arrives, at the moment of dispatch, removes most of this volume outright.

Realistic is the operative word. A transit estimate that ignores customs for international shipments produces a ticket on the day it is missed, which is worse than having given a wider window.

A worked example

A company shipping roughly fifteen devices a month internationally was seeing about 30 shipment-related tickets in the same period, two per device.

Sorted by content, 19 were status questions with no tracking reference in hand, 6 were about a charge demanded on delivery, 3 were held shipments needing paperwork, and 2 were damage on arrival. The 19 existed entirely because nothing was sent to the recipient at dispatch.

Adding an automated dispatch message with the carrier, the reference, a window that accounted for customs, and a line stating the company pays any import charge took the monthly total from about 30 to about 9. The remaining nine were real work.

Defining the handoff

The nine that remain need an owner, and the failure mode is that each one is handled slightly differently depending on who picks it up.

What to do:

  • Send carrier, tracking reference, realistic window and a no-show instruction at dispatch, in the recipient’s language.
  • State explicitly, at dispatch, who pays any import charge. This is the second largest ticket category.
  • Write down which shipment questions IT answers and which route to logistics or the vendor, with names.
  • Name who can authorise paying a charge or releasing a held shipment, and their backup.
  • Give the IT desk read access to the shipping platform, or accept a relay delay on every ticket.
  • Never ask the recipient to contact the carrier themselves, since they hold no account and the least information.

Read access is the item that pays for itself fastest. An agent who can look up a tracking status resolves a question in one exchange rather than three.

The held shipment

This is the category that costs real time, and it is where language compounds the problem. A customs query is usually addressed to the recipient, in the local language, with a short deadline and a request for documentation they do not have.

The recipient cannot resolve it and the company often does not know it has happened, because the notice went to an individual rather than to a shared address. Days pass, storage charges accrue, and in some cases the shipment is returned.

Prevent it by telling the recipient at dispatch exactly what to do if contacted about customs: forward it immediately to a named address, do not pay anything, do not respond directly. That single instruction, in their own language, is worth more than any amount of post-hoc chasing.

What self-service can and cannot do

A document-trained assistant handles the generic half of this well: what the usual transit time is, who pays duty, what to do about a customs notice, what happens if a device arrives damaged. Those answers are stable and identical for everybody, and they can be given in any language.

What it cannot do is tell somebody where their specific parcel is, because that requires a live lookup against a carrier system. Expecting it to close the status category is the common disappointment, and the fix for that category is the dispatch message rather than the assistant.

Used together they cover most of it: proactive dispatch information removes the status questions, and self-service answers the policy questions in the recipient’s language. Our multilingual IT support comparison covers the options.

Final thoughts

Shipment tickets are not really a logistics problem arriving in the wrong queue. They are an information problem, and the majority of them are created by sending a device to somebody without telling them anything about it.

Send the carrier, the reference, a window that accounts for customs, who pays any charge, and what to do if contacted about duty, all at dispatch and in the recipient’s own language. Then name the owner for held shipments and give the desk read access to the shipping platform. The residual volume is small and genuinely worth somebody’s time.

Frequently asked questions

Why do shipping questions end up in the IT queue?

Because the item being shipped is an IT asset, so from the employee’s point of view IT sent it and IT should know where it is. The fact that the shipment is handled by procurement, a lifecycle vendor or a courier account owned by another team is invisible to them and largely irrelevant. Trying to redirect these at the queue rarely works, so it is more productive to accept that they arrive and decide deliberately what the desk does with each type.

What removes the most shipment tickets?

A dispatch message containing the carrier name, the tracking reference, a realistic transit window that accounts for customs, who pays any import charge, and what to do if nothing arrives. The large majority of these tickets are status questions from people holding no reference and expecting no date, which is an information problem solved before the ticket exists rather than a logistics problem. Send it in the recipient’s own language, since this is exactly the content that gets read once and acted on.

Who should handle a shipment held in customs?

A named person with a named backup, decided in advance, because this is the category where days are lost to nobody owning it. The underlying difficulty is that a customs query is usually sent to the recipient in the local language with a short deadline, asking for documentation they do not have, so they cannot resolve it and the company frequently does not know it has happened. Tell recipients at dispatch to forward any customs contact immediately to a named address, pay nothing and respond to nobody directly.

Should the employee chase the courier themselves?

No, because they hold no account with the carrier, have the least information about the shipment and in many cases cannot be given a meaningful answer even if they call. Asking them to do it transfers your administrative problem to somebody who is already waiting for equipment they need to work, and it tends to produce a second ticket when the call goes nowhere. Give the IT desk read access to the shipping platform instead, which turns a three-exchange relay into a single answer.

Can a support chatbot answer shipping questions?

It handles the generic half well and the specific half not at all, which is worth understanding before deploying one against this category. Questions about typical transit times, who pays duty, what to do about a customs notice and what happens if a device arrives damaged are stable policy answers that can be given accurately in any language from your own documentation. Telling somebody where their particular parcel is requires a live lookup against a carrier system, so that category is fixed by the dispatch message rather than by self-service.

How should we communicate who pays import charges?

At dispatch, explicitly, in one sentence, in the recipient’s language, because a charge demanded on delivery is one of the larger ticket categories and it arrives at a moment when the employee has to decide something immediately. Stating that the company covers any import charge and that they should forward the demand rather than paying it removes both the ticket and the risk of somebody paying out of pocket and claiming it back. If the arrangement is different, say that instead, but say it before the courier is at the door.