Standing Orders is a feature request that has been hanging around for a long time, it has very wide appeal, but the full build is also likely to be reasonably complex. We are trying to get some momentum and a consensus on a first cut to finally implement something.
I’ve tried to describe a full set of user stories that have been discussed so far, so feel free to add any you can think of. More on the specifics of the data model and logic to come…
Full List Of User Stories (add more if you have more)
As an Enterprise User
I can create a representation of the way my order cycles repeat, by organising them into a set
I can see a list of my OC sets
I can see the list of OCs in a given set
I can add/remove OCs from a set
For a given set of OCs
I can create a standing order for a given customer
Contains all relevant information, products, quantities, addresses, shipping and payment methods
I can cancel individual future orders for a customer
I can alter the standing order (ie. all future orders)
I can cancel the standing order (ie. all future orders)
I can restrict which products are available to place in a standing order
I can alter an individual future order
Add/remove products
Change payment/shipping methods
Add payments
I can alter future orders in bulk (without necessarily altering the standing order itself)
Add/Remove products
Change Shipping/Payment Methods
Add payments
I can visualise past and future orders for all customers in a single interface
I’m envisioning a table with customers on one axis, OrderCycles on the other, and the order total at the intersection, which can be clicked on to reveal a modal with more detailed information about the order
Including a “Product View” where orders are represented by in the interface depending on which of a defined set of products they contain (Baw Baw Food Hub use case - Small, Medium, Large Veggie Boxes)
As a Customer
I can set up a standing order from scratch (without necessarily needing to place an order first)
can set products, quantities, addresses, shipping and payment methods
I can select an existing order to use as a ‘template’ for a standing order
Both from my account page, and in the order confirmation page
I can cancel my standing order
I can alter my standing order: ie. the products, quantities, shipping and payment methods
I can cancel an individual future order
I can optionally alter an instance of my standing order (ie. for a given order cycle), by visiting the shopfront
ie. it will automatically be loaded for alteration when I hit the shopfront
I can do nothing while an OC is open, and my order will be processed automatically when each OC closes
I can receive standard order confrimation notifications for my standing orders via email
I can understand when products in my standing order become unavailable
When I visit the site to alter my standing order
Information is displayed to me in the shopfront
When I don’t visit the site during an order cycle
The confirmation email I receive will inform me of the unavailability of certain products
Proposed Model
Create the ShopConfiguration model (as mentioned in Order Cycles 2.0), for grouping OCs together
Has many StandingOrders
Create a new model called StandingOrder
Belongs to an OrderCycleSet and a Customer
Holds a list of StandingLineItems, as well as informatino like preferred payment method, shipping method and address
Create a new model called StandingLineItems
Belongs to StandingOrder and Variant
Basically just holds a quantitity for the specified variant
Associate Orders to the Standing Order from which they originated, allows them to be identified as a standing order, and for the StandingOrder to determine whether an order has been initialised for a given OC
Notes on Logic
Using the hybrid of StandingOrder and Spree::Order, we get the best of both worlds
When no future changes are required - StandingOrders can take care of themselves
When future changes are required - we can instantiate an actual Spree::Order and alter it as we like
no need to choose between the two
Will need to use events around OC Opening and Closing - I think Delayed::Job can handle this?
On open, instantiate all relevant standing orders as actual Spree::Order instances
On close, if the customer has not processed their order via the shopfront, it is processed as it stands
The fact that an order belongs to a StandingOrder indicates that it should be processed on OC close if not processed manually by the user first
It does sound complex but I do get asked about repeat / standing orders frequently and people would no doubt appreciate it and use it. I wonder how it will work with limited stock. I guess I have the option of going to the shop front as soon as a new OC is open in order to submit my standing order, rather than wait until it’s automatically submitted. But either way I may not get a certain item because others got their first and that may affect whether I want the remaining items. I may decide in that case to leave it entirely for this time round.
Can people receive an automated reminder each OC that they have a repeat order active?
Yes - I have been thinking about the situation of limited stock as well. I think the scenario you have is a good solution when limited stock is involved. I think ultimately we should design for allowing hubs the flexibility to make these kinds of decisions themselves. For example: if stock for a given product is likely to be limited on an ongoing basis, I personally would tend to want to disallow customers from adding such products to their standing orders in the first instance. If however, stock is rarely likely to run out, but will on occasion, I would like to see comprehensive messaging to the customer, explaining the situation.
Sending notifications to customers with standing orders when each order cycle opens is certainly possible. I suppose ideally this would be configurable by both hubs (who can set the default) and by customers (who can turn them on/off as they wish)
This looks really good, thinking about the way I shop personally my repeating items would be quite limited. Having said that this could be a very useful feature for wholesale customers as well, I can see it being used in that way a lot.
Although an additional complexity, what if products in standing orders were deducted from the qty available as soon as the order cycle opened?
I assume this is what happens when a basket is created waiting for a customer to confirm their details and pay. So essentially standing orders act as baskets until order cycle closes?
In my mind it makes sense to reward (with higher product availability), rather than punish (with lower availability), people that have standing orders.
Lynne, the members that would have standing orders our end aren’t necessarily big spenders. They may well be people we could do without, buying only one particular (cheap) item and nothing else. So I’m not fussed about rewarding them.
Allocating stock should surely happen at the stage that the customer commits? Otherwise some stock may go unsold when there may have been people that wanted it.
@Oliver Does the customer not commit upon creating the standing order? Customer def don’t have to log in to get their standing order, although this might be a configurable feature.
Given that Stroudco has not had much opportunity to test a fully functioning standing order I’m interested why you are so confident that in general standing orders would be small? My feeling from DFFH is that those with standing orders would tend to order more and be more committed customers.
I can’t be sure, I’m only going by who is ordering the same thing every week and who’s asked for the repeat order function and that leads me to say the above. But it probably doesn’t matter, as I’m keen on having the functionality in any case.
“Does the customer not commit upon creating the standing order?”
Not necessarily. I can create the standing order and then, while the OC is open, delete or amend an instance of my standing order. If I do this late in the OC, others may have missed out because I had the items in my order but then I cancel it and put it back in stock but too late for anyone to buy.
@Oliver
I understand your point. Both will cause problems, either some stock that could have sold out but didn’t or some customers committing to repeating orders missing out on their order.
The solution would be to have this configurable such that the shop can choose which functionality they desire, and mitigate their complaints this way. Even more clever would be tagging customers one way or the other depending on their ordering/complaining behaviour. That sounds nuts, but that’s customers for you
I’m afraid that my understanding is that inventory is not currently allocated until the order is actually placed, so there is not existing logic we can piggy-back on for this functionality. How high priority is this for you relative to everything mentioned in the spec? I feel we are rapidly getting down into the nitty gritty of detail that can be thrashed out later after a few rounds of initial development and testing. Either way, I can’t see that the basic model I’m working on will be affected by the inclusion or otherwise of this functionality.
From my perspective, I am not that fussed about the timing of inventory allocation, as I’ll only be offering standing orders for products that are available on demand.
@oeoeaio
OK Rob, it does make sense to restrict it to “on demand” items. It’s just that from our experience it’s limited stock items that people would want to re-order on a weekly basis, so not sure many of our members would then use the functionality.
Hi all. Apologies, I just wanted to clarify that I am not suggesting that products for standing orders should be restricted to on-demand products only. I was merely trying to indicate the way in which the Baw Baw Food Hub would be likely to use restriction functionality to avoid the problem of limited inventory products for standing orders. Sorry for the confusion.
Restriction functionality for standing orders could be based on explicitly specifying allowable variants, or by using the on-demand flag, or by using tagging or a combination of all three. I suppose the more complexity we add the longer it will thake build…
I’ve recently had feedback that suggests repeat orders would be a great asset in trying to keep the order level up if it means orders will be placed unless people take action to the contrary. I already remind people by email and text and yet there is still a demand for this feature.
Hi @Oliver
Just to let you know, Standing orders is making its way through the dev pipeline. It’s desired by every OFN user and the UK are contributing toward the development. Thanks for your comments.
Closing this exploration / discovery / inception post now the the feature is in delivery and almost complete. This post is referred in the feature topic so can be found again if needs be. If something important is not fully covered in the feature a new wishlist item will be open and prioritized.
