3PL automationcarrier claimsparcel investigationslogistics automationFreshdesk automationDHL

How to automate carrier claims and parcel investigations in a 3PL

By Harshil Lakhani ·

In short

To automate carrier claims in a 3PL, let sellers open an investigation from a known order with the evidence the carrier needs, route it to the carrier by email or by a bot that fills the carrier's support portal, classify every reply as receipt, question, progress or verdict, and keep the seller updated in one thread until a verdict or credit closes it.

Automating carrier claims means a seller opens an investigation from a known order, the system sends it to the right carrier by email or through the carrier's support portal, and every reply is read and sorted into receipt, question, progress or verdict. The seller sees one thread from start to credit. The warehouse team only steps in when the carrier asks for something a machine cannot give.

I built this for a Dutch 3PL fulfilment company that ships for a few hundred sellers through DHL, PostNL, bpost, DPD, Evri, Colis Privé and Bring. Here is how it works, including the parts that broke.

Why are carrier investigations so slow for 3PLs?

A lost parcel involves four parties: the end customer, the seller, the 3PL and the carrier. Before automation, a seller emailed the support desk, the team looked up the shipment, wrote to the carrier, waited, forwarded the reply, waited again, and tracked the credit in a spreadsheet.

The slow parts were always the same:

  • missing tracking links or order references
  • the wrong carrier contact, especially for DHL
  • carrier replies buried in a shared inbox
  • carriers asking for an invoice or photos days later
  • nobody remembering to chase a case that went quiet

What should a seller submit to open an investigation?

The seller starts from an order they can already see in the seller portal, so the reference is always valid. The form then asks for:

  • order reference and carrier
  • tracking URL
  • reason for the investigation
  • parcel dimensions and a summary of the contents
  • confirmation of a short review checklist
  • optional: customer email, sales invoice, purchase invoice, photos and a question

The reasons are fixed: damaged parcel, no tracking updates, incorrect address, customer reports parcel not delivered, wrong product delivered, and no drop-off scan. Fixed reasons make routing and reporting possible.

One order can have only one open investigation. A seller who submits the same order twice is shown the existing case.

How do you route a claim to the right carrier?

Routing is where most manual mistakes happened. Some carriers handle claims by email. Others only accept them through a support portal. In this setup, DHL Netherlands takes email, while DHL Germany, Evri, Colis Privé, bpost, Bring and DPD go through a carrier partner's Freshdesk portal.

The DHL problem

"DHL" alone does not tell you which DHL. The shipping method name might say "DHL E-Commerce Nederland", "DHL for You", or a German parcel service. The rule I use:

  • a Dutch indicator in the method name (NL, Nederland, brievenbus, vandaag) means DHL NL
  • a tracking code starting with 3S or JVGL means DHL NL
  • anything else with DHL falls back to the portal route

The safe fallback matters. An email to the wrong DHL desk gets no answer at all. A portal ticket at least gets a reply saying where to go.

Internal reasons

"Wrong product delivered" and "no drop-off scan" are usually the warehouse's own mistake. Those cases go to the internal service team with the same evidence, not to the carrier.

Unsupported carriers

If a carrier has no claim route, the seller is told right away and the case is closed, so they can resubmit later if a route is added.

How does carrier portal automation work?

A Python service runs a stealth Firefox browser that logs in, fills the claim form, attaches files and submits it. The form has required fields such as the sales invoice and an optional non-receipt declaration, with dropdowns that need real pointer events to register.

Lessons from running it daily:

  • One browser at a time. Parallel sessions overwhelmed the single sign-on login, so a global lock serialises them.
  • Capture failures. If the form does not submit, the bot scrapes the validation errors on screen and saves a screenshot.
  • Check before you open. Reading every open ticket in a browser every fifteen minutes meant over 800 browser launches a day. Now a plain HTTP request fetches a fingerprint of the ticket in about half a second. The browser only opens when something changed.
  • Read closed tickets once more. A late reply can arrive just before closure, so a closed ticket is read in full one last time.

How do you classify carrier replies?

Every carrier email is sorted into one of five kinds:

  • Receipt: "your message has been registered". No news, nothing changes.
  • Question: the carrier wants an invoice, photos, more information, or could not prove delivery.
  • Still investigating: "we expect an answer within 5 working days".
  • Verdict: delivered, found, returned to sender, lost, compensated, or a duplicate case.
  • Unknown: a person reads it.

The rules work in Dutch and English, because carrier desks reply in both. The step that made them accurate was reading only the newest message. DHL quotes its earlier "investigation started" mail and our original question under every final answer. Without stripping quoted history, signatures and DHL's standard "due to high volume" notice, verdicts stayed open and questions got closed.

Order matters too. Receipt is checked first, then questions, then firm verdicts such as a credit note, then "still investigating", then softer verdicts. A sentence like "credit note within a few working days" is a verdict, not a delay.

Only a verdict closes an investigation. A question or progress update reopens a closed one if someone needs to act.

Mail that matches nothing

An unmatched carrier mail goes to a manual review label in Gmail. One special case: DHL sometimes mails the outcome of a case the consignee opened. If the order belongs to a known seller, the system creates an investigation for it, so the answer is not lost.

What evidence do carriers ask for?

Most delays come from the second request. Collect these up front:

  • sales invoice and, for higher values, the purchase invoice
  • photos of the parcel and the damage
  • dimensions and weight
  • contents description
  • tracking link with the last scan
  • a signed declaration of receipt (DOR) from the consignee

Each carrier has its own DOR form. When a carrier message mentions a DOR, the system attaches the correct form for PostNL, DHL Germany or bpost to the seller's message, so the seller does not have to find it.

How do you keep sellers updated?

The seller portal shows each investigation as a conversation. Carrier replies are forwarded into it. When the seller answers, the reply goes back to the carrier in the same email thread or portal ticket. Status is simply open or closed, because sellers do not need eight internal states.

Two timers keep cases moving:

  1. An email case with no activity for five days gets an automatic reminder in the same thread.
  2. A failed send is retried after 24 hours, checked once an hour instead of every 15 seconds.

How do you track carrier credits?

When a carrier confirms compensation, the investigation records a credit status. A credits page shows each seller their total. It separates "credit registered by the carrier" from "money paid", because those are different events, and mixing them creates support tickets.

The investigation workflow, step by step

  1. The seller picks an order and submits the reason and evidence.
  2. The system blocks a duplicate open case for the same order.
  3. The carrier is resolved from the shipping method and tracking prefix.
  4. The case goes to the carrier by email, by portal bot, or to the internal team.
  5. Replies are matched to the case and classified.
  6. Questions are forwarded to the seller, with DOR forms attached when asked.
  7. Quiet cases get reminders after five days.
  8. A verdict closes the case and any credit is recorded.

What should you measure?

  • open investigations per carrier and age of the oldest
  • days from submission to first carrier reply
  • days from submission to verdict
  • share of cases where the carrier asked for more evidence
  • verdict mix: delivered, lost, returned, compensated
  • credits registered per carrier per month
  • replies the classifier marked unknown

The unknown rate is your quality check. If it rises, a carrier changed its wording.

Should you build or buy claims automation?

Buy a claims tool if your carriers have APIs for claims and the tool supports them. In the Benelux, many carriers still run claims through email and support portals, and sellers expect to see progress in the same portal where they see their orders. That pushed this project toward a custom build.

Carrier claims automation checklist

  • Start every case from a real order
  • Make evidence fields required before submission
  • Route DHL by country, not by brand
  • Send internal faults to the warehouse team
  • Read only the newest message in each reply
  • Close only on a verdict
  • Attach the right DOR form per carrier
  • Remind after five quiet days
  • Track credits separately from payments

This is part of the logistics automation services I build for fulfilment companies. See the 3PL logistics investigation platform case study and the carrier portal automation bot behind the portal route. Many claims start at the returns bench, so also read how to automate returns processing in a 3PL.

Spending hours a week chasing carriers? Contact me and I will map your claims flow.

Frequently asked questions

Damaged parcels, parcels with no tracking updates, wrong addresses, parcels the customer says never arrived, and parcels with no drop-off scan. Wrong product delivered and missing drop-off scans are often the warehouse's own issue, so in the system I built those two go to the internal team first instead of the carrier.

Yes, with browser automation that fills the portal's claim form, attaches files and reads ticket replies. Run one browser session at a time if the portal uses single sign-on. Before opening a browser to read a ticket, check over plain HTTP whether it changed. That cut hundreds of browser launches a day in my setup.

Read only the newest message, then sort it into receipt, question, still investigating, verdict or unknown. Strip quoted history, signatures and standard busy notices first, because carriers quote their earlier mails under a final answer. Only a verdict closes the case. Anything the rules cannot read goes to a person.

A DOR is a declaration of receipt, or non-receipt, signed by the consignee to confirm whether the parcel arrived. Carriers such as PostNL, DHL Germany and bpost each use their own form. When a carrier asks for one, the system attaches the right form for that carrier to the seller's message automatically.

Five days without any activity is a sensible default. In my system an open email investigation with no reply and no reminder for five days gets a reminder sent in the same email thread. A failed send is retried after 24 hours, and portal tickets are checked every fifteen minutes instead.

Need an automation like this?

Tell me what your team does by hand and which tools are involved.

Discuss your project