Carriers, 3PLs, and freight operators

AI worker teams for delivery exception recovery

Logistics is the one sector where the contact centre can be driven by an event feed rather than a phone queue. The exception is already known to your systems before the consignee notices — the failure is that nobody told them.

CARRIERS, 3PLS, AND FREIGHT OPERATORSCONSTRAINT ENVELOPE4 sector constraints designed to firstHUMAN AUTHORITY — NEVER AUTOMATED· Cost and priority authorisati…· Regulated, damaged, and tempe…· Claims and liabilityACTS WITH APPROVALThresholds and gates on anything with cost or risk attachedACTS WITHIN POLICY2 blueprints start hereAutonomy widens outward only on evidence from the recordearned autonomy
The authority boundary we design to in Logistics & delivery — autonomy widens outward from the centre, and only on evidence.

Our view

Where we think the real opportunity is

Every other sector in this catalogue waits for the customer to make contact. Logistics does not have to, and that changes the design fundamentally. A deviation is a structured event on a tracking feed, timestamped and classified, sitting in the TMS while the consignee is still expecting a delivery. The contact that follows twenty minutes later is entirely avoidable demand — and it arrives twice, once to ask and once to chase. So the highest-leverage intervention here is not better handling of inbound volume; it is inverting the direction of the conversation so the exception is communicated before it is discovered. The corollary is that this is one of the few blueprints where success shows up as a reduction in contacts rather than faster handling of them, and we instrument it that way. The second design commitment is about money: every recovery action — reroute, redeliver, compensate — has a cost, so the worker assembles the case and a supervisor authorises it.

Operating reality

How demand actually behaves here

Volume has a shape, and the shape is what breaks teams. This is what we assume about your operation before we design anything.

  • The exception is known before the customer knows

    Scan events, failed-attempt codes, and dwell times land in the tracking system minutes or hours before the consignee forms a suspicion, which is a window nobody currently uses.

  • One deviation generates repeated contact

    The consignee calls to ask, then calls again to chase, and often the shipper calls on their behalf. A single exception therefore produces several contacts across several parties.

  • Status truth is fragmented across parties

    The carrier, the 3PL, the shipper, and the driver each hold part of the picture, so the answer a consignee receives depends on which link in the chain they reached.

  • Not all freight is equal

    SLA-bound, perishable, and temperature-controlled consignments carry consequences that a standard delay does not, and they are indistinguishable in a queue ordered by arrival time.

Where the hours go

The cost we would try to move first

Almost every operation spends its most expensive time on its least valuable work. Naming that precisely is what makes a pilot measurable rather than impressive.

  • Chase calls that a notification would have prevented

    This is avoidable demand in the purest sense: contact generated solely because information the business already held was not passed on.

  • Manual reconciliation by dispatchers

    Cross-referencing tracking events, driver notes, and customer calls by hand consumes the people who should be solving the exception rather than describing it.

  • Recovery decided without cost visibility

    Reroutes and redeliveries authorised under time pressure, without the cost of the alternatives in view, is margin spent on the least considered option.

  • SLA penalties and lost shipper accounts

    The real cost of a mishandled exception usually appears in a contractual penalty or a renewal conversation, far from the contact centre that caused it.

The trust envelope

What constrains the design, and what never gets automated

We design to the boundary first. A control added after launch is a control nobody believes — and in this sector the boundary is not negotiable.

Sector constraints

  • Tracking events as the only source of truth

    Status may only be stated from confirmed events. An inferred delivery time is the most common cause of a second chase call and a broken promise.

  • Cost authorisation before any recovery action

    Reroutes, redeliveries, and compensation all spend money, so they sit behind a supervisor threshold rather than being granted to end a conversation.

  • Regulated and temperature-controlled handling rules

    Dangerous goods, pharmaceutical, and chilled consignments have specific handling requirements that a general recovery path must not touch.

  • Who the customer actually is

    The consignee, the shipper, and the account holder have different entitlements to information, and disclosure has to respect which one is on the line.

Stays human, permanently

These are structural boundaries, not trust levels waiting to be relaxed.

  • Cost and priority authorisation

    Deciding to spend on a reroute, or to prioritise one consignment over another when capacity is short, is a commercial and operational judgement with an accountable owner.

  • Regulated, damaged, and temperature-sensitive freight

    Where handling rules are specific and the consequences extend past a late delivery, a specialist owns the case from the first turn.

  • Claims and liability

    Loss and damage claims determine who pays, which makes them a contractual decision rather than a service action.

Where to start

Sequencing matters more than scope

The first blueprint should be the one whose success criteria your team already agrees on. Each step below links to the blueprint that implements it.

  1. Start

    Inbound status on one lane, read-only

    Answer shipment status from live tracking for a single lane or service level. Nothing writes and nothing is promised, which proves the status grounding before any money is in scope.

    Read the blueprint
  2. Then

    Flip to proactive notification

    Notify from the tracking feed before the consignee contacts you. This is the step that actually changes the economics, and the one to measure hardest — chase-call volume per exception should fall.

    Read the blueprint
  3. Next

    Recovery assembly, then shipper-side order care

    Add costed recovery options behind supervisor approval, then extend the same governance to the retail order-care journey your shipper clients are running.

    Read the blueprint

Systems we would expect to read and write

  • Transport management system
  • Carrier tracking and EDI event feeds
  • Warehouse management system
  • Shipper portal or CRM
  • Proof-of-delivery and claims tooling

Blueprints that apply

2 operating blueprints for Logistics & delivery

Each one carries the full team, process, and control detail — the mechanics this page deliberately does not repeat.

Push back on this

Objections we actually hear in Logistics & delivery

Answered as we would answer them in the room, including the cases where the right answer is that this is not for you.

Our tracking data is late and incomplete, so proactive notification would misfire.
Then start with inbound status only, and let the first stage measure feed quality honestly — how often an event is present, how late it lands, how often it is corrected. That measurement is worth having on its own, because your dispatchers are already absorbing that data quality problem manually. Proactive notification should only be switched on for the exception classes where the feed proves reliable, and we would scope it that way rather than notifying on everything.
Consignees are not our customers — the shipper is. Why would we contact them?
That is a genuine commercial question and it varies by contract. Where the shipper owns the end-customer relationship, the blueprint notifies the shipper and their systems instead, and the consignee-facing version runs under their brand or not at all. The disclosure rules differ by party, which is why entitlement is a constraint in the design rather than an afterthought.
Would this just add a notification channel and more contacts?
It would, if measured wrongly. That is why the primary metric is chase-call volume per exception rather than notifications sent — if inbound contacts do not fall, the notification is not doing its job and the content or timing is wrong. A blueprint that increases total contact while looking busy is a failure, and the instrumentation is set up to expose that rather than hide it.

Other sectors

How the argument changes elsewhere

Next step

Argue with this in a working session.

Bring your own numbers. We will map your version of the operating reality, agree what must stay human, and scope the first blueprint against a measurable win — or tell you it is not worth doing yet.