1 Introduction

Customer Door Codes or CDC enable people and shops, service providers or public institutions (‘sellers’) to exchange standardized information about the following issues:

• Whether the seller has available concrete features that empower customers;

• Customers’ feedback and/or complaints against sellers;

• Sellers’ information to their customers or potential customers that they are interested in; and

• Customer’s information to all his or her respective sellers with implemented CDC about a change of customer’s profile done in one click.

In addition, users of CDC will be able to inform any seller about their key preferences (e.g., that they care for strong protection of their personal data or for an efficient online dispute resolution [ODR]).
CDC can be easily implemented by customer apps as well as by sellers on their website or seller-focusing apps.
This is an initial working draft proposal for discussion within interested communities.

2 [Yellow Button=Customer Door]

The availability of the CDC could be presented by the seller through a [Yellow Button] banner on his or her website. This sign will enable potential customers to see that the seller has implemented the CDC before deciding on any purchases. The seller might also post basic information related to his or her CDC in connection with the Yellow Button sign (e.g., what customer-empowering features the seller offers).

3 How It Works

Through the CDC, each of us can ask any seller whether he or she implemented the desired features described by the CDC (see later). Such ‘pre-transaction information’ is important for more and more people in their decision making whether to buy from the seller.
In addition, CDC enables people to file feedback or complaints against any seller, private or public. If the seller provides his or her own feedback or complaint feature, the seller can provide it to customers directly in his or her own ‘branded’ form.
If the seller does not provide the requested feature, people will still be able to file a complaint or feedback in generic, non-branded forms through their customer device and communicate it in this generic form to the seller.
On contact with a seller (e.g., by walking into the seller’s shop, by visiting the seller’s webpage or otherwise), customer app will receive a CDC for that particular seller.
The app will then read this code and does the following:

• Finding out whether the seller has a CDC;

• Finding out whether the seller provides concrete empowering features (see later);

• Finding out whether the seller has a complaint form or feedback form or both;

• Finding out the seller’s preferences (if any) if the seller has more than one available complaint or feedback forms;

• Finding out the languages of the respective forms;

• Providing a URL link to the forms in each of the languages;

• Providing an email to which information about customer preferences the seller does not provide yet (e.g., the language missing or ODR or privacy preferences not on offer yet) might be communicated;

• Presenting to the user as an alternative a generic customer-friendly forms for complaint/feedback that the user might complete and file via the app if the seller does not meet customer preferences; and

• Sending to the seller the respective form filed by the user by email, including informing the seller about desires of their customer that are not yet provided by the seller.

4 Specification of the CDC for Information That the Buyer May Want to Know before Making a Transaction

4.1 Preliminaries

Beginning string: “INFO_PRIOR_TO_TRANS:-”. This informs the app that it is reading a CDC concerning the customer empowerment features.

4.2 What Features the Seller Has Available

This part of the CDC checks whether the seller has policies that match the customer’s preferences before any transaction takes place, which helps the customer decide if he or she wants to buy a product from a particular seller.
More specifically, this section of the CDC will provide answers to the following questions:

1. Do I, as a customer, want to receive a detailed notice describing what personal data will be collected and how it will be processed?

2. Will it be possible for me as a customer to easily refuse certain ways of processing my data while still being able to buy your product or service?

3. Will I be able to choose what information you send me in your emails or other correspondence? Specifically,

   • Send all information only to my account—no emails please (I will provide you with access info to my account);

   • No sharing of my data with third parties please—inform me only about your products/services;

   • No information at all please; or

   • No restrictions.

4. Will I have the possibility to escalate any issue to an independent third party (ODR)?

These questions will be answered by a string of seven digits – each either ‘0’, ‘1’ or ‘?’, where ‘1’ gives an affirmative answer, ‘0’ a negative answer and ‘?’ a neutral answer that will be used when either the customer does not provide an answer or when he or she simply does not care about the issue or when a customer app does not support corresponding feature.
Therefore, a customer who wants to be able to use ODR but does not care about his or her personal data use or email correspondence will have the code “INFO_PRIOR_TO_TRANS:-??????1:-”.
Once the customer sets out his or her preferences in the customer app, the app will match the seller’s answers to these four questions and notify the customer of what the seller can or cannot do for him or her. Furthermore, the seller might choose to include in his or her CDC an automated message with related information, for example, a link to the seller’s relevant CDC landing page. This message will also be read by the customer app and appear on the customer’s screen.
The seller will include such message in its CDC in the following way: “MESSAGE:-xxxxxxxxx:-”, where the ‘xxxxxxxxx’ gives the text of the message. Messages will follow specification of the customer-empowering features separated from them by a comma. If a message is not given, the character ‘*’ will be given instead.
Therefore, a seller who provides his or her customers a detailed privacy notice but no other empowering features and who also has his or her CDC landing page in English only will have the following CDC on his or her website:
“INFO_PRIOR_TO_TRANS:-10000010,www.seller.com/cdc_en:-”, where www.seller.com/cdc_en will be the seller’s landing page for CDC.

5 Customer ID

This part of the CDC code transmits the customer ID so that the customer has one ID for all his or her sellers that have implemented CDC. This will enable customers and sellers to actively exchange information via their apps, not just read the CDC. Sellers will then be able to send automatically information that their customers ask for to their accounts in their apps. And customers will be able to change their profile info for all these sellers in one click, allowing sellers to update any information in their databases easily.
The way the customer ID is formed will be decided individually by each CDC provider. However, the main code will look like this: “CLIENT_ID:-xxxxxxxxx:-”, where the ‘xxxxxxxxx’ gives the customer ID.

6 Specification of Customer Door Codes for Complaints

6.1 Preliminaries

Beginning string: “CUSTODRDC:-”. This informs the app that it is reading a Customer ODR Door Code.

6.2 Beginning of a Complaint Form

The system will now provide information about complaint forms. It will first transmit the number of available complaint forms, each of which will be specified in the next section, and a possible way to code this would be “COM:-4:-”, where the ‘4’ could be changed to any number indicating the number of complaint forms available. If this number is zero, then no complaint forms are available.

6.3 Specifying a Complaint Form

Each complaint form will be specified individually and will include the following information:

• The preference of the seller to use this particular complaint form;

• The language of the complaint form;

• Whether ODR is available;

• What form of ODR is available; and

• The URL link to the complaint.

This information is described in the CDC in the following way:

• Preference: ‘2:-’, where the number indicates the preference to the ensuing complaint form. The complaint form starting with ‘1:-’ would be preferred to the complaint form starting with ‘2:-’ and so on. If the number is ‘0:-’ the seller has no preference regarding its complaint forms.

• The rest of the information about the complaint form can be encoded in square brackets. Therefore, the whole string for each complaint form can look like: “1:-[XXX]:-”, where the ‘XXX’ is specified in the following bullet points.

• Language: Each language has an HTML ISO Language Code, where it is represented by exactly two letters. For example, English is ‘en’ and Czech is ‘cs’. Therefore, the language of the complaint form will be encoded as ‘LC:-’, where ‘LC’ is the particular language code.

• Specification of the form: This will specify the features of the complaint form. It will consist of a series of questions that will inform the user if a complaint form contains certain features. The mandatory questions used to specify the complaint form are:

There will also be some non-mandatory questions. These might be, for example, as follows:

Each answer will be separated by a comma to increase readability. If an answer is not given, the character ‘*’ will be given instead. Therefore, a form with available ODR that is based on mediation and with a minimum cost of 5EUR but a maximum cost not specified will have the following code: “1,1,10EUR,*”.

• URL Link: This is the URL link to the complaint form. This is encoded in the following way: “&&&www.seller.com/feedback-en&&&:-”, where the ‘&&&’ give information to the user app that it is reading a URL code.

Therefore, if a seller has two complaint forms, a preferred version in English on the page www.seller.com/complaint-en and a secondary complaint form in Czech with the URL given by www.seller.com/complaint-cs, then if both forms offer mediation with maximum costs of up to 5EUR and 100CZK, respectively, and when minimum costs are not mentioned by the seller, the whole complaint form string will look like as follows:

“COM:-2:-1:-[en:- “1,1,*,5EUR,*:- “&&&www.seller.com/complaint-en&&&:-]:-2:-[cs:- “1,1,*,100CZK:-&&& www.seller.com/complaint-cs&&&:-]:-”

7 Feedback Form Information

This should be completely analogous to the complaint form with a different beginning string, “FEED:-”.
Furthermore, all the possible questions that determine the nature of a feedback form (if any) are non-mandatory and can be encrypted similarly as shown earlier.

8 Email to the Seller for Personalized Feedback/Customer Interaction and Possible Interaction Notifications

This will be encoded as “email=’EMAIL_ADRESS’:-”, where EMAIL_ADRESS gives the email address of the seller. Therefore, if the seller’s email address is info@buyme.com, then the code will be “email=’info@buyme.com’:-”.

9 Private Area of the CDC

CDC will also include private area which will enable to present specific information to certain users only.

9.1 Preliminaries

Beginning string: “PRIVAREADC:-”. This informs the app that it is reading a Private Area Door Code.

9.2 Provider’s Information in the Private Area

Provider’s information in the private area follows the syntax and elements of the rest of CDC and/or other rules agreed between the provider and CDC app producer.

10 End String of the CDC

End string: “QED:-”

11 Illustrative Example of the CDC Allowing to Send Information to Customer Account Only and Not Allowing Escalation to ODR

“INFO_PRIOR_TO_TRANS:-1111110:-ODRDC:-FEED:-0:-COM:-2:-1:-[en:-0,0,0,10EUR:- “&&&www.seller.com/complaint-en&&&:-]:-2:-[cs:-0,0,0,300CZK:-www.seller.com/ complaint-cs&&&:-]:-email=’ customerdoorcodes@seller.com’:-QED:-”

This CDC communicates that the seller provides detailed privacy notice that allows customers to refuse certain types of processing of their personal data which they don’t like, that the seller is also prepared to send his or her marketing and other information only to customers’ accounts if they wish so, and that the seller is also ready to not send any info to his or her customers who request so, but that the seller does not enable customers to escalate their issues to an independent third party for resolution.
Similarly, this seller has no feedback form but it offers two complaint forms. The preferred complaint form is an arbitration in English, which would cost the customer at most 10 euros, and the secondary option is an arbitration complaint form in Czech, which can cost as much as 300Kc to the customer. The minimum costs to the customer in both cases are zero. Furthermore, the preferred complaint form can be found at www.seller.com/complaint-en and the secondary complaint form can be found at www.seller.com/complaint-cs. The email to which any notifications or further feedback can be sent is customerdoorcodes@seller.com.

Note that this code ensures easy readability and since all elements are clearly labelled, error in transmitting the code is limited to a minimum. Finally, since none of this information is private but only works as a description of what is included on the seller’s webpages, special encryption of the code is not required.

12 Next Steps

The CDC is not limited to what is described above. CDC may include many different contents for different purposes. It is possible to describe all such different options of the CDC graphically as the following constellation:

The communication of internal nodes (I1-n) of “Me” with external nodes (E1-n) of “External Systems” can be in the form of either (i) presentation of information, e.g. that consumer ODR is available; or (ii) communication of information, e.g. about new products; or both.
Internal nodes describe internal set-up options of requests for or presentation of information or active messaging of the centre system (“Me”) and the external nodes describe the communication set-up of the External Systems. Active exchange of information (messaging) or passive communication (presentation of information) then run between the nodes according to the way the nodes are set.
It is possible to further break the three principal communication options (presentation of information, exchange of information or both) into a number of subsets. Regarding presentation of information, such subsets include e.g. (i) what info requests are included; (ii) what languages are available; or (iii) whether or not the CDC include a URL link etc. Regarding exchange of information, the subsets include e.g. (i) method of ID used; (ii) which external systems are to be interconnected with the center system (Me); (iii) statuses on external platforms which trigger exchange of information; etc.
Each subset might have several possible variants, e.g. various methods for an ID. Each variant can result into one or more screens of an application; each such screen contain few components which might also be described in a standard way.
This exercise will lead to preparing a documentation of an open source system for designing and developing personal communication tools which communicate on behalf of persons with external systems.