Rescheduling Tasks After "Failure"

[Paul-Eraman-CoopCycle]

The Need

To integrate with last mile providers, and really to give good last mile service to clients in general, we need to have the ability to do multiple delivery attempts and have this reality be seen and traceable in our platform.

--

Pour nous intégrer aux fournisseurs du dernier kilomètre et vraiment offrir un bon service du dernier kilomètre aux clients en général, nous devons avoir la capacité d'effectuer plusieurs tentatives de livraison et que cette réalité soit visible et traçable dans notre plateforme.

--

Para integrarnos con los proveedores de última milla y realmente brindar un buen servicio de última milla a los clientes en general, debemos tener la capacidad de realizar múltiples intentos de entrega y que esta realidad sea vista y rastreable en nuestra plataforma.

---

The Context

Right now a task can be marked as "completed" or "failed" and comments can be added. This leads to the situation where tasks are either completed, then recreated, or they are failed, and then recreated. Manually, this works mostly. But long term, if we want real visibility in the platform for what has happened, we want all the actions taken on a package to happen to one specific task, with the actions registered and visible in one place later.

--

À l'heure actuelle, une tâche peut être marquée comme « terminée » ou « échouée » et des commentaires peuvent être ajoutés. Cela conduit à une situation dans laquelle les tâches sont soit terminées, puis recréées, soit échouées, puis recréées. Manuellement, cela fonctionne principalement. Mais à long terme, si nous voulons une réelle visibilité sur la plateforme sur ce qui s'est passé, nous voulons que toutes les actions entreprises sur un package soient affectées à une tâche spécifique, les actions étant enregistrées et visibles à un endroit plus tard.

--

Ahora una tarea se puede marcar como "completada" o "fallida" y se pueden agregar comentarios. Esto lleva a la situación en la que las tareas se completan y luego se recrean, o fallan y luego se recrean. Manualmente, esto funciona principalmente. Pero a largo plazo, si queremos una visibilidad real en la plataforma de lo que sucedió, queremos que todas las acciones tomadas en un paquete sucedan en una tarea específica, con las acciones registradas y visibles en un lugar más adelante.

---

Potential Solution

We have made the ability for a Dispatcher or Administrator working from the web-based Admin Panel to open a failed task and reschedule it for later. This function ONLY takes the failed task and puts in back into a "to be delivered" state, and moves it to a future time that the dispatcher must chose.

--

Nous avons donné la possibilité à un répartiteur ou à un administrateur travaillant à partir du panneau d'administration Web d'ouvrir une tâche ayant échoué et de la reprogrammer pour plus tard. Cette fonction prend UNIQUEMENT la tâche ayant échoué et la remet dans un état « à livrer », et la déplace vers une heure future que le répartiteur doit choisir.

--

Hemos creado la posibilidad de que un despachador o administrador que trabaje desde el panel de administración basado en la web abra una tarea fallida y la reprograme para más adelante. Esta función SÓLO toma la tarea fallida y la devuelve al estado "para ser entregada", y la mueve a un momento futuro que el despachador debe elegir.

---

What To Think About

• How is the experience for a dispatcher? Is it clear? Could it be better?
• Should a messenger be able to reschedule a task? Or only dispatchers and administrators?
• What else could we want to change in this moment? The price associated with the order? The weight? Contact info?
• Should the rescheduled task automatically be assigned to the same messenger or be unassigend? Or should ask to assign the task to?

--

• Comment se passe l'expérience pour un répartiteur ? Est-ce clair? Est-ce que ça pourrait être mieux ?
• Un messager doit-il pouvoir reprogrammer une tâche ? Ou uniquement les répartiteurs et les administrateurs ?
• Que pourrions-nous vouloir changer d'autre en ce moment ? Le prix associé à la commande ? Le poids? Informations de contact?
• La tâche replanifiée doit-elle être automatiquement attribuée au même messager ou ne plus être attribuée ? Ou faut-il demander à qui confier la tâche ?

--

• ¿Cómo es la experiencia para un despachador? ¿Está limpio? ¿Podría ser mejor?
• ¿Debería un mensajero poder reprogramar una tarea? ¿O sólo despachadores y administradores?
• ¿Qué más podríamos querer cambiar en este momento? ¿El precio asociado al pedido? ¿El peso? ¿Datos de contacto?
• ¿La tarea reprogramada debería asignarse automáticamente al mismo mensajero o cancelarse? ¿O debería pedir que se le asigne la tarea?

[Atala]

Slightly related : Serge told me that when a delivery is failed we may need to create a new task that goes from the customer to the warehouse (somehting like "return this package task") - is it something you may need and could be related?

[Paul-Eraman-CoopCycle]

I don´t think that this type of action should be automatically created, but rather when the task is failed it should be "given back" to the dispatcher to see what to do with it. maybe it needs to be reassigned, rescheduled for the same day, or returned to the office, but we don´t want to assume one specific course of action right?

[0bi0ne1312]

The rescheduling is really a good feature, so the dispatcher don't have to recreate everything again and just have to rescedule it with a new time and date. Directly put a new assignment can be a good feature to add (unnassigned could be one of the proposed assignment then), with also an added price if it is necessary (this is a feature we need on our side, even for failed tasks or delayed tasks).

It should be only possible to the dispatch as the courier is "just" here to deliver and get the right info to the dispatch to take the right decision (because he is the only one with a good overview of quite everything at one given time)

[rayon9coop]

Français (english deepled below)

L’outil de replanification est facile à utiliser cependant :
A. Nous avons remarqué que lorsqu’une livraison échouée est replannifiée, elle est désassignée et déplacée au jour où elle doit être relivrée. Cette manière de faire fait perdre la lisibilité de l’historique de la tâche.
Use case: JOUR J: un coursier effectue un pickup à l’adresse A et ne peut livrer à l’adresse B. Il signale la tâche de dropoff comme échoué. Le dispatch clique sur “relivrer” et la déplace au JOUR J+1.
Dans ce cas, la plateforme: génère une série d’incohérences (qu’un refresh suffit à éliminer) mais la tâche de replanification déplacée jour J+1 n’est plus visible le jour J.

B. Lorsqu’une tâche est replanifiée, elle se place dans un groupe pouvant porter n’importe quel nom. Pour les coopératives qui utilisent des groupes pour organiser les tâches non assignées, les tâches à relivrer se perdent rapidement dans l’ensemble des groupes . Afin de faciliter la lecture du dashboard, il faudrait que le groupe contenant les tâches à relivrer soit nommé “à relivrer”

C. Nous pensons également qu’il serait intéressant de laisser le choix à l’administrateur de :

1. replanifier et laisser l’assignation au coursier actuel,
2. replanifier et assigner la livraison à un autre jour et à un autre coursier,
3. replanifier et assigner la livraison au même coursier et au même jour mais à une adresse différentes (ex. le client appelle pour dire qu’il n’est pas chez lui et qu’il souhaite finalement être livré sur son lieu de travail),
4. replanifier et assigner la livraison à un autre jour, à un autre coursier et à une adresse différente (ex. le client appelle pour dire qu’il n’est pas chez lui aujourd’hui et qu’il souhaite finalement être livré sur son lieu de travail le lendemain)
   => Cela pourrait être facilité par la possibilité d'ouvrir un popup-question fermée du type “Souhaitez-vous replanifier la tâche à la même heure demain ?” Oui-Non
   Si la réponse est oui toutes les informations sont les mêmes, mais à livrer le jour ouvrable suivant.
   Si la réponse est non alors possibilité de choisir l’adresse, le jour, l’heure et le coursier.

D. Les coursiers devraient pouvoir replanifier seuls une tâche échouée.
Use case: Un coursier va à l’adresse à livrer, mais le client est absent. En continuant sa tournée, il a la possibilité de repasser devant l’adresse 1 heure plus tard et de refaire une tentative de livraison.
Si l’incident est “Client absent” (on profite de l’occasion pour signaler que cet item d'incident pourtant courant n’existe pas dans la liste des incidents), le coursier devrait pouvoir replanifier sa livraison sans intervention d’un dispatch.
Si l'opération de replanification est effectuée par le coursier (via l’appli), il faudrait que la tâche se duplique et se place d’elle même juste en dessous de la tâche échouée.

English

The rescheduling tool is easy to use, however:
A. We've noticed that when a failed delivery is replanned, it's de-assigned and moved to the day it's due to be re-delivered. In this way, the history of the job is no longer legible.
Use case: DAY D: a courier pickup at address A and is unable to deliver to address B. He reports the dropoff as failed. The dispatcher clicks on "reschedule" and moves it to DAY D+1.
In this case, the platform generates a series of inconsistencies (which a refresh is sufficient to eliminate) but the rescheduled task moved to DAY D+1 is no longer visible on DAY D.

B. When a task is rescheduled, to make the dashboard easier to read, the group containing the tasks to be redelivered should be named "to be redelivered".

C. We also think it would be interesting to give the administrator the choice of :

1. reschedule and leave the assignment with the current courier,
2. reschedule and assign the delivery to another day and another courier,
3. reschedule and assign the delivery to the same courier on the same day, but to a different address (e.g. the customer calls to say he's not at home and would like to be delivered to his place of work after all),
4. reschedule and assign the delivery to another day, another courier and a different address (e.g. the customer calls to say he's not at home today, but would like to be delivered to his place of work the next day).
   => Have a closed question like "Would you like to reschedule the job for the same time tomorrow?" Yes-No
   If the answer is yes, all the information is the same, but to be delivered the next working day.
   If the answer is no, then you can choose the address, day, time and courier.

D. Couriers should be able to reschedule a failed job.
Use case: A courier goes to the address to deliver, but the customer is absent. Continuing his round, he has the opportunity to pass the address again 1 hour later and attempt delivery again.
If the incident is "Customer absent" (we take this opportunity to point out that this common incident does not exist in the incident list), the courier should be able to reschedule his delivery without the intervention of a dispatcher.
If the rescheduling operation is carried out by the courier (via the app), the task should duplicate itself and place itself just below the failed task.