Hubs can block shoppers / decide who accesses their private shop

Software improvement (Archived)
,
1

What is the need / problem

  • As a hub manager I run a public shop and require customers to login to buy. But some customers buy and don’t come to pick up. Or even if the shop is public the shop is invisible on the map and we send the link only to the list of members so when people are not members anymore we want to keep the records but remove their access to the shop.
  • As a hub manager I run a private shop. With the way the feature is designed today, all the people listed on my customer list can access my private shop.
    If I want to remove the access to my private shop for a customer, today I have no way to do that: I can’t delete a customer from my customer list. I can’t either setup anywhere that he cannot see my shop.

Who does it impact

All private shop hubs + invisible shops who manage member access on public shop + public shops who have issues with some shoppers.
At the end it’s quite a lot of shops.

What is the current impact of this problem

The hub manager cannot block / remove access to the shop.

What is the benefit in focusing on this

Enable hub manager to remove access to customers who previously had access if they are not members anymore or if they didn’t honor their previous order engagements.

Links to more details

An issue was opened in GH, we thought it was a bug but was just that the feature was not super well designed. So we propose to evaluate the feature candidates to answer that need and choose one before we implement the private shop v2 feature that allow removing access for customers.

Potential solutions that will solve this problem

1 - Add the possibility to “block” a customer (status “blocked” for a given shop on a customer account). That would either:
1.1 Remove access to the shop so users can’t see the shopfront and get the message “You can’t access that shop, either because it requires membership, or because the shop manager has denied access. For any question you can ask [hub mail]”
1.2 Shop the shop but prevent shopping when try click on “checkout” instead of having the link to choose between login and checkout as guest, we could display. "Your status with that shop doesn’t allow you to checkout. Please contact [hub mail] for further information
2- Soft delete a customer from customer list. Should not affect previous records with that customers (orders basically), just remove the customer from view in the customer page, so the customer will not be able to buy again. The problem is the shop loose track of the activity with the customer, doesn’t sound ideal… That doesn’t solve the problem of blocking access to a customer on a public shop (invisible or not)
3 - Add a column in customer page called “shop access” and a check box that enable to give/remove access. The access to the shop should be conditionned to this checkbox. Advantage is that the hub manager doesn’t loose the history of the relationship with the user, and can manage users who become active, inactive and then active again (like a buying group member who stop being a member for one year and join again). Messages display could be same as option 1 (3.1 and 3.2 then).

We would need some dev input on how complex 1/3 are. I think 2 doesn’t solve the issue… even if it will be needed at some point.

T-shirt size of the selected feature candidate

Feature candidate to be chosen first

Metrics to measure if need is well satisfied after feature has been implemented

  • every hub can block access to a specific customer account (registered customer) to their shop. (Y/N)
2

It seems that the “delete customer” button is shown even if it will raise an error, right?

Today a user raised this issue and probably we should at least avoid showing the button if the action is not possible.

Could this be a small step improving the UX on that page? It sounds like a “low hanging fruit”, but we need to check.

3

Hum… we could but I would rather vote for investigating that time on working on the solution to make that possible. We might want to increase the priority of that somehow this year… if that’s possible. At least by May we have some obligation regarding data regulation (not really covered here but connected). Even in UX I think it’s better to have a button that is diaplsying an error message than no button, it shows at least our will to make that happen :face_with_raised_eyebrow:

5

As a comment, another option rather than deleting a customer could be to “block her” or “deactivate her”. So when the user login, the access has been removed even if it is still in customer list. That could work btx also for non private shop and seems like maybe a solution with more value and maybe less effort.

6

@tschumilas @lin_d_hop @Kirsten @sauloperez (you should invite Guida here so we can ping her !!!) did you have any similar requests ? We had it from 2 hubs already. I changed a bit the phrasing and description of potential solutions as it doesn’t concern only private shop and the solution could enable to block customers on both private and public shops and would add more value…

7

This has been an issue for 2 hubs who have tried out OFN here in the past few months. Neither hub became a user and the hubs both said - "I want more control over my customer list’ as the reason why. So this issue is part of that. I think we need to do something. Hub managers need to be able to ‘control’ access to their shops - even if this wasn’t a legal issue, its solid customer relations. I don’t know the relative costs of the above options - but I like Add a column in customer page called “shop access” and a check box that enable to give/remove access . The access to the shop should be conditionned to this checkbox. Advantage is that the hub manager doesn’t loose the history of the relationship with the user, and can manage users who become active, inactive and then active again (like a buying group member who stop being a member for one year and join again). Messages display could be same as option 1 (3.1 and 3.2 then).

If we could do this, it is another step toward helping hubs to maintain more robust contact lists.
That said, I’m OK with other options too - I just think this is the best option. Open to other ideas.

8

If you think it is priority @tschumilas you can vote on it, the more vote the quicker we will move forward on inception and implementation :wink: Thanks for your feedback !

9

My understanding of the customer list is that it is designed to enable access to private shopfronts.

The fact that you cannot delete a customer is more of a bug in my mind. I would be in favour of opening an issue for the ‘cannot delete a customer’ issue such that the private shopfront issue actually works.

I’m not sure I’m a big fan of the complexity of having a customer list with a ‘shop access’ checkbox. There are many ways to see past shoppers in OFN that meet the needs of users to understand their current and past shoppers.

I can imagine the support queries coming in from the added complexity, particularly if we find ourselves with a bug in the ‘shop access’ read blocking customers from shops. Let’s aim for less complexity rather than more :slight_smile:

1 Like
10

not heard it - @sstead more likely than me to know for aus

11

@lin_d_hop I partially agree with you.

1- This page is used not only by private shops, but by any hub to update some customer information, tag them, and if I remember well discussions we had in Aus, we even said it could be the base of a “mini CRM” with a bit more ability to quality the customers. Also in Barcelona @Rachel started to rework on that page given the “customer category” feature (be able to propose different prices for different customer category).

Also your solution doesn’t solve the problem mentioned above : it means a public shop can’t block a shopper they had bad experiences with. If I’m a public shop, I delete the customer I don’t want to see anymore, this customer can order again and will reappear in my list…
It means then we have to force a shop who wants to block a customer to become private, but what if they want to remain public and be openly accessible ? I don’t think recommending them to become private is a solution.

2- But I agree that we could start with that, it would be simpler and a first level of answer at least for private shop users, and we will anyway need to enable to delete a customer (and we need it for GDPR). Then we should specify at the top of the page that “this list contains by default all the persons who made an order in the shop. And if their shop is set up as “private” this list is also the list of people who can access the shop. So if they run a private shop and want to remove access, they need to delete the customer record”.

So I can reopen that bug to start with https://github.com/openfoodfoundation/openfoodnetwork/issues/1494 and then we can see how to iterate to improve customer management by hub managers.

Would like @Rachel opinion on this also as she worked on it already.

12

Sorry for the brief answer from my phone…
Regarding blocking customers - if a customer wanted to order they could check out as guest with a different email to circumvent being blocked. I fear implementing functionality to block a customer would be a lot of work for little practical gain. Maybe this problem is better solved in a non-software way?

13

Yes… I mean they can always create a new email even if the shop force login… you’re probably right, probably there is no automatic way to prevent that.

So the plan would be:
1- enable delete customer (for private shop control of who can access)
2- Improve customer page (related to work on customer category, and maybe we can review later if makes sense to not force deletion of user if want to remove access to private shop)

@tschumilas does it makes sense to you and answer your need ?

14

Blocking customers is not an issue for me - I don’t think its necessary (haven’t heard it from anywone). And as @lin_d_hop says - a customer can check out as a guest in a public shop.
The concern I’ve heard is about private shops (not public). The screen suggests the owner can delete a customer - but they can’t. So - for sure the button shouldn’t suggest they can do it. So - I’m totally in favour of what you propose @MyriamBoure - a private shop being able to delete a customer. (Even in my own flower shop, for example, which is private for florists and designers, the client list changes all the time - and I’ve had florists asked to be removed from my list - and I can’t comply with their wishes.So that’s not great.)

15

Ok so I reopened the bug https://github.com/openfoodfoundation/openfoodnetwork/issues/1494 and I propose to close this post for now and we will open another wishlist if / when needed to improve customer page / customer management.

18

Additional investigation from @sauloperez in Github #1494:

"After the insightful input I better understand now what’s the situation. Fundamentally, there are few features tight together in the Customer model. Granting access to a private shop, the list of customers a hub manager wants to keep track of (a CRM-like idea of customer) and tagging: giving access depending on criteria defined by a manager.

Now, however, there’s no way I can do one without the others. If I want to add a person to the list (to keep her in the loop of my hub) and I happen to have a private shop, I’m granting her access to it. If I made a mistake I can’t delete the customer and I understand that’s annoying. Also, if I remove the customer the underlying user we’ll skip any tagging rules and end up buying the variant I don’t want her to. You see? the Customer model serves multiple purposes at the same time.

So these various use cases need to be decoupled so that I can do one without the others. Then, my question is. How should we proceed? This issue’s expectation is explicitly related to revoking access to private shops but the issue’s title relates to enabling deletes. First, we need to separate these two issues and start with one.

I started exploring the idea of soft-deleting customers in #3457 (soft-delete = flag it as deleted and filter out deleted rows everywhere, which avoids us from losing data), but that doesn’t address this coupling issue. We still experience the problems I described above. Also, it’s not clear to me if someone is using the customers’ list as a CRM, if that was the case I’d go with #3457 which is nearly finished. Still, with these problems but it would solve the private access revocation.

On the other hand, we can implement explicit permissions to grant access to private shops but that requires a bit of UI and deeper thinking. IMO it should be then addressed as a feature and not a bug, although removing customers feels on the edge as well. We could perhaps start with the delete and consider explicit permissions meanwhile if we think it’s a priority.

In any case, let’s not rush and get a Frankenstein out the door. Let’s reach consensus first. I’ll close #3457 meanwhile as it’s blocked and the Spree upgrade should be our focus."

Reopening this in Discourse as we agree this should go through the prioritization process.

21

Migrated to wishlist board: Hubs can block shoppers / decide who accesses their private shop · Issue #101 · openfoodfoundation/wishlist · GitHub