Proof of delivery your customer can fetch without asking you

“Could you send me the proof of delivery for Tuesday’s load to Gothenburg?” It is a polite email, and every transport office receives a steady trickle of them. It is the quieter sibling of the where-is-my-shipment call: nobody is upset, nothing is on fire, and a person in your office still stops what they are doing, finds the booking, finds the document, attaches it and replies. Then the customer replies to say thank you and asks for the one from Thursday too.

Signed proofs of delivery that customers can download themselves end that thread. But the interesting part is not the download button. It is deciding what the document has to contain, because the person who asks for a POD is rarely the person who will finally rely on it.

Three readers, three questions

A proof of delivery is read by different people at different moments, and each asks something different of it.

• The dispatcher asks: did it arrive? A photo and a timestamp are enough.
• The customer’s accounts department asks: can I close this file and pay the invoice? They need the document to match their own order reference.
• A claims handler, an insurer or an auditor asks: what exactly was handed over, to whom, in what condition, and can I trust that this record has not changed since? This reader turns up months later, usually because something went wrong, and they are the one the document has to be built for.

A POD designed only for the first reader fails the third. A squiggle and a “delivered” status settle the dispatcher’s question and open the auditor’s.

What the document has to carry

Think of it as the answers to six questions, all readable in one place.

Which consignment is this? Your booking number, and the reference the customer knows it by. Customers look things up by their own order or purchase number, not yours, so a document you can only find by your identifier is a document you will be emailed about.

What was delivered? The packages, counted, as they appeared on the consignment note. A delivery of twelve pallets where eleven were unloaded needs to say so in the record, not in a phone call.

Where and when? The delivery address and a timestamp, with the time zone stated. Cross-border lanes make this less trivial than it sounds: a time without a zone is an argument waiting to happen.

Who received it? A printed name next to the signature. A signature alone identifies nobody, and “someone at the gate” is a legitimate receiver only if the record says so.

In what condition? This is the field that matters most and gets the least attention. If the receiver noted damage or a shortage, that reservation belongs on the document, in their words. If they did not, the record should say that explicitly rather than leave the field blank, because an empty space can be read either way.

The reason is that reservations are time-sensitive. Under the CMR Convention, for international road carriage, a consignee who takes delivery without noting reservations is treated, as prima facie evidence, as having received the goods in the condition the consignment note describes. Apparent loss or damage has to be noted no later than delivery; loss or damage that is not apparent has to be reported in writing within seven days of delivery, Sundays and public holidays excepted. Domestic carriage is governed by national rules that differ, so treat that as an illustration of why the condition field matters rather than as advice for your lane. But the direction is general: what was noted at the door, or was not, is often the most valuable line on the page, for you as much as for the customer.

Can this record be trusted? Evidence that can be edited after the fact is weak evidence. A POD becomes far more useful once it is fixed at the moment of delivery, so that the copy the customer downloads is the copy that was signed, not a fresh render from data that may have moved since. Ask any system you evaluate whether a delivered POD can be quietly altered, and by whom.

Failed deliveries belong in the same record. A refusal, a closed depot, an absent receiver: each needs a reason, a time and, ideally, a photo. The proof that you tried is worth as much to you as the proof that you delivered.

Self-service is a scoping problem first

Handing customers a login is the easy part. What you are actually promising is that each customer can see their own documents and nobody else’s, resolved on the server, with no way for a caller to ask for somebody else’s shipment by changing a number in a link. An emailed PDF is, in its way, safer than a badly scoped portal, because you chose the recipient. So ask exactly how access is limited, and treat a vague answer as a no. The customer portal article covers this side in more detail.

Three practical points make the difference between a portal customers use and one they ignore:

• Search by the customer’s reference, not only yours. Otherwise the first thing they do is email you the number.
• Availability at the moment of delivery. A POD that appears when the driver finally hands in the paperwork on Friday is the paper problem in a new coat. The document should exist when the receiver signs.
• One file per delivery, downloadable as a PDF. Something they can attach to their own claim or ledger without reformatting.

What it will not fix

A portal exposes the quality of the underlying record. If drivers collect signatures as an illegible scrawl, or skip the printed name, or never record a damage remark, then customers can now see that too, and a self-service copy of a poor POD generates a sharper call than an emailed one did. The habit that matters is at the ramp, in the driver’s hands, and no portal repairs it downstream. Equally, some customers will keep emailing. That is fine; measure the change against a tally, not an adoption figure.

The tally is simple. For two weeks, count every inbound request for a delivery document and note how long it took to answer. After a month of self-service, count again. Whatever is left is either a customer to onboard or a gap in what the document carries, and both are worth knowing.

Where navichain stands

In navichain the delivery is captured in the driver app, and deliveries are sealed with a digital eCMR. The customer portal is included on every plan: customers get their documents, proof of delivery and invoices themselves, scoped to their own organisation. Nothing is retyped between the driver’s phone, your office and the customer’s screen; one record serves all three readers. The platform page shows what is included, and it is worth checking any tool against the six questions above before you decide.