Incident Reporting

[Paul-Eraman-CoopCycle]

In a store settings:

EN

The Need

We need to have the ability to track incidents both for ourselves, and to communicate to our package providers.

The Solution

We can now create a list of incident types with codes (for last mile providers) and associate them to a store. This will then allow the courier to mark a task as failed and add an incident to the failure. This task still will have associated prices for the delivery, which will only not be charged if the task is cancelled by a dispatcher. (no show of a client still means I get paid)

Things to think about

• How this interacts with rescheduling failed tasks feature: https://github.com/orgs/coopcycle/discussions/1
• What happens after this. Are rescheduling failed tasks charged an extra fee?
• We think we would like to make filling out the incident report or saying there are no incidents as mandatory for certain stores/clients
• We think we would like to have the ability to change the characteristics of the task, and thereby change its price. Ex. you arrive and the object is twice as big as they said it would be, you can change the weight and volume, and you charge the appropriate amount

Other things?

FR

Le besoin

Nous devons avoir la capacité de suivre les incidents pour nous-mêmes et de communiquer avec nos fournisseurs de forfaits.

La solution

Nous pouvons désormais créer une liste de types d'incidents avec des codes (pour les prestataires du dernier kilomètre) et les associer à un magasin. Cela permettra ensuite au coursier de marquer une tâche comme ayant échoué et d'ajouter un incident à l'échec. Cette tâche aura toujours des prix associés pour la livraison, qui ne seront pas facturés uniquement si la tâche est annulée par un répartiteur. (la non présentation d'un client signifie toujours que je suis payé)

Choses à prendre en compte

• Comment cela interagit avec la fonctionnalité de replanification des tâches ayant échoué : https://github.com/orgs/coopcycle/discussions/1
• Que se passe-t-il après ça ? La reprogrammation des tâches ayant échoué entraîne-t-elle des frais supplémentaires ?
• Nous pensons que nous aimerions rendre obligatoire le remplissage du rapport d'incident ou l'indication de l'absence d'incident pour certains magasins/clients.
• Nous pensons que nous aimerions avoir la possibilité de modifier les caractéristiques de la tâche, et ainsi de modifier son prix. Ex. vous arrivez et l'objet est deux fois plus gros qu'ils l'avaient annoncé, vous pouvez modifier le poids et le volume, et vous facturez le montant approprié

Autres choses?

ES

La necesidad

Necesitamos tener la capacidad de realizar un seguimiento de los incidentes tanto para nosotros mismos como para comunicarlos a nuestros proveedores de paquetes.

La solución

Ahora podemos crear una lista de tipos de incidencias con códigos (para proveedores de última milla) y asociarlas a una tienda. Esto permitirá al mensajero marcar una tarea como fallida y agregar un incidente al error. Esta tarea aún tendrá precios asociados para la entrega, que solo no se cobrarán si un despachador cancela la tarea. (La ausencia de un cliente significa que me pagan)

Cosas en las que pensar

• Cómo interactúa esto con la función de reprogramación de tareas fallidas: https://github.com/orgs/coopcycle/discussions/1
• ¿Qué pasa después de esto? ¿Se cobra una tarifa adicional por la reprogramación de tareas fallidas?
• Creemos que nos gustaría que rellenar el informe de incidencias o decir que no hay incidencias sea obligatorio para determinadas tiendas/clientes.
• Creemos que nos gustaría tener la posibilidad de cambiar las características de la tarea y, por tanto, cambiar su precio. Ex. llegas y el objeto es el doble de grande de lo que dijeron, puedes cambiar el peso y el volumen, y te cobran la cantidad adecuada

¿Otras cosas?

[Yannick-CoursiersMtp]

For this new feature, I have created three failure reasons, but when attempting to cancel and choose a reason, I find that the dropdown menu is not visible enough on an Android phone.

[0bi0ne1312]

As you said, it a great number of related issue :

For your example of redefining the goods weight/volume to make the pricing accurate, it firstly takes into consideration that we can change the pricing after the order is created. I did not know it was possible ! Also, it is weird to fail the task to say it is not accurate and be able to modify it... then is it done or failed ?

Depending on the client, we have rules for failed task. for example, a charge of 0%, 25% or 50% or 100% of the task is charged even if we can't deliver.

Also, the POD is really important in order for the dispatcher to have as much information as he needs to take the right following action : rescedule / call the client / etc.

Regarding DHL functioning exemption, they also have drilldown menu to have as much info about the failing issue without making the first menu to hard to understand. I have the manual of it if you want to see it ! I will find a way to send it to you @Paul-Eraman-CoopCycle

For debugging, we did not had enough issue to try it out for now... Will come later.

[rayon9coop]

Français

Nous avons pu remarquer en testant la fonctionnalité que les coursiers ne pouvaient pas voir sur quel “incident” ils ont cliqué lorsqu'ils sont sur la page de validation de la tâche.
Cela étant, l’incident choisi par le coursier est bien visible dans l’historique des tâches sur le dashboard des administrateurs.

Il faudrait pouvoir aussi indiquer des motifs pour les livraisons réussies
Exemples :
Colis endommagé mais le client a accepté le colis (dans ce cas, le colis est livré mais il peut -être intéressant de signaler l’incident quand même)
Client absent -> Colis déposé en sécurité chez le voisin, dans le jardin, etc.
Ces particularités pourraient également faire partie d’une liste personnalisable (en fonction des clients, certains acceptent une livraison dans le jardin, mais pour d’autres, il faut absolument une livraison en mains propres)

Rendre obligatoire le remplissage du rapport d’incident ou de l’absence d’incident nous parait une bonne idée. Il est aussi important que tout soit consigné et lié aux tâches afin de faciliter les recherches lorsque nous nous retrouvons face à des clients mécontents ou qui posent des questions. L’obligation du remplissage de ce rapport permet de savoir en 1 seul clic quel coursier a effectué la livraison et la cause de l’incident.

Concernant la modification des caractéristiques de la tâche et donc de son prix:
les coursiers sont en première ligne pour avoir accès à l’information (ils sont en contact avec les colis et ce sont eux qui ont la possibilité de voir les modifications des tailles par rapport à ce qui est noté dans la tâche). Ils sont donc bien placés pour signaler les changements. Par contre, l’acceptation éventuelle du changement de prix doit pouvoir être validée par les administrateurs. L’idée serait donc que quand un coursier signale un changement de caractéristique de la tâche (taille, adresse,...), la plateforme notifie le dispatch qui décide de valider ou non le changement de tarif.

English

While testing the feature, we noticed that couriers could not see which "incident" they had clicked on when they were on the task validation page.
That said, the incident chosen by the courier is clearly visible in the task history on the admin dashboard.

It should also be possible to indicate reasons for successful deliveries
Examples:
Damaged parcel but the customer has accepted it (in this case, the parcel is delivered, but it may be worth reporting the incident anyway).
Customer absent -> parcel left safely with neighbor, in garden, etc.
These features could also form part of a customizable list (depending on the customer, some may accept delivery in the garden, but for others, hand delivery is absolutely essential).

We think it's a good idea to make it obligatory to fill in an incident or non-incident report. It's also important for everything to be logged and linked to tasks, to make it easier to find out when we're faced with unhappy customers or people asking questions. The obligation to fill in this report means that in just 1 click we know which courier made the delivery and the cause of the incident.

When it comes to modifying the task's characteristics and therefore its price:
couriers are in the front line for access to information (they are in contact with the parcels and it is they who have the opportunity to see changes in size compared to what is noted in the task). They are therefore well placed to report changes. On the other hand, the eventual acceptance of the price change must be validated by the administrators. The idea would therefore be that when a courier reports a change in the job's characteristics (size, address, etc.), the platform notifies dispatch, who then decides whether or not to validate the price change.

[Yannick-CoursiersMtp]

https://github.com/orgs/coopcycle/discussions/8

Following our tests on the incident reporting functionality by couriers, we observed that the chosen incident reasons are not visible upon task validation. On the Administrator Dashboard, the incident reported by the courier is not visible. We conducted tests on two phones of different brands, and the observation remains consistent. Either we are not correctly locating where the incident should appear, or the incident reporting button is not functional.

Video of the incident selection by the courier.

video5974438171755156454.mp4