Articles on: Sales

Return requests

This feature makes managing returns easier, helps you control balances more effectively, and improves clarity and efficiency in presale processes for your delivery staff.

With this feature, mobile users will be able to make a return request without having an assigned load, since the delivery will not be completed immediately, but at a later time.

📦 **What does this mean? **This allows delivery staff to complete these return requests later, when they receive an open route. The total amount will be seen as a positive balance for the client.

This balance can be applied to the client's next delivery or even used in the same visit in which the return took place.

For this feature to work, make sure to enable it in Return Settings in the web portal.

It will only work if the user DOESN'T have an open route:

In the mobile app, go to the client's details, click on Return:

Then, you'll need to select the products that are being returned, and, if you've enabled that setting, specify the reason why they're being returned. Learn more about this setting here: Reasons for return

It's important to know that return requests can't be printed; they can only be edited or deleted. This is because they're not considered a complete process yet. Until delivery is completed, they can be printed as Returns.

View returns 💻

After completing the request, it will be sent to the web portal, where the administrator can view it. It can be found in several places:

You can find return requests in "User Activity", where you can see requests individually alongside the user's orders, visits, forms, etc.

You can also see a full list of return requests by clicking Main menu > Reports and goals > Returns > Return requests.

Here, you can filter requests by client, user, zone, state, and others, as well as delete requests.

Request status 🔵 🟡 🔴 🟢

A return request may be in one of four statuses, which will update as the return process advances.

A single client can have more than one return request, which can be edited or deleted as many times as the pre-sale user considers appropriate.

🔵 All new requests start in the PENDING status. Once the request is edited, it won't go back to pending.

🟡 During the route creation process, requests will show as ASSIGNED, and they will be assigned according to the deliveries included in the route. All pending return requests are taken into account, from all customers to whom those deliveries belong.

During this process, the route can be cancelled, or the delivery crew can deny the load, which is why requests marked will only be marked as ASSIGNED when the load has been accepted by the delivery crew.

🔴 While requests are in the PENDING status, they can enter the **DISCARDED **status, meaning the return won't take place, and the request won't be assigned to any delivery user.

A request can be considered as DISCARDED if the delivery person decides not to carry out a straight return. Before closing the process in the app, a confirmation window will be displayed, warning the user that the requests will be canceled.

If a route is closed and all requests are still in the ASSIGNED status, if they're not completed, they will be marked as DISCARDED.

🟢 When a return is completed from all of the client's return requests, Handy will add all total amounts marked as the same reason for return and mark it as COLLECTED.

It will also show you which user collected the return:

🔐 Validations

If a client has ASSIGNED return requests, all operations will be blocked to ensure the delivery person collects the returned products. This also applies when they try to end the route while having pending deliveries. The app will check if any of those deliveries have ASSIGNED requests, and it will display the client’s detail screen instead of the delivery confirmation. This ensures that the client’s returned products are always collected.

Send us a message in the chat if you have any questions! 😎

Updated on: 11/10/2025

Was this article helpful?

Thank you!