There are a couple of options to consider, depending on whether you want to apply different fees, products and options to each delivery location/day. The pros and cons of a few configurations are discussed below:
Have 3 separate shipping methods (with different days/locations).
This is ideal when the only different between your customer groups is the time/location that delivery occurs. If you need to also have distinct fees or product availability or prices, this doesn’t work as well.
This relies on people selecting the correct shipping location at checkout.
You can attach a different shipping fee to the different audiences (this can be instead of a markup). But people might not like this way of applying fees, as they prefer such fees to be incorproated.
This means that there will be one ‘order cycle close date’ for all of them. This might not be what you want.
It keeps the reporting simple, because all are within one order cycle.
You can’t have different products available to different audiences like you can with separate order cycles.
Three Separate Order Cycles
This gives customers the option of selecting the ‘Ready for’ date as soon as they arrive at the shopfront. Each order cycle is customisable in regards to products available and enterprise fees.
You can’t have different shipping methods available in different order cycles.
Interacting with reports may potentially be less straightforward as you’ll need to collate orders across order cycles. This could be worked around however.
Three Different Hubs
The main advantage of this is that you can have different shopfronts for your different groups. This removes the likelihood that customers will select the wrong option (both possible in the above 2 options). The product prices can also be overriden and customised in each shop, as well as all fees (including shipping methods and fees).
Reporting becomes more complex
OFN fees are applied per shopfront, so this may raise the cost of using OFN (if the instance has fees)
I know this is from ages ago - but I’ve been reading back posts on using and super-admin to help me become a ‘power user’
So when describe doing this by ‘three different hubs’ …
Is this the same thing as a hub setting up buying clubs/groups - so there is a coordinator (I call them a mother hub) and multiple sub-hubs (Platform calls them ‘outging’ or ‘distributors’)?
And when you sal "OFN fees’ - which fees do you mean - are you referring to fees set up at the instance level for ‘charging’ users based on turnover? Or are you referring to enterprise fees the coordinator sets up?
The idea with the 3 different hubs option is that you will create 3 enterprises E.g Farmers Market East, Farmers Market South and Farmers Market West. Each has a separate day and a separate pickup location. Regardless of whether their order cycles are setup as 3 unique hub order cycles (where each market is the coordinator, and single distributor) or if the order cycle is setup as one order cycle, with the three markets as distributors, each enterprise (market) will have their own shopfront that customers interact with. Because each shopfront is unique, each one can have unique shipping methods, payment methods and enterprise fees.
Regarding what the difference is between the 2 options above… the main determinate of which option you want to do depends on logistics. Does each market want to same closing date for the order cycle? Or do they each need a different closing date? Do you want to order stock in a cumulative way (across all 3 shops) or do you arrange stock for each individually. If the 3 markets distribute in the same order cycle, they’ll have the same OC closing date and the coordinator can easily view the total stock ordered across the three shops in reports. If they run independent order cycles, the shops would be administered differently. In both options the shops can offer different products.
This is very helpful - I’m going to try to develop a set of ‘if… then…’ scenerios that help new hubs. I think this would be a good way to explain the OFN options.
So like a decision tree for hubs, that leads them to the best set up for them, and then takes them to the page in the user guide.
but my other question here is regard to your reference to ‘user fees’. Are you referring to the platform usage fees that the instance collects. I guess I’m asking where and how these are calculated. So - if Canada charges a 2% platform use fee - what do we consider the ‘turnover’ on which this is calculated?
so a hub that is also the single distributor - this is calculated on the transactions in that shop, and paid by this hub I presume. This platform use fee is separate from the enterprise fees the hub adds (although I guess they might pass this on to the consumer in an admin fee)
But if a hub has 2 distributors, Each distributor has a shop where consumers buy. So - is the OFN platform usage fee calculated in the distributor’s shop (when the consumer makes a purchase) so the distributor pays it. Or does the OC coordinator pay it? (Or does the instance ‘control’ this in some way? ie - it doesn’t seem fair that a OC coordinator AND a distributor both pay the fee, since it is ONE OC)
Yes, I’m referring to platform usage fees. These are calculated per shop enterprise, based on the turnover in their shop (plus any fixed fees, and potentially capped at an upper limit). If someone is a coordinator but doesn’t distribute, they will have no turnover so won’t be charged (so turnover isn’t charged twice, to the distributor and coordinator). However if there’s a fixed fee, plus turn-over, it is more expensive to have more shops. Here’s the page describing how to setup the instance fee calculator - Configuration > Business Model .
Each instance can setup their billing structure as they choose. The Business Model tool built into the OFN is quite flexible, but if you want to charge in a way that isn’t captured by the automatic tool, you can do that. At the end of the day, while OFN has a billing tool, users won’t actually get billed until you send them an invoice, so you can charge how you wish and make individual agreements with users if you wish (E.g. You might say…you can have 3 distributing enterprises but I’ll only charge you the fixed fee for one). See here as well - Enterprise User Accounts (configuration > accounts & billing)
I am going to jump on this old post too! @sstead Is there any particular reason why you can’t select different delivery and payment methods for different order cycles?
We have a bakery on OFN UK that has requested this feature, and I have explained the different workarounds above, but the ability to select delivery and payment methods of each order cycle really would make sense for them.
They have a recurring order cycle open weekly, to buy individual loaves of bread for collection at the market, and also an ongoing order cycle where you can buy a three month subscription of bread, for collection or delivery. If you are buying a subscription you can pay by card, but if you are only buying a few loaves in the weekly order they’d rather you pay cash. Similarly, delivery is only really viable if you pay the 3 month up front amount.
They are looking into tagging customers that want to buy a subscription, so the card payment and delivery options only appear for them, but this requires customers to make themselves known to the hub in advance. We’ve also looked at having them set up as two enterprises, but it is the same customer base using both and having two separate enterprises might limit the opportunity to upgrade a weekly shopper to a 3 month subscriber.
What’s the chances of getting this included in a future wishlist? Or is there something substantial about the way OCs are configurated that prevents you from selecting payment and delivery options for them?
Hi @mags this issue is on the radar. Unfortunately, at the moment Shipping Methods and Payment Methods are set at the enterprise level, not filtered out at the Order Cycle level. There are plans to overhaul the way Order Cycles are setup in the not too distant future and this issue will be addressed as part of this overhaul, but it could be some time until this happens. @oeoeaio has said he could spec out a small fix for this in about 1 day, however it’s a question of whether it’s a big enough priority?
The solutions you’ve mentioned above are the best options at the moment unfortunately. One other idea is to put messages in bold in the shipping method descriptions saying ‘Delivery for SUBSCRIBERS ONLY’, but of course customers can miss/ignore these messages.
I actually have this same issue with my own flower farm. I sell bouquets (one by one) and prefer internet transfer or cash at pickup. But I also sell flower shares - 20 x weekly bouquets. I’d like to offer delivery for the share holders - but not the ‘one offs’. I thought as a work around, I would set up a delivery option - but use price sack, so that if the order is under $100, delivery costs $20 or something. So it might deter the ‘one offs’ from asking for delivery. Just a thought. @mags