Subscriptions: Next steps for the beta

Continuing the discussion from Subscriptions improvements:

Hi all, I’m starting a new thread for this topic so that we can keep the good information we have gathered but also refocus the conversation on next steps with the beta version. This comes off the back of a couple of sessions @sstead and I have had in mapping the current functionality and then listing out the pain points with that were identified on the previous thread.

Firstly, here are the raw whiteboard notes that show you what Sally and I covered off.

You can see that these images outline the tasks in setting up and managing subscriptions, and the pain points / gaps that exist in the current version.

And this was the initial view we had of the tasks at a high level, and also who can do what (enterprise vs shopper). Listed beside / around the tasks are the pain points / gaps again, some of which are reflected above and some additional. And side meanderings about naming and questions to be answered about the beta.

I’m going to make these more digitised and beautiful, but in the meantime I wanted to lay out some things for discussion.

1 - DO WE BELIEVE THAT THE CURRENT VERSION IS GOOD ENOUGH TO BE LAUNCHED?

I think we can all agree that the current version does not come close to meeting our needs. However, the bigger question is are we all happy to consider this “done” for now?

What “done” could look like in terms of implementation:

  1. Leave it as it is, only accessible via a super admin OR make the feature visible so that enterprises can see that it’s there and use it if they want to.

  2. Leave it as a beta version (regardless of decision above) so that it’s obvious it isn’t finished yet OR make it version 1.0.

  3. Leave this as a soft launch, where we don’t communicate / promote the feature to OFN users and instead let them serendipitously find it in their settings OR we can go with a hard launch, where we communicate out to the world about this version being live and accessible.

2 - WHAT SHOULD THE CURRENT BETA FEATURE BE CALLED?

There has been some talk of this feature in its implementation not being so much a subscription model as a standing order model.

I assume this is related to the enterprise model and how they do subscriptions (e.g. CSAs or subscribing to a weekly box of veg for a season) vs allowing customers to have a standing order at a nominated frequency that they can control as part of their shopping process.

It seems there was/is a gap in having these different models defined/written about somewhere. Sally and I took a generic view of the feature, but it would probably be valuable to understand it in the context of these different models. Would it be possible for those of you in the know to add them to this post, so we can map them to what exists in the beta version? @tschumilas and @MyriamBoure perhaps this is something that you could contribute? Or anyone else, all input welcomed!

Click here to go to the next topic, which is Subscriptions: What do we improve next.

My vote is that this is not a v1, but there are use cases it satisfies. I think the in the UK we are treating as a soft launch beta, communicating to some users that have been asking for SO for a long time. We are laying out the limitations of the current feature and offering to help them set it up. We’re still waiting to hear if people want this feature as is. There is always an issue when people discover things for themselves, as it amplifies the ‘OFN is hard to use’ rhetoric. However I would still vote Visible but not a hard launch.

1 Like

My votes :

  1. Make the feature visible so that enterprises can see that it’s there and use it if they want to.
  2. Leave it as a beta version (regardless of decision above) so that it’s obvious it isn’t finished
  3. We can go with a hard launch, where we communicate out to the world about this version being live and accessible.

I would communicate about it, but as a beta version, so tell “we have something you can use, not yet perfect, but can help you what you need this for”.

I will explain in a separate post our findings from discussion about CSA and difference between subscription vs standing orders after discussing with Kirsten, Theresa, Rachel and Luis. I insist in calling that “standing orders” for now, for clarity, because we don’t “sell” any subscription today, selling a subscription means making a subscription a product someone can buy and be invoiced for. Standing orders mean you don’t commit to anything, you buy a new basket by default each week, but you don’t buy from the begining a subscription all invoiced from the start, you are invoiced at each basket. I will clarify, but it is important to understand the transaction model behind standing orders vs subscription, for hubs it’s two different management logic for their offers.

1 Like

I think @myriam’s post describes the distinction between 3 models well here, under item B.

I think what we have is a beta version of ‘standing orders’ - not ‘subscriptions’. @MyriamBoure has clarified one key difference: discrete purchases in an OC (standing order) vs purchasing a promise of future products/deliveries/boxes (subscription). Our confusion, in part, is that enterprises that call themselves “CSAs” might do either. Some CSAs are really ‘box programs’ or ‘box schemes’ where the buyer selects their order weekly. Other CSAs are ‘true’ subscription models, where the buyer (we call them a member) buys in advance and receives their share over the course of a series of weeks. (further confusing because the actualy payment might happen in multiple weeks.) So a standing order might or might not have a composite ‘food box’ in it. So - I might do a standing order of discrete items that I usually use, adn then edit it and pay every week. Some of those ‘items’ might include a pre-made box or bag of goods.

1 Like

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