The delivery outcome and digital proof of delivery are two different statuses. “Delivered” describes what the delivery workflow reports; “proof available” 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.
Why the two moments differ
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.
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 to process both events without their order changing the business facts.
A status model for delivery and proof
| Outcome | Evidence | Operational meaning |
|---|---|---|
| On the way | Not available | Do not complete |
| Delivered | Processing | Delivery may be complete; proof will follow |
| Delivered | Available | Delivery with retrievable proof |
| Failed attempt | Photo/note available | Do not complete as delivered |
| Unknown | Unknown | Investigate; make no promise to the customer |
Record which exact provider values map to these internal statuses. Depending on the API, words such as “completed” may refer to a route, stop or technical task. Test against actual documentation and controlled payloads, rather than a translated dashboard label.
Fictional example: proof follows seven minutes later
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 “processing”.
At 13:29, a second event arrives with the confirmed proof identity. The order timeline adds “proof of delivery available” without changing the delivery status again or sending another completion email. Order 772 receives a photo, but its outcome is “address not found”, so it still requires attention. This fictional example shows why a file and an outcome provide separate evidence.
Customer communication and support checklist
- Only use “delivered” after an explicitly permitted provider outcome.
- Only say “proof available” when the object can actually be retrieved.
- Keep the stop, order and proof identities together within the correct workspace.
- Prevent duplicate notifications when events are repeated or arrive out of order.
- Give proof links appropriate authorisation and a managed retention period.
- Present a failed attempt as a next action, rather than a completed delivery.
In Desk employees need one timeline showing both moments and the exact outcome. For more context on the difference between a label and an actual delivery, see customer service with order context. Assess privacy and retention periods for your own situation; this article only describes the process model.
Also design a waiting route for proof that takes too long to arrive. Missing proof does not necessarily require the delivery status to be reversed, but may warrant a warning when proof is mandatory for your process. Assign an owner to that warning and show the stop identity, delivery time and last successful provider check. A retry should only retrieve the proof; it should not change the WooCommerce status again. If proof remains unavailable, an employee should be able to record that the provider was consulted or alternative proof was accepted under internal policy.
Test the integration with four separate events: delivered without proof, delayed proof, a failed attempt with a photo, and two identical proof events. Check the customer email, order status, timeline and access rights in each case. Also open the proof link as a user without the correct role and after the retention period has expired. The process is only complete when the status mapping is correct and proof can both be found securely and become unavailable in a controlled way.
Agree on a glossary with the carrier and customer service team. “Delivered”, “completed” and “proof ready” must not be used interchangeably on screens. Put the exact source value in a detail view, while giving employees one consistent Dutch meaning. This prevents two teams from explaining the same event differently to a customer.
Want to separate delivery status and ePOD in your order flow? Discuss the status model with Yindle.