Improve management of multiple ordering process in a given open OC

[MyriamBoure]

What is the problem ?

Now that standing order feature is released, there are some pressing flaws to fix on the user flow when multiple orders are made on a given open OC.

1- Customer who has a previous order for a given OC and make a new order can see in cart dropdown AND cart page the “items already ordered for that OC”
BUT the items are not appear below any order reference, and are not aggregated either, so it induces some confusing result when a given product is ordered in multiple previous orders.

2- When customer who has a previous order for an OC makes a new order, at checkout she can view the items previously ordered and can delete them while checkout out for the new order. If she clicks on “modify confirmed items” she is abruptly redirected to “account page” without any instruction on what to do.

3- When she makes a modification, either delete a confirmed product when checking out for the new order, or when modifying an order from “my account” access, she receives no notification.

Solution proposed to fix those problems

It seems technically complicated to aggregate already made orders into a single order for an OC, so my suggestion would be to TAKE IT SIMPLE and do 4 things:
1- Just consider that every order should be displayed separately so that user can reconcile and understand what was ordered where and why he has to go in this order to modify things, etc.

In cart dropdown:

In cart page:

2- I would move in cart page the “modify order” button on each order line and redirect directly to the relevant order so that it can be modified. (see cart page image above)
3- I would remove the possibility to delete items from previous orders, to avoid confusion and have a clear rule: modification is on the order page, that’s all. (see cart page image above)
4- If a modification is done on an existing order, I would trigger an email “Order modification” with content saying: order number #X has been modified, here is the updated content for that order (ideally in the same thread as first confirmation email…)

T-shirt size

M (for the whole feature, the 4 points)

Previous discussions related

GH issue: https://github.com/openfoodfoundation/openfoodnetwork/issues/1166

What do you think about that @sstead @danielle @Rachel @Kirsten @maikel ? If you are happy with it I’m happy to work as a PO, check with a dev that this solution is technically ok and get a quick estimate so that we can decide to prioritize or not. Then we can easily do the story map from there, it would clarify a lot the process.

[maikel]

Sounds good. Instead of trying to make it too simple and condensing items, we are making it more transparent and show what’s actually happening.

[Kirsten]

hmmm. should this be connected to delivery notes at all? as in some kind of coherence about managing changes to an invoice / delivery note / packing sheet / order? Does the Customer here get one or more order confirmation emails? invoices?

[MyriamBoure]

I don’t think it is @Kirsten . One order is one order, then an invoice can be issue for multiple orders, a delivery note can be build for multiple orders, but amend / change / cancel an order is about the order. It can be done until the OC is closed if the hub permits it, I don’t see impact or connection with delivery note or invoicing. Packing sheet will probably be per order as well, but liste by customer so you will see the two orders of the customer and can prepare them “together” somehow if that makes sense, but in some cases it might not (like a customer made 2 orders with different delivery options). So I would really keep that separate and keep a clear logic.

[Kirsten]

I just don’t see this @MyriamBoure - it seems to me to make infinitely more sense that if the OC hasn’t closed and the Hub allows then the Customer is actually amending the same order - not creating a new one. Managing separate / multiple orders for the same customer in the same OC, and therefore making everything else like packing sheets, invoices, delivery notes etc handle multiple orders seems a way way harder way to deal with this?!

[MyriamBoure]

Sure @Kirsten ! I think we misunderstood each other. The case here is about a customer who did make multiple orders for the same OC.
Ex: the customer has a recurring order made automatically, OC opens, the order is complete. He wants to ADD products (this is not possible to do amending an existing order, you have to make a new one). SO he has no choice but making a new invoice…

This is a basic common case now that recurring orders are operational.

Other case: a customer making a first order for him, and a second for a friend (pretty common case) so they want two separate orders.

So the fact is that we do have multiple orders for one OC. If we want to make that impossible we need to rewrite somehow the recurring order feature, which I think you don’t want So from now, the “cleaner” way to handle that is to keep those orders separate. If hub invoice outside of OFN they can make just one invoice for the OC afterward, it doesn’t matter. In OFN it will be one invoice per order as invoice is based on the order. For delivery note as we are thinking it v1 will be one delivery note per order, but later on we will be able to iterate, and what I say is that in the report / packing sheet orders are sorted by customer name so the packer will prepare the two orders for the same customer one right after the other, and can put them together.

[sstead]

I love your suggestions Myriam!
Things will change when we allow true order modification (being able to add to an order), but for now this sounds far cleaner than the current setup.

[MyriamBoure]

@Kirsten do you agree then now on the feature candidate proposed?
Or do you still think we should consider another feature candidate?
It would be great to have some T-shirt sizing of this feature @maikel, would you give XS, S, M, L or XL ?
Would be great to have another dev opinion on that as well.

[maikel]

All the individual tasks are small, S. All four of them together make a medium, I guess.

[Kirsten]

sure. Based on the many issues we’ve had with CERES around things like this, I think it will be far superior and more intuitive to get to the point where the customer can just add items to existing order. Is that actually so difficult? but taking your word/s for it that that is hard, then sure go with this

[MyriamBoure]

I 100% agree with you on the principle, but we need
1- First to implement the thing to trace order modification or it’s gonna be even more messy that it is with invoicing info, etc.
2- Then it implies we need to review some of the logic behind order cycles (and subscription as a consequence). At least the minimum thing would be to prevent a user who already has an order for an OC to make a new order, we should force to modify the existing one…
BUT
a- what do we do with users who make orders for several persons of their family? (we do have some…)
b- what do we do with “hubs without end dates” like hubs who have a permanent OC and treat the orders one by one when they arrive?

I think we will be able to review that when we have moved forward on network feature and review the whole logic of order cycle… but it’s a big investigation.
Did you find a way to go around those issues with CERES? I think their model is simpler, they don’t allow hundreds of hubs with different models to use their platform…

Happy to have other people views on it but I think this proposal is the best feature candidate we have on a short term. We can do some discovery work but it’s a 3 months job as touch to lots of things in the system… in value x ease matrix the solution above add lots of clarity at very cheap cost, then we can improve later.

[Kirsten]

sure. The main tricky thing that CERES encountered that would happen here is when people need to create a new order in same order cycle (as that’s the only way to add items they forgot) but there is a shipping fee / delivery cost per order. Then they end up paying it again even if they’re only trying to add one item to the order, which makes them sad and mad

[luisramos0]

Interesting topic!

Looks good. I agree with the estimate.

We could also explore the “order modification” case. That would be another item.

[MyriamBoure]

Ok, I get the case @Kirsten and I would say as @luisramos0 jut suggested that we need to explore how we could “add products” when we modify an existing order. So for me it would be a second iteration.
First : clean the current mess and clarfy the order UX and separation of orders.
Then iteration 2, or could be parallelize actually, we could already open another wishlist about “Enable to add products when modifying an existing order”
Do you agree ? If yes I leave this one as is and open a second wishlist.