DPD tracking statuses read a little differently from other carriers, and the very first one causes the most confusion: "order data transmitted to DPD" regularly sends shoppers to support asking why nothing is moving. Nothing is wrong. Nothing has shipped yet either.
Here is what each DPD status means in practice, in the order a parcel normally moves through them, and the small number of statuses that should trigger action from your store rather than patience.
The normal DPD sequence
Order data transmitted to DPD. Your store created the shipment and sent the data. DPD has not touched the parcel. This is the status behind the widely searched question "what does parcel data submitted to carrier mean": it means a label exists, not that a parcel is traveling. If it lasts more than a day, the delay is in the warehouse, not at DPD.
Parcel handed to DPD / received by DPD. First physical scan. The parcel is genuinely in the network now, and the delivery window starts counting from here.
At parcel delivery centre / in transit. Moving between DPD depots. On domestic lanes this phase is usually a day. Cross-border parcels repeat it at each hub, which is normal.
Out for delivery. On the van, with DPD typically showing a predicted delivery window. Most parcels complete the same day.
Delivered / delivered to your preferred neighbour. Done. DPD records who accepted the parcel or where it was left.
Delivered to Pickup parcelshop. A frequent ending in Europe and a happy one: the parcel is waiting at a pickup point, and the customer usually has around a week to collect it. Worth showing prominently on your tracking page, because "delivered" without "to a parcelshop" reads like a missing parcel to someone who was home all day.
The statuses that need action
Consignee not located / delivery not possible. A failed attempt. What matters is the follow-up line: reattempt tomorrow, redirect to a parcelshop, or held at depot. If your system reads this scan in real time, you can tell the customer their options before they discover a card in the mailbox, which is exactly the kind of routine work AI agents handle without a human touching it.
Back at parcel delivery centre. The parcel returned to the depot after a failed attempt or a routing problem. One occurrence is routine recovery. Repeats mean the address needs checking.
Returned to sender. Unclaimed from a parcelshop, refused, or undeliverable. This should open your returns flow automatically so the refund or reship decision happens while the parcel is still in motion.
DPD across Europe: same network, different words
DPD operates as a federation of national businesses, so the same milestone carries different wording in the UK, Germany, France, and the Nordics, and sometimes a different level of detail. A brand shipping three DPD countries is effectively parsing three status vocabularies.
That is the general carrier problem in miniature. Carriers emit anywhere from 10 to 115 distinct statuses each, and none of them agree on wording. Pango normalizes DPD's variants, along with PostNord, Instabee, DHL and 100+ other carriers, into one consistent set of milestones, so your tracking page, notifications, and support view speak one language regardless of who carries the parcel. The same feed drives routing decisions, so lanes shift when a carrier has a bad week.
The bottom line
DPD's happy path runs from "order data transmitted" to "delivered" with little need for attention. The action statuses are failed attempts, "back at delivery centre", and "returned to sender", and acting on them at scan time is what keeps tickets down. Pango turns DPD's raw feed, and every other carrier's, into one clean status set that can act on itself. See the post-purchase operations platform and book a demo.
