An enterprise can offer different prices for different type of customers (ex: members, wholesalers, etc.)

listed
network
Tags: #<Tag:0x00007f4315ffb270> #<Tag:0x00007f4315ffb130>

#1

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:


WIKI - ordered inception backlog (discovery and inception)
Enable different fees to be charged based on tag used
#2

Local Orbit handles this. Worth discussing with them why is done the way it is and what they do or don’t like about it


#4

I’m moving this to review ready as the need seems specified enough to me. @Kirsten @danielle @Rachel great if you can have a look and tell if you agree. Investigation about how we implement it has already been started in Barcelona, but of course we’ll be happy to discuss with Rob to see how Local Orbit handles it. As a reminder: this is also the first bit we decided to start with on the “network” feature. We have regularly requests from users, I had again one this morning from a big cooperative in Sicily starting to use OFFrance.


#5

Ok I hit again today the need, I was talking to a farmer selling to a current hub and willing to create two other shops on OFN, one to sell to restaurants/pro, the other to support their online farm. but they propose 3 different prices top the current hub, their professional client, and their farm shoppers. It is such a basic ecommerce feature that we don’t offer ! I have to ask this user to create duplicates of their own products to be able to do that it is silly! @Kirsten @danielle @Rachel can you review and approve that icebox item pleaaaaase!


#6

@tschumilas didn’t you hit that frequently as well?


#7

The thing I am confused about @MyriamBoure is how this interacts with Network 2.0. I realise I missed Barcelona and therefore probably important stuff - but I thought the first step in Network 2.0 was to build a prototype to test assumptions. Do we need to do that before progressing this? Or it was agreed to skip that step and go straight to implementation, picking this bit off first?

I have no objection to progressing this, I would just like to see a clearer explanation / reassurance that it has been thought through how to do it in the way that is moving Network 2.0 . .


#8

@Kirsten see the last part of Inception session: product chain data model where we added the things from Barcelona discussion; We agreed price listing and customer category was the very first step toward network feature, and doesn’t need the whole product chain to have been done already. Rachel and I worked on mockups and UX and discussed with Matt and Lynne, Rachel is going to publish it in a couple of days, but it’s already solution design so we need to prioritize the need before we move forward.


#9

ok, fine with me :slight_smile:


#10

I’m fine with it as it is for now ! Sorry I haven’t answer sooner, I’m still struggling to come often around here :frowning: So I miss a lot of notifications…


#11

Does this mean you consider this icebox approved @Kirsten? Can we move this to approved?


#12

sure let’s do it and more characters


#13

I think we all come across this need all the time - but we are finding ways to manage some of it now:

If Fred sells to Mary and Shannon, he uses keeps his basic (no markup no fee) price for the hub, and adds an enterprise fee in his farm shop for the retail customer (I do this know - very easy)

If Mary sells to members and non members or to retail and wholeale buyers -she has several options - yes as you say - duplicate products and tag… But she can also set up 2 shops with different fees applied to all products - bit easier.

But I have no objection to moving forward on this if it is setting the stage for our network features, and to make setting different prices easier (I’m just noting, its already pretty easy compared to lots of other OFN stuff)


#14

I agree with you somehow @tschumilas about your workaround n°1, I propose the same, but producers are not happy with it, they don’t want THEIR shop to shop a 20% margin, they want the wholesales shops to show a 20% discount, it has quite a big marketing impact… So this workaround is not satisfying.
Another way to do it is to put wholesell price in catalog and retail in her own inventory and base her shop on inventory, but it limits to 2 prices only.


#15

I see what you mean @MyriamBoure about showing a discounted price - I hadn’t though along those lines before - a bit of a marketing game I guess. Anyway - I concur with this icebox feature and will be voting for it. Its good to have more options for users.


#16

Again, I had another case yeasterday, Italian big hub, they offer different prices for members and non members (actually they charge a fee only for non members). We found a hack by putting a negative % as a “payment method fee”, it’s terribly hacky but it works… customer choose “Pay on delivery for member (-10%)” and “Pay on delivery for non members” but it’s not scalable.

IMO this is the most painful thing I see in the OFN world today, in term of request from user support, amont the French users I think not even One hub doesn’t encounter that issue. I’m surprised it’s not annoying other instances as much :wink:


#17

UK deal with it in the same way: -% payment/shipping methods.
It is certainly annoying UK hubs… but still less than many other things unfortunately.