We know you want it . . . lots of Producers and Hubs have a core set of Customers that have the same order every week / month, and it would be much better for them if those orders could be automatically generated each Order Cycle.
We hear that this is a high priority. It is a complex feature, and building it in a way that gives you all the flexibility you will need requires careful design.
Ultimate feature set looks something like:
My Customers can set-up and maintain standing order / s with my Shop / Hub
They can edit those orders - pause for a week or two, amend the order, have their changes apply from a certain date etc
I can set up a season / series and have my Order Cycles automatically recur, with the appropriate standing orders in them
Step 1: Enterprise can set up a series of Order Cycles
The first step is to enable the Enterprise to set up a Series of Order Cycles for the Customer Orders to be attached to
Then we need to be able to create the orders
Step 2: As Enterprise (Hub / Shop), I use Create Order to make a new order
can save this order as a ‘standing’ order
can apply to a whole series, or specific scheduled order cycles
[need a check control on products / variants - not all available to standing order. Perhaps set with a tag?]
I set shipping and payment method etc
[NB: to do this, we first need to fix up the Order edit / create so that it works properly with our significant changes from Spree basic. Can possibly do in one big chunk]
Step 3: Future orders created
When Order Cycle opens, the orders are created
? send order confirmation email to Customer letting them know it’s done
? Customer can click link in email to edit the order?
? payment - depends on payment method . .
Step 4: Enterprise management of standing orders
As Enterprise, I need to be able to see and edit Customer’s standing orders and order cycles in bulk somehow
As Enterprise, I want to be able to create a bunch of future orders in one go
Step 5: Customer can create and manage their own ‘standing’ order
enable in checkout
for this series, until date, or pick future dates
Customer needs to be able to edit future order . . individual orders? just the template one?
I wonder if this is combining too much? Would automatically repeating order cycles be a somewhat separate feature that could come first, then standing orders are built on top of that?
About standing orders, Able and Cole here in the UK have a nice implementation of this, where they send a reminder email each week to check your repeating order. Each item has a “skip” button that just says skip 1 week (or whatever repeat frequency is). So maybe if I still have eggs from last week, I can skip just my eggs for this week but still get everything else.
the Stroudco repeat order facility allowed a shopper to select certain products that would appear in their basket automatically each order cycle. they were then sent an email each order cycle that told them what had been put in their basket (noting any items that were not available for the current order cycle) and asking them to take out any items that they did NOT want before the end of the order cycle.
would it be helpful to have access to the php code that we wrote to make this happen?
see changes above . . I’ve made it a wiki page so fine to adapt it a bit with possible ideas. We’ll keep working here until we’re clear what it is we want to do, then split it off into chunks and move into Backlog when we have dev capacity to do it
I am starting to think about this with a view to building something in my “spare” time over the next few weeks. Just trying to map out the model that I think would support the full feature set that we are after, what actually gets done will depend on how much time I get to put it together.
Part 1: Enterprise can set up a series of Order Cycles
User can create an OC Group (or Series), which is pretty much an empty shell that groups a bunch of OCs.
We need an interface for OC Groups/Series that allows the user to generate OCs with properties defined according to a set of rules around opening/closing times, frequency, naming, etc.
Would be good to enable selection of an existing OC as a ‘starter’ or ‘template’ from which to create exchanges for new OCs
The interface obviously needs to allow the user to list/add/delete OCs for a specific Group/Series.
This setup allow us to support for both finite and indefinite OC group/series models, where indefinite users can just continue generating more OCs for a particular group whenever they begin to approach the end of the group/series.
Part 2: User can apply changes to the set of exchanges that occur for a particular order cycle to ‘all future’ OCs in that series
This is similar to the way repeating events in Google Calendar work. You create a repeating event, and then you go in and edit the information, choosing whether to apply your changes to just the specific event that you are dealing with, or all future instances of the event.
The basic idea would be to provide a ‘apply to all in this group/series’ button on the OC edit page which appears when the user is editing an OC that is in an exchange, and that copies the set of changes across all future OCs in the series.
I suspect we may need to alter the OC controller routing and therefore flow of the order cycle edit page for this to work. If we are going to try and copy a set of exchanges across several order cycles it would be good to have dedicated update_outgoing_exchanges and update_incoming_exchanges actions, which could be set up to handle errors around removing variants from future orders cycles for which standing orders already exist, etc.
Another concern: If we want to keep the “collection time” field for each outgoing exchange as a free text field, how are we going to generate that text in an appropriate way when automatically generating exchanges or future OCs? I suspect we may need to start using rules for defining the collection times relative to the closing date/time of the OC in question. Basic implementation would be something like:
Have a collect from and until date, where the date is specified as “First Wednesday After Order Cycle Closes”. Can be two different days
Then just specify opening and closing times for collection
This has the added benefit of allowing us to change collection times for this exchange in all future OCs
Part 3: As Enterprise (Hub / Shop), I can create a new Standing Order
I am going on this basic list of features so if there is anything else we need to do, let me know:
User (front or back) can create a standing order, that applies to a series of OCs
User (front or back) can alter a specific future order, whether it be line_item quantities, shipping address, payments, payment method, shipping method.
User (front or back) can alter the ‘standing order’ itself, ie, have changes reflected in all future orders
This is the tricky part: somehow expose or intuitively document the interaction of changes to specific orders and the standing order itself. For example, if I alter a specific order in one way, and then I apply a conflicting change to the standing order, which change takes precedence?
Proposal
My proposed model for standing orders looks a lot like the one for OC Groups/Series: the StandingOrder object is very basic and pretty much just holds a collection of orders. I think it should probably also have a start date and and end date, a flag for allowing the user to amend or cancel each order (by sending them an email with a link when the OC opens), a default order and an ‘auto-generate’ field (see next).
The StandingOrder instance would have a reference to a “default” order, and an option to ‘auto-generate’ from the default order each time an OC in the relevant OC Group/Series opens. This will happen every OC from ‘start_date’ until ‘end_date’. In this way, we can minimise the amount of effort required to maintain standing orders that don’t change week to week, while still providing flexibility to change future orders to those who need it (see next point). When generated in this way, the orders are flagged (maybe a status of ‘pending’ or a completely new flag which identifies them as a standingorder order). This flag allows messaging to users when the OC opens, and allows them to open it up and edit it before it is placed.
For advanced users, we provide an interface for the bulk creation of orders, either constructing one from scratch or selecting an existing or from the standing order series to duplicate. These orders are also flagged as ‘pending’ or whatever.
The advanced interface also allows for listing/adding/removing orders from a group of standing orders
In terms of editing an individual order, that should be as simple as creating it (if it doesn’t already exist) opening it up and altering it.
Changing multiple orders is as easy as changing the default order for auto-generation. Eg. If a customer decides that from now on, they would like to order an extra loaf of bread with their order, the enterprise user can simply amend the order for the current OC and set this and the default order for the StandingOrder.
When auto-generation is being used, a new order will not be created when an order for the same standing order already exists. This means that any orders generated through the standing order interface, either in bulk or individually, will override the auto-generate functionality.
When auto-generation is not being used (ie. orders are all created individually or using the bulk-generation tool), I think we may have to come up with a way to intelligently apply any changes made to an order that we want to be reflected across future orders. This may involve exposing any conflicts to the user and allowing them to amend each conflicting order individually. Hopefully this will not happen very often, and we probably don’t need to build this functionality any time soon.
Part 4: When an OC opens or closes
We need to implement some sort of event system that allows us to fire background jobs whenever an OC opens or closes
When an OC opens
If it is part of a series, all of the orders for that series and OC are either collected (if the already exist) or are auto-generated from the specified defaults
If a standing order is flagged as allowing the user the edit it, an email with a link to loading it up for alteration is sent to the user, lets them know how long they have to edit it. When they alter and place the order the ‘pending’ flag is removed
When an OC closes
Any orders still flagged as ‘pending’ are placed as they stand, with the normal confirmation email being send to the user
Part 5: Customer interface for creating/editing standing orders
User should obviously be allowed to see any existing future orders, and edit them.
With regard to the creation of standing orders, I think that selection of an existing order for a given OC series as the default (where auto-generation is being used) should be sufficient. Not sure what to do if auto-generation is not being used - I guess they will just have to edit their future orders manually…
Let me know if you would like to see the Stroudco repeat order system which was working fine for us but then developed a bug that we couldn’t solve so we have disabled the feature. But I can put you in touch with the php developer who wrote it for us if that would help.
Thanks again for working on this - we would be very happy to see it included
looks good to me @oeoeaio . . but I still find myself searching for a first small and simple iteration. Don’t know if I’m searching in vain and it just needs to be the full investment to get the architecture we need?
Ok, well let’s call that the full spec of what I think we eventually want. For a first iteration I am thinking:
Enterprise User can create OC Series, and populate them by bulk creating OCs based on a template.
I think we need rules for automatic setting of open/close dates, and the name of the OCs
Probably also really need to do the work of making the collection times more machine readable/alterable/format-able
Probably don’t really need the ability to replicate changes to exchanges across other OCs in the series at this stage
Just having some different thoughts about standing orders: perhaps the best way to allow alteration/skipping of future orders is not to create them all in advance and then only delete/alter the ones you want, but rather to just have a simple standing order created by a reference to an existing one that cycles every week, and then a list of OCs stored on the standing order for which an order should not be created.
Standing orders point to an existing order, which is replicated when each order cycle opens
Interface for standing orders could be an list of past and future order cycles, where past OCs are represented by the actual orders placed, and future ones are represented by what will theoretically be auto-generated
Using this interface, we can switch particular OCs on and off, to prevent an order from being created
Just thinking about the BBFH situation and payments. It would be good if this interface allowed an enterprise user to store a payment against each future order, which would then be applied when the order was actually initialised.
I think this lets us get away with not building a complex multi-standing-order edit interface because:
In the event that a future standing order needs to be adjusted we can just turn the standing order off and manually create a normal order
We send an email to each customer with a standing order when an OC opens, which allows them to alter the contents of their order before it is placed - so this should catch any last minute changes they want to make.
Email confirming an unaltered standing order should be sent on OC close
Maybe we don’t worry about allowing customers to alter their standing orders directly for now?
@oeoeaio - is this thread where you are going to post updated plan for implementation? or more likely to do a linked post and start again? have made sure that the top one is a wiki anyway so you can easily change, but just not sure if you want to keep this detail around.
Just reviewing this page in light of current discussions around moving forward with some work on standing order functionality. I think my ideas generally hold, with the exception that the trajectory of our work on inventories could mean that any need to update future instances of order cycles becomes greatly simplified (due to removing the need to update product selections within OCs).
That said, I’m still struggling to find a set of features that would give us a good first step, but would be relatively simple to implement. Does anyone have any suggestions for such first steps?
I keep coming back to the need for more structure around order cycles if we are to set them up as repeating instances where each is self aware of their position in a larger group. However, this is perhaps not the highest priority, and is more an ideal scenario.
For the purpose of standing orders, we could get away with manually creating a group of order cycles and then getting Enterprise Users to link per customer standing orders to it that can be turned off for a given cycle if desired. It should be fairly simple to also allow alteration of an order on a one off basis by the customer once the order cycle has opened. Is this a good basic set of features?
For Baw Baw I would be wanting to move quickly from that starting point onto allowing more fine grained control of future instances of standing orders such as applying payments to them and tweaking the items included in each order individually.
I know that others are more interested in allowing the front end customer to set up and manage/alter their own standing orders but this is not really a priority for us at present.
Interested in hearing other people’s ideas about feature priority…
@NickWeir@lin_d_hop@Sara@MyriamBoure@serenity any thoughts on what Rob has written here. He’s super keen to kick off this work, so any input you have on his thinking would be really helpful
Thanks Rob - it is great that you are moving on with this. I think it will make a big improvement to the turnover of enterprises. When we had to stop using the Stroudco repeat order functionality (because we couldn’t find the bug in it) we lost a lot of shoppers. It would be great to win them back!
Maybe it is worth me summarising what the Stroudco system did when it worked:
When a shopper was reviewing their basket they had an option to add any of the items in the basket to their repeating order. Once they had set up a repeating order they could add or remove items from that repeating order and change the quantities of items (eg 3 loaves every week instead of 2)
The shopper could click one button to turn off their the whole of their repeating order (if they were going on holiday) without having to remove all items from the repeating order individually.
Every Sunday the system sent the shopper an email telling them what had been put in their basket and reminding them to change it before Wednesday evening if they didn’t want it that week. If the shopper edited the order they had an option to add any new items to their repeating order.
I think you have covered all this. My only concern is that i think it would be a lot of work for the hub administrator to have to make changes to repeating orders on behalf of the shoppers. It would be great if the shopper could set up the repeating order and make any changes themselves.
I will check with @Oliver and see if he would like to add anything to this
How about starting with allowing shoppers to add items to a memorised list to which they can go back next time they shop and easily re-order them? Just to keep it simply for a start?
Makes sense to start with adding the functionality for OCs to be set to automatically reopen in a series, with a set of rules for dates, naming etc.
Backend management of block repeating orders will be useful for enterprises in the UK but not specifically requested at the moment. The use case that you are working to @oeoeaio is, I think, a nice case and I think it makes sense for you to prioritise for Baw Baw.
Perhaps once the interface for adding repeat orders has been developed in the above we can look at extending…
UK would definitely like the user to be able to control repeat order functionality. It seems logical to me to include in the Account section and I’d be interested in spending some time scoping this functionality out and drawing it up with/for others’ inputs.
GoCardless seems like a good payment method for this functionality. Would it make sense that repeat orders have a specific set of payment methods available as configured by the enterprise?.
I wonder if this might be something for @stveep to look at next? Would be a nice feature and a solid first piece of paid work in the UK dev team. Perhaps looking at GoCardless while @oeoeaio develops the initial infrastructure. Maybe we could have another session in the Esmee offices drawing some nice pictures again @stveep… you made them perfectly last time
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.
