[This is a reverse engineering work to clarify the scope of the current feature being delivered so that we can move it till done and close the first chapter of it]
What is the need / problem
In 2 words: A hub manager can setup an automatic “standing” order for a registered customer
Some hubs sell products on a recurring base, like subscription models. A customer will buy a basket of vegetable per week for 2 months for instance. Or customers will ask a hub if they can setup some “automatic order” because they order bread and potatoes every week and don’t want to make the same order every week. In order to be able to organize the operation of such offers, hubs need to be able to automate the ordering of the concerned product for a given customer. But also manage “events” like a customer goes on holidays and want to not receive the expected product some weeks, etc. So the hub manager needs to be able to create, pause and cancel a recurring order to be able to propose such offers to their customers.
NOTE: the need to be able to sell and buy a subscription is not concerned by this icebox. Also, the need for a customer to create an automated order herself is not covered in the scope of this icebox.
The scoped unmet need that we propose to prioritize:
- A customer can ask (not using OFN) the hub manager to automatically order a certain set of products for her on a certain pace/schedule for a given period of time, using a given payment method and a given shipping method.
- She can ask (not using OFN) the hub manager to pause, modify or cancel this automatic ordering process.
- If she wants to cancel or modify an automatic order, she can ask (not using OFN) the hub manager to do so.
- In order to meet answer those requests, the hub manager needs to be able in OFN to set up a recurring/standing order for a given customer for a certain set of products on a given schedule/pace, for a given period of time, with a given payment and delivery method.
- She needs to be able to pause, modify or cancel this recurring order.
So for the feature to work here are the prerequisites:
- the customer is in the customer list of the hub and has a validated account
- if hub wants to attach a credit card payment via Stripe to a recurring order, the customer needs to have a saved credit card on the platform
All what concerns “modifying an order until the OC is closed”, whether it be an automatic standing order, or a single order, is out of scope as not specific to this feature. Today if the hub manager allow it, the customer can cancel or change quantity of products within an existing order until the OC closes. No improvement of this feature is included in scope, it remains as such.
ANYTHING BEYOND THAT IS OUT OF SCOPE and to cover it another icebox will need to be described and prioritized by the community.
Who does it impact?
Hub managers: today they have no possibility to propose “recurring based offers” to their customer as they can’t operate them on OFN. Or they have to manage them outside of OFN.
Customers: today if they do make the same base order every week, they can’t save or automate it in any way, they have to remake manually the order at every order cycle
What is the current impact of this problem
Hub managers are limited in the treatment of offers they want to make to customers, so it results in high time management if they do it anyway outside OFN with spreadsheets or other things, or profit loss because they decide to not propose such offer, so they loose customers who want those kind of offers.
Customers are annoyed to make again the same order all the time, and if the customers are not happy, hub managers aren’t either.
What is the benefit in focusing on this
Make food enterprises (= hub managers) happier because they can be more efficient in their hub management and propose richer offer to their customer that answer the needs of those customers.
Potential solutions that will solve this problem
There might have been different solutions, but here is the one we have chosen and that has been implemented (this is a reverse engineering exercise)
The solution has been designed mainly by Rob and include the ability for the hub manager to create “schedules” associated to order cycles, and then setup a recurring order that specify a list of products that will be automatically ordered on the order cycles associated to the given schedule chosen in the subscription setup. It is mainly described here: Standing Orders - version 1.
Big overview of how it works:
- hub manager can set up the recurring order, pause or cancel. If start date is before OC end date, order is made for the OC. If end date is before OC end date, no order is made for the OC.
- when OC starts, customer receives an email saying an order has been made on her behalf (can amend, if hub authorize it)
- when OC closes, customer receives an email saying the order has been confirmed and can’t be modified anymore
T-shirt size of the selected feature candidate
XL
Metrics to measure if need is well satisfied after feature has been implemented
100% of shops that want to propose such “recurring ordering” offer are able to do it using OFN so no more hubs are preventing themselves to propose such offer or manage it outside OFN like in excels.
Epic and/or project board where you can follow implementation
Project board is here: https://github.com/openfoodfoundation/openfoodnetwork/projects/15
What will happen next
When this feature is released, we will let users use it and see what are the new need that emerged. We have listed some needs that we perceive to improve the current feature, to add things that we imagine are needed beyond that, and also to develop real subscription products that can be sold. We propose to try to prioritize small needs that will emerge one by one and treat them one by one. For instance: “a customer can automate herself a regular order she wants to make”. We don’t know yet what is the next step of needs that will emerge, so let’s leave it open for feedback for now before proposing straight away the new level of development towards an extended subscription feature.
Connected wishlist and discovery discussions:
Lots of discussions has happened about recurring orders / subscriptions, etc. With lots of confusion also about the difference between a recurring order, a pre-sale and a subscription.
- Synthetic view of feature project: [FEAT] Subscriptions (standing orders)
- Description of implementation model: Standing Orders - version 1
- Some thoughts about next step after this first scoped feature is released: Subscriptions: Next steps for the beta and Subscriptions: What do we improve next
- Wishlist for later needs around recurring orders and subscription: Subscriptions improvements
- Original discovery/inception work on listing user stories: Standing / Repeating Orders
- Inception topic on exploring the workflow: Customer can have a Standing / Repeating order