{"id":145,"date":"2026-10-24T09:00:00","date_gmt":"2026-10-24T07:00:00","guid":{"rendered":"https:\/\/yindle.com\/?p=145"},"modified":"2026-10-24T09:00:00","modified_gmt":"2026-10-24T07:00:00","slug":"bezorguitkomst-en-bezorgbewijs-verschil","status":"publish","type":"post","link":"https:\/\/yindle.com\/en\/delivered-is-not-the-same-as-proof-of-delivery-available\/","title":{"rendered":"Delivered is not the same as proof of delivery available"},"content":{"rendered":"

The delivery outcome and digital proof of delivery are two different statuses. \u201cDelivered\u201d describes what the delivery workflow reports; \u201cproof available\u201d means a signature, photo or other ePOD object can actually be retrieved. Do not complete an order or promise proof based on a single general provider message.<\/p>\n

Why the two moments differ<\/h2>\n

A driver can mark a stop as delivered while proof is still being processed. A provider may send a status webhook first and make a document or image available later. Conversely, a file may exist for a failed attempt, such as a photo when nobody was home. Treating every file as a successful delivery may give the customer the wrong account of events.<\/p>\n

At a minimum, model the outcome, event time, proof status and source identity separately. Only use explicit delivery outcomes to complete a WooCommerce order, and make proof availability a separate update. This allows Connect<\/a> to process both events without their order changing the business facts.<\/p>\n

A status model for delivery and proof<\/h2>\n
\n\n\n\n\n\n\n\n\n\n
Outcome<\/th>\nEvidence<\/th>\nOperational meaning<\/th>\n<\/tr>\n<\/thead>\n
On the way<\/td>\nNot available<\/td>\nDo not complete<\/td>\n<\/tr>\n
Delivered<\/td>\nProcessing<\/td>\nDelivery may be complete; proof will follow<\/td>\n<\/tr>\n
Delivered<\/td>\nAvailable<\/td>\nDelivery with retrievable proof<\/td>\n<\/tr>\n
Failed attempt<\/td>\nPhoto\/note available<\/td>\nDo not complete as delivered<\/td>\n<\/tr>\n
Unknown<\/td>\nUnknown<\/td>\nInvestigate; make no promise to the customer<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

Record which exact provider values map to these internal statuses. Depending on the API, words such as \u201ccompleted\u201d may refer to a route, stop or technical task. Test against actual documentation and controlled payloads, rather than a translated dashboard label.<\/p>\n

Fictional example: proof follows seven minutes later<\/h2>\n

Fictional example: order 771 from DIY shop Rivier & Rand is reported as delivered at 13:22. The exact delivery outcome meets the internal delivery criterion, so the webshop order can move to completed under the approved process. The proof URL is not yet available and receives the status \u201cprocessing\u201d.<\/p>\n

At 13:29, a second event arrives with the confirmed proof identity. The order timeline adds \u201cproof of delivery available\u201d without changing the delivery status again or sending another completion email. Order 772 receives a photo, but its outcome is \u201caddress not found\u201d, so it still requires attention. This fictional example shows why a file and an outcome provide separate evidence.<\/p>\n

Customer communication and support checklist<\/h2>\n