Subscriptions: What do we improve next

Continuing the discussion from Subscriptions: Next steps for the beta:

And now, we talk about where to next. There are SO MANY problem areas we can focus on, so this is my attempt to put them into some kind of grouping and resulting list.

So to continue the count from the previous post…

3 - WHAT WOULD WE PUT FORWARD TO BE PRIORITISED NEXT?

I believe we could have the following icebox items that focus on the biggest problems with the current version (in no particular order):

  1. Shoppers can’t set up and manage their own subscription. This causes way more overhead for the shop to set up and manage them. This would include the ability to manage the overarching standing order (create, cancel, pause, change)

  2. Shoppers can’t effectively edit their scheduled order, they have to contact the shop to do it for them. This means more work for the enterprise, plus also a lost opportunity for added sales. This would include the ability to edit each order (remove/add items, change quantities).

  3. Enterprises can’t manage both public and private order cycles on the same shop. This means that if they want a members only subscription they have to create another shop that is only for those subscribed customers. Or they have to have all their order cycles open and try to communicate/steer shoppers to the correct one.

  4. If there are no future order cycles in a schedule the enterprise can’t edit subscriptions due to a product unavailable error (existing GH issue).

  5. Where subscriptions are contractual agreements between the enterprise and the shopper (France only I think?), there is no means of managing this agreement via the feature. This creates more work for the enterprise to manage the contracts outside of the system.

  6. Failed Stripe payments for subscriptions are not proactively managed by the system, therefore the enterprise needs to spend time identifying when a payment has failed and contacting the shopper to remedy this.

  7. Something about how crappy the experience of setting up a schedule and the order cycles within it is for enterprises, the logic is unclear, and cloning order cycles within a schedule is a nightmare.

  8. Something about product variants are really painful to manage and cause much pain for enterprises fulfilling scheduled orders.

If you can think of any additional problem areas please add to the list. And please comment below on which you believe are the biggest priority, and which aren’t, and if I haven’t captured the first 8 well.

@danielle I took the time to document the legal investigation about subscription management (linked to CSA, but not only actually…) CSA features : undersanding how CSA work and the gap with current standing orders feature
I think there are two ways to see that:

  • Either we keep on improving the “recurring orders” feature, but let’s be clear with our users: subscriptions are not supported by the OFN today. Which is case 1 in my post: " 1- A hub wants to enable customers to automate orders."
  • Either the cases we want to enable are 2 or 3 and I think we need to brainstorm solutions with product and dev people to see if that is the same path / feature than current recurring orders that we can iterate from and how to do it in a way that can support evolution of recurring order to make them more usable and also draw a path toward a real subscription feature.

I don’t think we should move forward on recurring orders before asking ourselves those questions and building a strategy… that we can then implement step by step and iterate then on the way. Happy to discuss with you @danielle about how to move forward on this BIG chunk…

Yes, Myriam. The list we curated above is improvements to the current ‘recurring order’ functionality. Seems like a pathway to attaining true subscriptions as you refer to them is a whole other matter… BIG chunk indeed.

This is now covered in our Wishlist repo Subscription improvements · Issue #137 · openfoodfoundation/wishlist · GitHub
Added a reference to this topic there