← Back to Work
Process file · Logistics Logistics

What’s inside: monitoring · step-by-step flow

One damaged pallet, one claim, the photos already attached

The question this file answersWho in my office is rebuilding a damage claim from scratch while status emails pile up around it?

Fits: logistics teams where claims and exceptions share an inbox with routine mail.

Typical day

What the desk looks like today

Typical, though unmeasured — the logistics playbook counts no claims separately, so neither do we. Damage, shortage and refusal claims share a mailbox with “where is my shipment?”. A clerk opens the driver’s photos, finds the shipment in the TMS and writes to the carrier from a blank page.

What changes

What Monday looks like after

On the day a big customer complains, the claims clerk opens a short queue of files that already hold the POD, the photos and the shipment — instead of hunting for them in three places. The status questions never reach that queue; you can see, per claim, when it opened and what was attached.

Typical, not a measured client result. Every figure here comes from the playbook source named below.

One claim file

POD, photos and shipment in one file before anyone writes to the carrier — same build as our BOL/POD-to-tracking file; no published figure for claims admin

Before: a clerk rebuilds each damage claim from scratch while status mail piles up around it. After: clean deliveries update tracking on their own; a claim opens with the documents already attached. No percentage: the DHL dispatch-document figure stays with the parent file.

No published figure for this desk. The range lives on the parent file: POD photos, PDF bills of lading, “where is it?” →

How this file is built

No published benchmark covers claims administration at a forwarder. The DHL pilot (2022) figure of ~55% less manual handling belongs to dispatch-document processing and stays on the parent file; we do not apply it to claims. Not a recovery-rate claim.

What we install

What we put in front of the systems you already run

Your TMS and tracking portal stay — CargoWise, project44, SAP TM — whichever you run. The same document-reading build as our BOL/POD-to-tracking file, with one extra sorting step:

  1. inbound PODs and delivery mail are read and classified — clean, damaged, short, refused
  2. clean deliveries update tracking through the API or the import you already use
  3. anything marked damaged, short or refused opens a claim file for the claims clerk with the POD, the photos and the shipment record attached, and nothing is sent to the carrier without them.
What stays human — and what this will not do

Liability. Reading the photos. The argument with the carrier. Customer goodwill. No model closes a claim.

Not a recovery-rate claim.

What can go wrong — and what we do about it

A photo that shows nothing useful still opens a claim — the clerk decides, the system only collects. If your POD photos arrive on paper, or by WhatsApp to the driver’s own phone, there is nothing to read until that changes.

What it costs to get there

The path: free 60-second estimate → free 20-minute review → paid audit of this one process (€1.5–3K, typically two weeks) → pilot with your people in the loop (€10–20K, weeks, not quarters). No transformation programme. Prices are public, on the services page →

Scoped in the audit — the playbook has no estimate for this exact desk.

This is about you if…
What does this mean in euros?

That depends on your volumes and wage costs — this page will not invent the number. The free 60-second estimate runs that calculation from your answers, with every multiplier sourced.

Get your free savings estimate 60 seconds · no sales call Or write first → Map a logistics process like this one — free, 60 seconds →

Not a named Aperanda client. Process file · Logistics.

Short process file. Same build as its parent file; the playbook has no separate volume or benchmark for this desk.

All process files