Hubs can ask their customers to validate their own terms and conditions

Software improvement 3-Pipe-ready
,
Tags: #<Tag:0x00007f45e1206060> #<Tag:0x00007f45e1205f98>
#1

What is the need / problem

Today instance require hub to accept “terms and conditions” when they want to create their first enterprise.
BUT the hubs that use our platform as legally required to ask their customers to validate the shop’s terms and conditions. Today there is no way for a hub to ask their customer to validate their terms and conditions while shopping.

Who does it impact

All merchant hubs in various countries (at least France but I’m pretty sure it’s not only France)

What is the current impact of this problem

Food hubs are out of law

What is the benefit in focusing on this

Hubs will be legally compliant.

Links to more details

NA

Potential solutions that will solve this problem

I suggest a very easy solution which is to enable a hub to link the url for their terms and conditions in their enterprise profile (on menu: legal where there is alredy the VAT stuff) + we add a small checkbox at the end of checkout “I validate [enterprise] terms and conditions”.

Product curation meeting #16 notes - 30 June 2020
Product curation meeting #13 notes - 19 May 2020
Product curation meeting #14 notes - 2 June 2020
Product curation meeting #15 notes - 16 June 2020
#2

@MyriamBoure can you please assign this icebox item a sub-category? Draft or Review Ready or Approved?

I wonder whether it actually is a legal requirement for all instances…perhaps worth finding out?

#3

This remains needed and quite important on legal side. It is clear enough to be prioritized when we want, leaving it in voting candidates.

#4

I guess we need to show the checkbox on checkout only when customer has not accepted previously the terms and also add something on the backoffice customers list to show if a customer has accepted the terms.
This is an S, maybe M.

#5

@luisramos0 why only when the customer did not accept them previously? When I look at other ecommerce shop, I have to check them each time I do a purchase. I guess they do that because they update them often. how was it at Farfetch?

Doing it for all orders would simplify the work, isn’t it? The only tricky thing I see for our case is for subscriptions… :grin:

#6

At FF the terms are at user registration. Not at checkout. It’s probably because of the god of ecommerce called conversion. An extra checkbox impacts conversation…
We shouldnt show the terms all the time because of conversation (and UX noise on checkout).
But yes, we can show it all the time, we still need to record it at order level… so maybe better, and not much harder, to implement it at customer level and not show it all the time.
Anyway, I dont think this would change the estimate. Maybe a more solid S.

#7

@luisramos0 I agree about the noise. The problem with putting the terms and conditions at customer level is that one customer can shop at several shops on the OFN. Yet terms and conditions are specific to one particular shop…
So I’m not sure we have another option than to put it at checkout…

If we don’t put it all the time we will need to think of a UX journey when the hub updates its terms and conditions.

#8

:+1:

“If we don’t put it all the time we will need to think of a UX journey when the hub updates its terms and conditions.”
Maybe just clean up the records for that shop customers so that users will see it again on checkout.

1 Like
1. Hub's suppliers can prepare the invidual orders for the hub's customers
#9

Okay so first iteration could be the following:

  1. Add in the /business_details page a part where the enterprise manager can add their ToC and ToS

What type of format it the easier for us @luisramos0 ? PDF or text area with WYSIWYG ?

  1. At checkout we display a checkbox with a sentence closed to something like:

You agree to [INSERT SHOP NAME] ToS and ToC (with 2 links that open in a new tab)

My proposal is that the checkbox is selected by default. If the customer unselects it, the checkout button becomes disabled.

  1. As long as the hub does not complete the field, we don’t show that checkbox to the customer

  2. We need to make a change in the customer list : the checkbox yes / no should be stored in our database. We cannot migrate our database and say all previous customers have agreed. So we need to store that info for the hub to see it.

One unresolved comment on my side:

Hubs are legally forced to warn their users when they change their ToS or ToC but I didn’t yet found the responsibility of the marketplace provider: are we legally responsible to warn the hub’s client if the hubs changes something? It can be fairly complicated if it is the case :exploding_head:

ping @danielle @lin_d_hop @Kirsten

#10

sounds good.

Last case - could it just be that if there is a change - new pdf file uploaded or edit to WYSIWYG

Perhaps a ‘revision’ text field and date for the Hub to summarise what changed - creating this revision could be what triggers customer notification

Either:

  • The customer is notified in checkout - ToS or ToC have changed since your last order. Click here to see changes (show the ‘revision’ box) and ask them to tick again

Not sure if that’s overcomplicating things

My vote would be for pdf. Too easy to change WYSIWYG by accident and I think important that they also have a clear record of what ToSC that had on particular date. They should have pdf files for each time they publish. And we only have the current pdf files. Otherwise we will end up in some kind of ‘track changes to WYSIWYG’ hell

#11

yeah, I think wysiwyg is easier to implement but PDF sounds better.

What if when they upload a new pdf file we warn them that the acceptance records will be voided and we void all customers ToC acceptance records (void can be different from delete), so they all need to re-tick the checkbox on checkout.

#12

To alert people to changes I reckon its best to follow the examples of the bigger players i.e. send out an email advising that the terms have changed, briefly explain the changes, add a link to the new document and then something like "if you continue to use the system after dd/mm/yyyy, you are deemed to have agreed to these changes. I dont think asking them to retick a box is useful as they will just tick it without reading anything - better to tell them of the changes.

#13

Definitely a PDF as this is definitieve and cannot be easily altered - should also be under version control with a Version number, date of issue and the comment that this replaces the version nn, dd/mm/yyyy

#14

Hubs are legally forced to warn their users when they change their ToS or ToC but I didn’t yet found the responsibility of the marketplace provider: are we legally responsible to warn the hub’s client if the hubs changes something? It can be fairly complicated if it is the case

My understanding is that the answer to this is based on the kind of contract.

For subscriptions there is an ongoing contract and the user will need to be notified of an changes.
For a normal checkout the shopper is bound to the contract that they agree to at the point of checkout.

For example: a shopper checks out in week 1 with contract 1.0. The sale is bound by the rules of 1.0
The contract is changed.
Then the shopper checks out in week 2 with contract 1.1. This sale is bound by the new contract.

Might be worth confirming this so that it can be made clear to the hubs that if they have subscription customers the ToS and relevant changes will not apply to subscriptions by default.

#15

I totally forgot about subscriptions… :scream:

Notification is one thing but the bigger problem I see is that it also means that some customers can absolutely NEVER visit the checkout page hence never accept the ToS or ToC :woman_facepalming:

Some brainstorm on my side:

  1. Remove this from the scope here. Just add a sentence on the subs page saying “when you set up a subs, people are not validating your ToS please send them a copy per email and ask them to agree before setting up the sub”.

  2. Do something close to 1. But automated. Maybe something close to a validation of the subs from the customer? This is maybe already in the scope of subs v2 I need to check.

  3. Have another place where the user can check or uncheck the box - something like user profile. But we would need to set up a box per shop. So there is the question of how we would build the list of shops as obviously we don’t want the full list, but it is possible that the customer never ordered before with the shop… I wonder if we could force somehow the customer to do a first order with the hub :thinking:

This makes me think also of another case: people with no email accounts. Currently my hubs are doing admin orders for them with a fake email address. I guess this is a question for a lawyer…

Thoughts @lin_d_hop @Kirsten @luisramos0 @Permakai ?

Aside of those questions I think I have enough material to draw some mockups here before moving forward. Thank you everyone!

#16

I think for the purposes of getting this done - let’s go with 1. There are many ways to do it better but we want to knock this off and I think that is adequate. The hub is placing the order for the customer and therefore is their responsibility to ensure the customer knows.

One slight improvement might be a thing on the last step of subscription creation that has a button to email the customer with ToS attached and tell them to cancel their subsctiption if they don’t accept? But then that opens up actually sending them a notification that their subscription has been created which i don’t think actually currently happens!

#17

Why is this our problem? Surely the contract is between the hub and the customer. If the hub changes something then its the hubs responsibility to let the customer know. I’ve made phone orders and have never been asked if I agree to some T&C or whatever. Its implicit in the taking of the order that the customer is familiar with them - otherwise trading law allows the customer to reverse the transaction within a certain period, usually 8-10 days. Its simply a question of adding (usually in incredibly small writing) to the bottom of the delivery note/invoice, or whatever the mention that by accepting this order you have agreed to t&c on the website.

#18

@Rachel for now manual and later in subs v2, customer confirmed (or placed) subscriptions.

re people with no email accounts, I dont think they are using the platform so they will not have to accept the terms.

#19

Yes that was my solution number 2

Why is this our problem?

It’s something that is unclear to me in the legislation. If you have any legal document that can back that up I’m all ears!

for now manual and later in subs v2, customer confirmed (or placed) subscriptions.

@luisramos0 I’m not sure what you mean by this sentence? About people with no emails, we are talking here about the ToS of the hub, not the ToS of the platform. So even when you have no emails you need to accept the terms as the hub is making an order in your name. But I will leaving this for later. Like Rory is suggesting that would maybe need to add the ToS link on the invoice.

#20

Sorry I was not clear. I meant I think we should have a manual solution for now. And later, in subs v2, we can sort this out on the customer side by adding a checkbox to the create/edit subscription page of the customer.

1 Like