A failed delivery is rarely a single driver problem. It is usually the final symptom of weak address data, an unrealistic promise, poor handover or unclear authority. This guide sets out a practical response system for UK takeaways.
Define a failed delivery before measuring it
Use a small set of outcome codes that staff can apply consistently. A delivery can fail because the address cannot be found, nobody answers, access is blocked, the customer disputes the location, the order is damaged, the driver cannot complete the journey safely, or the business misses the promised window so badly that the customer no longer wants the order. Do not hide these outcomes inside a general “cancelled” status.
- Record the order, channel, zone, promised time and actual dispatch time.
- Record the first confirmed cause, not a guess made after the shift.
- Keep food-quality, address, payment and driver-safety failures separate.
- Allow the cause to be corrected later, but preserve the audit trail.
Use one live escalation path
The driver should not negotiate complex remedies while riding or driving. Give the shift lead one contact route and a clear authority matrix. The driver reports the situation; the restaurant verifies the order and customer contact; the authorised person decides whether to wait, return, redeliver, partially refund or fully refund.
| Situation | Immediate action | Decision owner |
|---|---|---|
| No answer | Use the approved contact sequence and safe waiting rule | Shift lead |
| Address cannot be found | Confirm postcode, building and access notes; do not encourage unsafe searching | Dispatcher or shift lead |
| Food damaged | Photograph only when appropriate, protect personal data and return or dispose under the agreed process | Shift lead |
| Severe delay | Give a revised promise and realistic remedy options | Customer-service lead |
| Unsafe weather or route | Stop or reroute the journey; safety overrides speed targets | Driver and duty manager |
Choose the remedy from the facts
Redelivery is useful when the customer still wants the meal, the kitchen can produce it safely and the revised time is credible. A refund may be more appropriate when the customer no longer wants the order, the business cannot recover within a reasonable period or a serious quality issue has occurred. A partial remedy can fit a missing item, but it should not be used to minimise a wider failure.
Do not publish a blanket “no refunds” rule. Prepared food is not treated like a durable product returned because a customer changed their mind, but customers still have rights when what was supplied is faulty, not as described or not provided as agreed. Marketplace orders may also require the platform’s case process.
Protect the evidence without creating surveillance
- Keep order events, contact attempts, dispatch and delivery timestamps.
- Retain only relevant tracking data and limit access by role.
- Use photos only when they genuinely help resolve the issue; avoid capturing unrelated people or private interiors.
- Record refunds, credits and redeliveries against the same incident.
Review causes weekly
A high number of no-answer cases may actually be poor ETA communication. Wrong-address cases may come from a weak checkout form. Cold-food complaints may be caused by kitchen waiting before dispatch rather than the road journey. Review the complete order path and fix the earliest controllable cause.
Implementation checklist
- Create no more than ten failure codes.
- Write the driver contact and safe-wait procedure.
- Set refund and redelivery authority by role.
- Test direct and marketplace escalation routes.
- Review outcomes by zone, time and channel every week.
Build a standard incident record
A useful record should allow another manager to reconstruct the event without calling every person involved. Keep the original customer address and notes, the validated destination, order acceptance and dispatch events, driver assignment, contact attempts, outcome, remedy, cost and final owner. For marketplace orders, add the platform case reference and distinguish what the restaurant decided from what the platform processed.
Do not ask staff to write long narratives during a busy shift. Use structured fields for common facts and a short free-text note for anything unusual. Restrict access to people who need it and apply the business retention schedule rather than keeping tracking screenshots indefinitely.
Separate recovery from prevention
Resolving the customer’s order is the first task; correcting the system is a separate task. A refund may close the complaint but does not fix a postcode-validation problem. A redelivery may save the meal but does not correct poor bag loading. Assign every repeated cause to an operational owner, a due date and a test that will show whether the change worked.
| Failure pattern | Likely control point | Useful verification |
|---|---|---|
| Address not found | Checkout fields and address review | Test flats, new developments and boundary postcodes |
| Customer unavailable | ETA communication and contact sequence | Measure contact attempts and safe waiting time |
| Cold or damaged food | Kitchen-to-dispatch wait, packaging and route grouping | Run representative journey tests |
| Unsafe journey | Promise, weather control and route decision | Review whether staff felt pressure to continue |
Related guides
- Delivery Management — the main guide for the wider topic.
- Complaint Handling for Delivery Issues — a detailed next step for putting this guidance into practice.
- How to Reduce Failed Deliveries — a detailed next step for putting this guidance into practice.
- Driver Tracking and Communication — a closely related operational control to review alongside this page.
- Peak Period Delivery Management — a closely related operational control to review alongside this page.
- Refunds and Chargebacks — a connected decision that can change the recommended approach.
Sources and recheck points
Guidance checked: 24 July 2026. Recheck official guidance and supplier documentation before changing a live process.
