What is the need / problem
- Fred sells his products to both Mary and Shannon, he wants to ask a different price for the same product to Mary and Shannon.
- Mary sells to members and non-members, and want to take a different markup on products for each of her customer category.
Who does it impact and what is the impact
Fred, Mary and Shannon, they are not able today to easily charge a different price to different customers for a same product.
Implies Impossibility/Difficulty to use OFN: Mary/Shannon/Fred charges different prices for the same product to three customer. The only way for her to do that is create 3 variants for each product with a different price for each, and display/hide variants depending on customer tag. Or just create 3 enterprises and duplicate the product catalog. It is very time consuming and hard to manage. She prefers not to use the OFN for the moment.
Some do “hack” the system and setup a payment method “for members” with -10% as a fee that is only visible for members. But it doesn’t cover all use cases, and it prevent the hub to really propose various payment methods and charge fees for them as well if they hack it to offer discount… so it’s not a solution.
What is the benefit in focusing on this
- It would enable Fred, Mary, Shannon to ask a different price for a product to different customers, so they would be able to manage properly their sales and gain in efficiency.
Potential solutions that will solve this problem
1- Enable different fees to be charged based on tag used.
Hub manager creates different enterprise fees for each customer group, and in OC, on “outgoing distributor” line, she can select for a single distributor multiple enterprise fees. When user logs in, depending on her tag, only the fee that applies to her “tag” is applied on price calculation. That requires to create a new tag rule type “applicable/non applicable” enterprise fee.
Pros: we keep on using the same current tag logic.
Cons: it only works for prices that can be “calculated” for instance if a seller have a discount price for wholesale but with one by one price adjustment it’s not managable. It’s probably not a usual case though, most of the time sellers will have a % discount for some groups.
2- Build a full pricing table where the hub can define customer categories and set up prices for each product for each of them.
Pros: this is the most flexible way to introduce the feature and would cover all specific use cases. Less constraints for users.
Cons: it requires time to maintain for user, unless there is a way to update in bulk prices for a while category, like “setup up prices for all products for customer category X = prices for customer category Y - 10%”, then it fills in all the prices but you still can update one single price if you want in the table.
3- Take a % discount approach for whole shop using tag rules
That requires to create a new tag rule type “discount”.
Default tag rule = no one has any discount
Tag rule can be : if customer tag = member, apply x% discount on all products in the shopfront.
Question : I guess it is on variant master price excluding any fee ? I think the fee logic we use until now make those kind of rule hard to apply in a way that fits everyone. A hub who add a markup of 20% on product will want to apply a discount to the prince including fee.
Pros: Use the current tag logic in a pretty simple way
Cons: not a lot of flexibility, confusion about on which base price apply the discount, can there be a common rule for all ?
4- Use Spree promotion feature
https://guides.spreecommerce.org/user/promotions.html
See “user” in “rules” section. “You can use the User rule type to restrict a promotion to only those customers you declare.”
Then “actions”, “create adjustments”. Action can be "create a flat % reduction on each order, or each item.
Question : would the reduction apply to the fees that are already treated as adjustments ? I think not… it’s gonna be tricky to make it work with our enterprise fee logic I’m afraid, but it might need more investigation.
Pros: Follow the Spree logic so avoid a new customisation
Cons: Might not work properly with our enterprise fee logic + confusion in UX between the tag logic and promotion groups logic. It’s a new way to make “groups” and apply rules to those group of users, might be confusing on UX prospective.
We did some brainstorming in Barcelona gathering and said option 2 seems to be what we need. We worked on some design solution that @Rachel shared in Porto and those 4 solutions came up.
Value x ease analysis and selection of our feature candidate
To be done
T-shirt size of the selected feature candidate
To be done depending on which feature is chosen
Metrics to measure if need is well satisfied after feature has been implemented
To be described
Epic and/or project board where you can follow implementation
To be described.
Connected wishlist and discovery discussions:
- Github issue with advanced speccing: https://github.com/openfoodfoundation/openfoodnetwork/issues/1824
- Community discussion: Enable different fees to be charged based on tag used
So I miss a lot of notifications…