Incidents V.2

[Paul-Eraman-CoopCycle]

The Context

We have recently introduced the ability to create incidents in CoopCycle as a courier, which allows for the courier to pick from a set of pre-determined failure reasons (broken on delivery, client not home, etc). However, we have not made this feature useable for dispatch or administration in any way and now need to make that next step.

This proposal has a series of assumptions:

1. Couriers can create incidents that would modify the price of a task (not 1 box, but 2 boxes on pick-up) but couriers are not responsible for incident management or commercial activities. Therefore, incidents must be reviewed by a dispatcher and approved, rejected, or otherwise managed.
2. We want to manage food delivery and non-food delivery incidents in the same portal/space
3. Incident management and customer support should be done internally to CoopCycle as much as possible so that economic impacts of these decisions can be reflected in the database of tasks and their prices, facilitating correct accounting and invoice creation through the CoopCycle platform
4. The orders page will include ALL orders and deliveries that happen on the platform due to correct use of the platform based on new developments, and therefore a menu of "today / upcoming / past" will be added, as exists in the deliveries panel
5. We have the following workflow for tasks

Key

Flow

Goals

1. Clearly show to a dispatcher the incidents that have occurred and must be managed somehow
2. Allow couriers to communicate issues to responsible members of the cooperative
3. Have correct pricing information for invoicing that includes incidents, facilitating that a cooperative charges for wasted time and other such problems

The Proposal

In the orders page, an "Incidents" tab will be added with a submenu of "Needs Review" and "Managed Incidents". In this tab you will be able to see incidents that still reviewing by a dispatcher, and you can also review past incidents that have already been managed. The search bar and so on remain functional. This page is separated into 4 parts:

1. Mark as reviewed
2. Basic details about the order: Order Code / When Delivered / Client (business) / POD / status (can be incident with no delivery (client wasn't at home), or an incident where it was still delivered (made me wait, but i delivered))
3. Incident details: Final client info or name / type of incident / courier
4. Resolution details: button to manage the incident / Who is responsible / Description of resolution / financial impact (+ if coop makes more money, - if coop looses money)

As seen here, in the page with Managed Incidents, the resolutions would be shown, using codes that will need to be determined

However, if you click on the gear icon to manage the incident, a modal pops up that allows you to do 3 things:

1. Manage the incident
2. See the tasks relevant information
3. Modify the task (WILL MODIFY THE PRICE OF THE DELIVERY)

FoodTech Example

Non-FoodTech Example

Important: for foodtech, the possible "issues" are limited and don't suggest what to do since it is a B2C customer service issue. For local commerce, the incidents create sort of "suggestions" for price modification.

For foodtech:

1. Client not home or made me wait (incident can be created by the courier or dispatch depending on coop norms)
2. Arrived bad or cold (will be told to dispatch by the client)
3. Something missing in the delivery (will be told to dispatch by the client)
4. Late delivery (can be "automated")

But in all situations, the way to deal with the situation is very subjective and depends on the way the cooperatives work

For Last Mile / Local Commerce for pickup or dropoff tasks:

1. Wrong package type (rider can indicate which is the correct package type)
2. same but weight
3. same but volume
4. made me wait
5. change in delivery window
   and so on, all of which are things that, if the client profile is appropriately set up, a "suggestion" by the courier (it was 2 boxes not 1) can automatically suggest a new price based on the changed characteristics. The management of this would look like this:

[tcmjlnt]

Looks pretty complete to me, thanks for the proposal.
I don’t know what else I could be adding.
I have a few questions :

1. Clearly show to a dispatcher the incidents that have occurred : does it mean there should be a specific notification for the dispatcher?
2. How would the whole thing be configured for the coop ? i’m especially thinking of pricing rules (that are already quite complex to set up), but also in term of decision workflow, etc?

[0bi0ne1312]

Yeah baby !
This is a really advance way of problems notification I love !
It seems a bit complex but at least it respond to every scenario case I have in mind.

The idea to make the dispatch in charge of confirming a price modification is important. (for me) the courrier is here to inform on specific change (error of parcel loading or infos, waiting time) and the dispatch is here to take actions if needed.

Making the order panel the same way the delivery one is also good because for now, it is like every page as a different behavior and way of working so a bit of UI work for dispatcher is not bad :)

Linking to person in charge is not a bad idea either so we are sure informations are passed to the right person and nothing is forgotten !

Thanks for this job !!!!!

[rayon9coop]

We completely agree with @0bi0ne1312

What's more, this will enable us to manage incidents in a highly structured way (and it's a way of positioning the platform towards greater professionalism).

Questions:

• in local shops, will suggestions be automatic? Will the platform propose a predetermined list or a "smart" list based on the type of incidents?
• Will it be possible to personalize list of incidents? For example, waiting time, how will couriers manage it (waiting 10 minutes is not the same as waiting 30 minutes)?

[Paul-Eraman-CoopCycle]

We are making wait time a separate type of thing (because it requires some interaction, "how much wait time"; " 15 minutes" etc whichw e have to think about a little) but other than that, RIGHT NOW:

1. there is a predetermined list of incidents that is one "by defect". this list needs to be visualized for the admin (in process)
2. you can then create your own lists, and associate them to stores, much like packages. If you only want a few waiting time options, this could be a good way to do that until what i have mentioned above is ready