Statuses
In this section, we will present the delivery states in Shippify and help you link them with those of your platform.
Última actualización
In this section, we will present the delivery states in Shippify and help you link them with those of your platform.
Última actualización
To complete a delivery, it must go through a series of state changes, which we detail in the following image.
When a delivery is created in the system, it can be created with a 'Processing' status, which means the task was created successfully and is ready to be assigned. When created as 'Pending Review,' it's because there was an error in geolocation, either in the pickup or delivery address, and it's necessary for an operator to correct the address so it can move to 'Processing' and continue the flow.
To link a delivery with a driver, there are two options: either put it in 'broadcasting' status (the delivery is published in the network of drivers for one of them to take it in the mobile application) or assign it directly to a driver (this process is carried out by an operator in the dashboard; when assigned, it doesn't mean the driver has accepted the task).
When a driver takes the delivery from the mobile app or an operator assigns it from the dashboard, and the driver accepts the delivery in the app, it moves to 'confirmed for collection'. After confirming the collection, the driver indicates from the app when they are on their way for the collection. Finally, upon arriving at the warehouse, the driver marks in the app that they are at the collection point. Throughout this process, the driver can reject the delivery, changing its status to 'not collected'.
Throughout this collection process, the driver can reject the delivery, changing its status to 'not collected', thus leaving the delivery without an assigned driver. Under this state, reasons can be configured to describe the reason for the change or rejection, such as vehicle issues
When the driver is at the warehouse, they proceed to scan and verify the packages for delivery. If the delivery belongs to a route, the same process must be carried out for each one. During this process, the task is in the 'in delivery' status. After completing the verification, it moves to 'on the way to delivery', and subsequently to 'at delivery point' when it arrives at the agreed-upon address.
Throughout this delivery process, the driver may abstain from completing the delivery by changing it to the status 'hold by courier'. Under this status, reasons can be configured to describe the reason for the change, for example, the customer was not at the address. The driver can attempt delivery up to a maximum of 3 times, in case the delivery is successful, the task continues in the green flow, otherwise, it follows the red flow that returns the package to the warehouse, leaving the delivery as 'returned'.
After delivering the packages to the recipient, proof of delivery is requested in the app, such as photos or a signature from the person receiving the package. Once the proof is provided, the task changes to the completed state, thus ending the task lifecycle.
At any step of the flow, the delivery can be canceled, either through the external API integration or from the dashboard. When canceled, the delivery is left without a driver. Under this state, reasons can be configured to describe the reason for the change, for example, customer canceled the order.
Pending to review
pending_to_review
A delivery is created with missing pickup or delivery information (contact, location) and needs review
Processing
processing
A delivery is successfully created on the platform
Broadcasting
broadcasting
A delivery has been broadcasted to a network of drivers
Assigned
assigned
A delivery has been assigned to a driver
Confirmed to pickup
confirmed_to_pickup
A delivery has been confirmed for a driver to carry out
Going to pickup
going_to_pickup
A driver is heading to the pickup location
At pickup
at_pickup
A driver is at the pickup location
On delivery
on_delivery
Driver en route to delivery
Going to dropoff
going_to_dropoff
A driver is heading to the delivery address
At dropoff
at_dropoff
A driver is at the delivery address
Dropped off
dropped_off
A driver is awaiting the delivery receipt (photo, signature, recipient's information)
Completed
completed
A driver has successfully completed a delivery
Canceled
canceled
A delivery was canceled
Going to return
going_to_return
A driver is heading to the pickup address to return a delivery
At return point
at_return_point
A driver is at the pickup address to return a delivery
Returned
returned
A driver has successfully returned a delivery
Not picked up
not_picked_up
A driver has reported that a delivery was not picked up
Not picked up payable
not_picked_up_payable
A driver has reported that a delivery was not picked up, but they will still be paid
Hold by courier
hold_by_courier
The delivery is held by the assigned driver until a new attempt is made or it is returned to the pickup address
If you need to specify the reason why a task changed to a certain state, you can configure the reasons you want for the state of your preference. These reasons will explain or provide more detail about the change. If in your external system you have a state that does not exist in our list, you can link it to the one that most closely resembles it and create a reason under it that identifies it better. Generally, these reasons are added to the 'hold_by_courier' and 'canceled' states.
hold_by_courier
Recipient rejected the package
Recipient rejected the package
hold_by_courier
Recipient can't be reached
Recipient can't be reached
canceled
Lost package
Lost package
canceled
Canceled by client
Canceled by client
You can create these reasons within the dash by accessing the state and reason configuration through this link. Here you will find system reasons that you can reuse, and if you don't find the one you need, you can create it.
Click on this link.
Select a state.
Check if there is no similar reason in the system to yours. If it exists, add it to your company; otherwise, create one.
Since you know the states and reasons within our system, you can proceed to link them with your system. For a better understanding of this, you can fill out this spreadsheet.
Here's a table where you can fill in the information about the states in your system and their equivalent in Shippify.
List the states of your platform in the blue column
Find the equivalent state in Shippify. You can help yourself by asking the following questions:
Is it a state that occurs before the collection of packages in the warehouse?
Is it a state that indicates there was an issue?
If you need more details for a state or if you got the same state in Shippify for 2 or more states from your platform, then you can add them to a specific state.
Once you have your table filled out, you can proceed to configure the state synchronisation in your system.
