Direct answer
Shipment exceptions are handled well when each one becomes a record with a type, a named owner, a clock and a next action, and when the client is told before they ask. Handled badly, an exception is a thread in someone's inbox that gets answered when that person next looks. The mechanics are simple: define the exception types, decide how each is detected, assign an owner at once, set a time to the next update and log how it was resolved.
This page is specific to freight operations. It works from statuses your own staff update; it does not claim live carrier tracking or automatic feeds. If a carrier offers an API, using it as a source is a per-project decision, not an assumption here. For the general design of escalation rules in any workflow, see workflow exception and escalation design.
Define your exception types
You cannot manage what you have not named. Start with the exceptions your team actually meets and give each a short, agreed name and a default severity. Keep the list short enough that people will use it.
- Delay: a milestone is later than planned
- Missing or incorrect document that blocks movement
- Damage or loss reported on cargo
- Hold or inspection by an authority or terminal
- Booking change, rolled cargo or capacity problem
- Delivery failure: consignee unavailable, address issue, refused delivery
- Cost dispute or unexpected charge
Severity is a decision, not a feeling
Write down what makes an exception urgent in your business: a fixed delivery date, perishable or high-value cargo, a client tier, or a cost exposure. Then severity is applied by rule, and two people looking at the same case give the same answer.
Detection from staff-updated status
Without live feeds, detection depends on your team recording what they learn. That is workable if you design for it. Every shipment carries planned milestone dates and an actual status entered by staff. An exception can then be raised in three ways: a person flags it directly, a milestone passes its planned date without an update, or a status change matches a defined trigger (for example, a status of held).
The second one is the most useful. A rule such as a milestone overdue without a status change raises a review item automatically, so silence becomes visible. The honest limit is that this detects the absence of an update, not the real-world event itself. A shipment can be late for hours before anyone records it. Say so in your internal process and set the expectation with clients accordingly.
Owner and clock
Every open exception has exactly one owner. Shared ownership means no ownership. The owner is not necessarily the person who fixes it; they are the person who is accountable for progress and for the next client update.
- Assign by rule where possible: the shipment's account handler, or a duty coordinator by mode or region
- Set a next-action time when the exception is opened, and reset it every time an action is logged
- Show open exceptions on one working view, sorted by the nearest next-action time and severity
- Make reassignment an explicit step with a note, so handovers between shifts do not lose context
Client updates
Clients mostly want three things: to know early, to know what you are doing and to know when they will hear next. Agree on templates for the common exception types so updates are fast, consistent and factual. State what is known, what is not known, the action being taken and when the next update will come. Avoid speculating about causes or promising outcomes you do not control.
Log every update sent against the exception. If clients can see their shipments in a portal, the exception status can appear there as well, updated by staff. See freight customer portal for how staff-updated milestones are shown to clients without any live-tracking claim.
Escalation
Escalation should be a rule, not a mood. Decide the triggers and the target for each. Typical triggers are a severity level, an exception that has passed its next-action time without an update, a cost exposure above a threshold you set internally, or a client tier that warrants senior attention.
- Level one: the owner, reminded when their clock runs out
- Level two: a team lead, notified when the owner has missed a clock or the severity is high
- Level three: a manager or account director for exceptions that affect the client relationship or carry significant cost exposure
- Escalation notifies and records; it does not silently reassign the case
Resolution log
Close every exception with a resolution note: what happened, what was done, who was involved and what it cost or saved in terms your business tracks. Choose a small set of cause categories, such as supplier, carrier, client information, documentation or internal error, so the log can be analysed later. Free text alone is readable one case at a time and useless in aggregate.
Reporting and limits
Once the log exists, useful reports are simple: open exceptions by owner and age, exceptions by type and by cause, repeat causes by supplier or lane, and how many were overdue for their next update. These point to the process fixes worth making, such as a recurring document problem with one supplier.
The limits are worth stating plainly. Data quality depends on staff updating statuses. There is no real-time event detection unless a per-project integration is built where an API exists. And the workflow does not remove the need for judgement on hard cases. What it does is make sure nothing waits unseen. If you want to explore how this could be built around your operation, see logistics software development.
Questions
Does this include live carrier tracking?+
No. Detection here relies on statuses your staff update and on overdue milestones. Feeds from carriers are only possible per project where an API exists.
How many exception types should we start with?+
As few as your team will use consistently, often a handful. You can split a type later once the log shows it hides different causes.
Who should own an exception?+
One named person, usually the shipment's account handler or a duty coordinator. Their job is accountability for progress and the client update, not necessarily doing the fix.
Should clients see exceptions?+
Usually yes for their own shipments, with a factual status and the time of the next update. Internal notes and cost detail stay internal.
How is this different from general escalation design?+
General design covers any workflow. This page applies the idea to freight: shipment milestones, exception types, client updates and the resolution log.