@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?
This remains needed and quite important on legal side. It is clear enough to be prioritized when we want, leaving it in voting candidates.
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.
@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… 
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.
@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.
“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
Okay so first iteration could be the following:
- 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 ?
- 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.
-
As long as the hub does not complete the field, we don’t show that checkbox to the customer
-
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 
ping @danielle @lin_d_hop @Kirsten
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
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.
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.
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
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.
I totally forgot about subscriptions… 
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 
Some brainstorm on my side:
-
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”.
-
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.
-
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
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!
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!
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.
@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.
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.
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
Hello !
A little update and some further questions 
I think the correct place for uploading the file would be in business details. So it would be something like this:
What’s missing here is that I think we will need to add a little info on the file size and format.
I’ve used the “what’s this” tooltip as I figured we would like to remind them that this is important info.
However I wonder: do we want this to be a mandatory field to update the page?
After upload of the file (and our infamous green banner telling success has happened ), I understood that we will get something like this:
I’ve added a download of the file in my drawing. Scope creep?
Something I will need to confirm with a tech owner here is when do we send the file up? This page has update/close button at the bottom, so I’m guessing nothing happens before I click update? 
In anycase, after clicking on it we will need to display a confirmation text. A bit like this:
This text can be changed in translation, but any good English sentence is welcome
On the buyer side, I still need to figure out what’s the best display, especially if we want to introduce the last update date. I will see if Yuko can help me with a good UI on this From our previous discussions I conclude that we will:
- NOT tick the checkbox by default unless the buyer already agreed to them previously
- disable the checkout button if the checkbox is not selected
- uncheck the checkbox if changes have been made
A summary of all the things we are putting aside for a first iteration:
- Mentions on invoices templates / buyers with no account
- Subscriptions
Does it wrap up correctly everything @lin_d_hop @Kirsten @luisramos0 ?
Also I want to link here a discussion we had today with @Bato as it appears that this solution won’t work at all for Turkey : https://openfoodnetwork.slack.com/archives/C0DNLAZC7/p1588860866200200
Maybe there are other countries with particular legal aspects on this, so I would like to make sure that all active instances know we will introduce something like this. ping @tschumilas @lauriewayne1 @Eugeni @hhomann