Ten years ago a large share of logistics contact was people asking where their shipment was. Almost all of that is now self-served through tracking pages, carrier notifications and marketplace order screens. The calls, chats and emails that remain are the ones tracking could not answer: the late, the damaged, the held at customs, the misrouted, and the delivered to the wrong address.

That changes what a support programme is for. It is no longer a queue of lookups with the occasional problem mixed in. It is a queue of problems. Anyone scoping outsourced logistics support against the old shape of the work will build the wrong team, train it on the wrong material and measure it on the wrong things. This article sets out how we think exception handling should be scoped, staffed and reported when it moves to an outsourced team.

Scope for exceptions, not volume

An exception is any shipment whose actual state differs from its promised state, where the difference matters to the customer or the consignee. The common families: delays past the promised window, damage discovered on delivery, shortages and mis-picks, holds at customs or at a carrier depot for missing paperwork, address failures, failed delivery attempts, and returns that stall in reverse logistics. Each has its own cause, its own fix and its own information trail, and each tends to arrive as an angry contact because the customer already checked tracking and found it unhelpful.

The useful discipline is to write these families down before scoping anything. A list of ten or twelve exception types, with the typical cause and the action that closes each, becomes the training syllabus, the reporting taxonomy and the basis for deciding what an agent may do. Without it, every conversation with a provider stays at the level of customer service for a logistics company, which describes nothing.

A programme sized against total historical contact will be trained and staffed for a job that no longer exists. The useful number is exception volume by type and by hour, and the useful skill profile is problem resolution rather than information lookup. These are different hires and different scripts. An information lookup agent needs speed and a good search habit. An exception agent needs to read a shipment history, work out what went wrong, decide which of three or four remedies applies, and explain it to someone who is already annoyed.

The staffing arithmetic changes too. Exception contacts run longer, involve more hold time while a carrier portal is checked, and generate follow-up work after the call ends. Scoping on handle-time assumptions borrowed from a retail customer service line will leave the team short from the first week. During the discovery call we ask for exception counts by type and the time each currently takes an internal team member, and we build the plan from that rather than from total call volume.

Resolution authority is the whole game

The single largest variable in whether outsourced logistics support helps is what the agent may authorise without asking. An agent who can issue a reship, approve a credit, file a carrier claim, or rebook a delivery closes the contact. An agent who can only log it has added a step to a process the customer was already unhappy with, and the customer will call back, which doubles the cost of the exception and halves the goodwill.

Set this first. Define, in writing, before launch:

  • The value an agent can credit or refund unilaterally, and the value that needs a second approval.
  • Which remedies are available for each exception type: reship, refund, partial credit, redelivery, or collection.
  • When a carrier claim is filed, by whom, and what evidence it needs.
  • What the agent tells the customer while a decision sits with someone else, and the time by which it will be made.
  • Who inside your business owns the escalations the agent cannot close.

Systems access is where programmes stall

Every hour spent settling authority before launch is repaid in escalations that never happen. Programmes that go live with use your judgement as the policy produce inconsistent outcomes, and inconsistency is what customers complain about publicly. The second thing that stalls a launch is access.

Exception work requires visibility into the same systems your internal team uses: the transport management system, the warehouse system, the carrier portals, and whatever holds the order and the customer's contact history. Provisioning that access is almost always the longest item at launch. Programmes that go live without it spend their first months relaying information rather than resolving anything, and the relaying is done by the very internal staff the programme was meant to relieve.

Our project manager maps the process and prepares the systems before agents are trained, which is when the access list gets written. It should include read access to shipment history, write access to whatever records the remedy, and named logins for each carrier portal rather than a shared one, so that actions are traceable to a person. Role-based access and controlled permissions are part of how we work; the scope of that access is defined with you during onboarding. See inbound call centre services for how the live-contact side is structured.

The carrier is a third party in every call

Most exceptions involve someone who is not on the call. The carrier lost it, the customs broker is waiting for a form, the last-mile partner marked it delivered. Your agent is mediating between a customer who wants an answer and a third party who has not given one yet. That makes two things essential.

First, the agent needs a documented route into each carrier: which portal, which escalation address, which reference numbers to quote, and how long a response usually takes. Second, the agent needs a script for the interim. Telling the customer that the carrier has been contacted and that they will hear back by a stated time tomorrow is a resolution of sorts. Telling them nothing is known is not. Training agents on each carrier's own exception process, not only on yours, is a large part of the knowledge transfer and is often skipped.

Coverage should match when freight moves

Freight moves overnight and exceptions surface with it. A delivery attempted at seven in the morning, a truck that missed a cut-off at eleven at night, a customs hold flagged in another time zone: these generate contact before any office opens. A support arrangement staffed only to office hours is structurally missing contact rather than occasionally missing it, and the gap shows up as a backlog every morning that colours the whole day.

Coverage does not have to be the full team around the clock. It can be a smaller exception desk overnight with clear authority limits, backed by a morning handover. Our after-hours answering service is built for that shape. What matters is that the overnight desk can act on the common exception types rather than only take messages. The related piece on what round-the-clock support really takes covers the staffing arithmetic.

Knowledge transfer: teach the failure modes

Agents learn a logistics operation fastest when they are taught how it breaks. Product training alone tells them what you ship. Failure-mode training tells them what to do when a pallet arrives short, why a particular lane is always late in winter, which packaging fails in transit, and which customers have contractual delivery windows that turn a delay into a penalty. That knowledge lives in the heads of your best internal coordinators and needs to be written down during onboarding.

We train agents around your process and standards, and for logistics that means walking through real recent exceptions end to end: the contact, the investigation, the remedy, the follow-up. A dozen worked cases teach more than a policy document, and they give quality reviewers a benchmark to score against after launch.

Report by cause, not by count

Counting exceptions tells you how busy the team was. Grouping them by root cause tells you which ones can be removed entirely: a mislabelled lane, a carrier that consistently misses a window, a packaging spec that fails in transit, a warehouse picking error that shows up as a shortage claim. That reporting is where an outsourced team earns more than its cost, because each removed cause removes contacts permanently.

The reporting rhythm is agreed with you up front. For exception handling we recommend that it include exception volume by type, remedy issued, cost of remedies, carrier performance against promised windows, and a short narrative on the causes that recurred. That last item is the one operations leaders act on. The rest is context.

The easy contacts already left. What remains is the hard half, and the hard half has causes.

When outsourcing exception handling is the wrong move

It is the wrong move when you cannot yet describe your exception types, when systems access cannot be granted to anyone outside the company, or when nobody internally will own the escalation queue. It is also the wrong move if the real problem is upstream: a warehouse that mis-picks at a rate no support team can absorb, or a carrier contract that should be renegotiated. A support programme handles the consequences of those problems well but does not fix them, and paying for excellent handling of avoidable exceptions is poor value.

If those conditions are met, the work outsources well because it is repeatable, documentable and measurable. The logistics and transportation page sets out the service mix, and the back office outsourcing page covers the claims and reconciliation work that sits behind the front line.

How to evaluate a provider for this work

Ask how they scope: if they quote from total contact volume without asking about exception types, they have not done this before. Ask what their agents will be authorised to do and how that authority is enforced in the workflow. Ask how carrier access and TMS access are provisioned and how long that takes. Ask for the reporting format and whether it groups by cause. Ask how overnight exceptions are handled. And ask who your project manager is and how the process is documented before launch, because the documentation is what survives agent turnover. The answers will tell you whether you are buying exception handling or a generic queue with a logistics label on it.