How to handle failed deliveries and reattempts
To handle failed deliveries properly, the failure has to create a record with a reason, not just a parcel coming back. In Jestor, a failed stop raises an exception with its cause, triggers customer contact, and forces an explicit reattempt decision.
Why failed deliveries repeat
A parcel returns to the warehouse and goes back out the next day, to the same address, with the same problem. Nobody contacted the customer, because contacting the customer was not part of anything.
The second failure costs the same as the first and was entirely predictable.
What a structured response prevents:
- Identical reattempts to an address that will fail again
- Parcels sitting in the warehouse with no owner
- Customers unaware their delivery was attempted
- No data on which causes dominate
- Costs absorbed without ever being measured
Failure causes and the right response
| Cause | Correct response | Reattempt |
|---|---|---|
| Nobody present | Agree a new window | After confirmation |
| Address incorrect | Confirm the correct address | Only once corrected |
| Access denied | Get access instructions | With the instructions recorded |
| Customer refused | Start the return process | No |
| Vehicle or route issue | Reschedule internally | Yes, no customer action |
Step by step to structure it
- Require a failure reason from the driver, chosen from a short list.
- Capture evidence where the cause is disputed.
- Trigger customer contact immediately, while the day is still actionable.
- Block automatic reattempt where the cause requires customer input.
- Record what changed before scheduling a second attempt.
- Set a limit on attempts, after which the return process starts.
- Report cost per failure cause, which is what justifies fixing the top one.
Why blocking the automatic reattempt is the key rule
The default behaviour of most operations is to try again. For half of the causes, trying again without a change guarantees another failure. Making the reattempt conditional on something having changed is what breaks the loop.
Why choose Jestor
In Jestor, a failed stop is a record with a required reason category, customer contact can fire automatically through native WhatsApp automations, conditional rules can block the reattempt stage until the blocking field is filled, and reporting by cause is available on the same data the drivers produce.
Frequently Asked Questions
Why do deliveries fail twice at the same address?
Because the reattempt happened without anything changing. See jestor.com.
Should the customer be contacted automatically?
Yes, immediately, while there is still time to arrange a new attempt.
How many attempts should be allowed?
Set an explicit limit, after which the return process starts.
Video Tutorial: Step by Step
With Jestor, you can automate workflows, connect teams, and build internal systems your way, all without code and powered by AI. Discover Jestor at jestor.com and see how to take your company's operations to a new level of efficiency and control.