> For the complete documentation index, see [llms.txt](https://help.supplyd.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.supplyd.co/supplyd-erp/deliveries/managing-deliveries/managing-failed-deliveries.md).
# Managing Failed Deliveries
Managing failed deliveries helps ensure they are quickly identified and resolved, reducing delays and making it easier to successfully deliver orders to customers.
Managing failed deliveries correctly and efficiently helps ensure orders are promptly identified, retried, or reassigned for delivery. Supply’d provides flexible options for handling failed deliveries, allowing drivers and operational teams to take the appropriate action and minimise delays in getting orders to customers.
* [#managing-failed-deliveries](#managing-failed-deliveries "mention")
* [#id-1.-retry-the-order-during-the-current-delivery-run](#id-1.-retry-the-order-during-the-current-delivery-run "mention")
* [#id-2.-reassign-the-order-to-a-new-delivery](#id-2.-reassign-the-order-to-a-new-delivery "mention")
***
## Managing Failed Deliveries
When a driver marks a sales order delivery as , there are two ways the order can be handled, depending on whether the order should be attempted again during the current delivery run or reassigned to another delivery.
### 1. Retry the Order During the Current Delivery Run
If the driver is still completing the delivery run and has not yet finalised it, they can attempt to deliver the failed order again. This allows the driver to retry the delivery as part of the current delivery run without creating a new one.
{% stepper %}
{% step %}
Close the sales order screen.
{% endstep %}
{% step %}
Return to the main **Delivery Run** screen.
{% endstep %}
{% step %}
Scroll to the list of orders included in the delivery.
{% endstep %}
{% step %}
Find and open the order marked as .
{% endstep %}
{% step %}
Attempt the delivery again.
{% endstep %}
{% step %}
If the delivery is successful, click on the 3 dots in the top right and select **Delivered** to mark the order as .
{% endstep %}
{% endstepper %}
***
### 2. Reassign the Order to a New Delivery
Once an order has been marked as , it can be manually added to a new delivery, such as the next day's delivery.
* **You do not need to wait for the driver to finalise the current delivery run.** As soon as the order is marked as , it can be added to another delivery.
* Failed orders must be added manually because **Auto-Assign** only selects orders with a **Picked** or **Unfulfilled** status. An order with a failed delivery does not meet these criteria.
{% hint style="warning" %}
Confirm whether the driver intends to retry the delivery before reassigning the order. Your business should have a clear process for communicating and managing delivery retries to prevent an order from being retried after it has already been assigned to another delivery.
{% endhint %}
After adding the order to the new delivery, continue with the usual delivery process, including optimising the delivery. The order will return to status and will appear on the driver's scanner for the new delivery.
{% hint style="success" %}
You can use the **Delivery Failed** filter on the **Sales Orders** screen to quickly identify orders with failed deliveries that may need to be reassigned.\
{% endhint %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://help.supplyd.co/supplyd-erp/deliveries/managing-deliveries/managing-failed-deliveries.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
, there are two ways the order can be handled, depending on whether the order should be attempted again during the current delivery run or reassigned to another delivery.
### 1. Retry the Order During the Current Delivery Run
If the driver is still completing the delivery run and has not yet finalised it, they can attempt to deliver the failed order again. This allows the driver to retry the delivery as part of the current delivery run without creating a new one.
{% stepper %}
{% step %}
Close the sales order screen.
{% endstep %}
{% step %}
Return to the main **Delivery Run** screen.
.
status and will appear on the driver's scanner for the new delivery.
{% hint style="success" %}
You can use the **Delivery Failed** filter on the **Sales Orders** screen to quickly identify orders with failed deliveries that may need to be reassigned.\ 