I’m starting this thread to follow-up the Slack discussion which happened here:https://openfoodnetwork.slack.com/archives/CG7NJ966B/p1611600286045900
The purpose is to share the cases of differential pricing we come accross and tips on how we deal with them on the OFN software.
In FR, several hubs are applying a differential pricing model (documentation in progress) the last one in particular gave me a set of constraints that is a bit more tough to deal with. Many thanks in advance to anyone helping me on this
In a nutshell:
- They have around 200 orders / week - 3 delivery spots - 2 payment methods - only 1 shop
- They want to start a new pricing model for people with low income
- This lower prices model will basically be funded by a lower margin on their side
- They won subsidies and a partnership with local authorities to do so
- Each week they have 2 order cycles: the first one handles meat products and finishes earlier and the second one all the other products. First OC start on Mondays, deliveries (by bike and pick-up at their physical shop) are happening on Fridays
- Even if a shopper orders twice : one order of meat, and one order of veggies e.g., they only get ONE delivery.
Because of these 2 OC / only one delivery system they already have a complex set of shipping and payment methods. Indeed, each customer ordering meat is tagged so that they can order on the second OC without added fees (example: if the shopper has chosen home delivery with a fee of 6 euros on his first order, then they can order on the second OC with a shipping method without fees - only displayed for tagged shoppers).
Same for payment methods, as they consider Stripe to be too expensive, they only allow shoppers who have chosen home delivery to pay by credit card on OFN (this is done with trusting the shopper as OFN does not allow any direct link between shipping and payment methods).
Alright, so now back to differential pricing:
- people with low income will go to their physical shop to get listed as people allowed to checkout with lower prices
- These shoppers are living in the neighborhood of the physical shop, so they will often come to the shop to order OR order by phone
- They need to keep strict records of people ordering this way to report back to local authorities (including shoppers info)
- Often these shoppers do not have an email address
So I have 2 blockers currently:
- How to deal with shoppers who don’t own an email address? Apparently thanks to the slack discussion I’m heading towards using an individual fake email address, that the hub will be able to reuse each week in order to load all shopper info (address etc)
- How to implement the pricing model other than using a negative fee in payment / shipping methods? Given how complex their shipping and payment method system is… Note that I’ve already suggested them to create several shops, but they are really afraid of that solution…