Customer Uniqueness Documentation

——By setting the category and order of IDs that participate in customer uniqueness judgment, the ID problem of the same customer entering from different channels can be solved.

Overview

● ID of Channels

A customer has different IDs representing unique physical users in different channels, such as email addresses, WeChat OpenIDs and UnionIDs, user login accounts, etc. These are collectively referred to as IDs.

Identification	Usage Scenario
Docking ID	If you want Sobot to identify customers according to the existing rules of your CRM and other systems, you can synchronize your own unique ID to partnerid.
Phone no.	Universal attributes that can connect different channel IDs
Email	Universal attributes that can connect different channel IDs
WeChat UnionID	This ID can be used if you have docked multiple applications such as WeChat ecological official account and mini program. For instructions on UnionID, please refer to the official documentation (opens new window)
External contact ID of WeCom ID	If you use WeCom for customer reception or operation, you can use this ID. For instructions on the external contact ID of WeCom, please refer to the official documentation (opens new window)
WeChat OpenID	This ID can be used if you have docked a single official account or mini program or the application cannot bind to the open platform. For instructions on WeChat OpenID, please refer to the official documentation (opens new window)
Facebook	This ID can be used if you have docked Facebook.
Instagram	This ID can be used if you have docked Instagram.
WhatsApp	This ID can be used if you have docked WhatsApp.This ID is the customer's mobile No. After obtaining the user WhatsAppID, Sobot will also place this field on the user's mobile No.
Line	This ID can be used if you have docked Line.
Telegram	This ID can be used if you have docked Telegram.
Discord	This ID can be used if you have docked Discord.

● Priority

When an unknown user has multiple IDs and generates behaviors such as chats, tickets, and talks, priority is required to determine which customer the behavior belongs to.

Scenario example: Assuming mobile No. > email

Step 1: When a customer makes an inquiry through mobile No. 18888888888, it is saved as customer userid1;

Step 2: When a customer sends an email at sobot@sobot.com and generates a ticket, it is saved as customer userid2;

Step 3: A customer submits a ticket through a desktop site submission, leaving mobile No. 18888888888 and email address sobot@sobot.com.

As the priority of the mobile No. is higher than the email address, the ticket will belong to the customer's userid1, and the sobot@sobot.com will also be updated to the user's userid1;

Event Table:

Steps	Mobile No.	Email	Result
1	18888888888		Generate the customer's userid1
2		sobot@sobot.com	Generate the customer's userid2
3	18888888888	sobot@sobot.com	userid1 is added with email sobot@sobot.com

Final Result Table of User:

userid	Mobile No.	Email
1	18888888888	sobot@sobot.com
2		sobot@sobot.com

How to Use

● Function Configuration

1、Select the ID participating in unique ID of customers, as shown in the figure:

Figure 1：Select ID

2、Determine the priority of each ID, as shown in the figure:

Figure 2：Order priority

3、It will take effect after 2 minutes of saving, as shown in the figure:

Figure 3：Remain Valid

● Scenario examples

Assuming the customer's unique ID rule is docking ID > email > mobile No. ● Class I scenario, customer matching scenario with visual operation interface Manually creating and editing customers in CRM belongs to this class of scenario. The operator can select to merge or associate a specific customer through the page when there is a conflict between the customer's ID and existing customers.

Step 1: Create a customer with email sobot@sobot.com. After successfully creating, generated the customer's userid1;

Step 2: Create a customer with mobile No. 18888888888. After successfully creating, generate the customer's userid2;

Step 3: Create a customer with email zhichi@sobot.com and mobile No. 18888888888. After successfully creating, generate the customer's userid3;

The priority of email is higher than that of mobile No., so email is preferred for retrieval. No known customers are retrieved at zhichi@sobot.com, so they can be successfully created;

Step 4: Create a customer with email sobot@sobot.com and mobile No. 18888888888. Failed;

1）The priority of email is higher than that of mobile No., so email is preferred for retrieval. The sobot@sobot.com already exists in the customer's userid1;

2）Then, retrieve a customer with an empty email and mobile No. 18888888888. The userid2 will also be retrieved;

3）The final operation is, creation failed, prompting the need to merge customers with userid1 and userid2;

4）When merging customers, if you choose to keep userid1, userid2 will be deleted and the mobile No. 18888888888 will be updated to userid1.

Event Table:

Steps	Mobile No.	Email	Result
1		sobot@sobot.com	Generate the customer's userid1
2	18888888888		Generate the customer's userid2
3	18888888888	zhichi@sobot.com	Generate the customer's userid3
4	18888888888	sobot@sobot.com	Keep userid1 and add a new mobile No. 18888888888

Final Result Table of User:

userid	Mobile No.	Email
1	18888888888	sobot@sobot.com
2	18888888888
3	zhichi@sobot.com	18888888888

● Class II scenario, customer matching scenario without visual operation interface

Class II scenarios include: email generates a ticket, visitor makes an inquiry and automatically generates a customer, and Excel imports customers in bulk. When there is a conflict between the customer ID and existing customers, manual intervention is not possible, and the system can only select one of the customers as the customer for this record.

Step 1: A customer generates a ticket at sobot@sobot.com, and will create a customer to generate the customer's userid1;

Step 2: A customer makes an inquiry through mobile No. 18888888888. Agent creates a customer to generate the customer's userid2;

Step 3: The customer makes an inquiry through the APP and brings ID with docking ID wubnwYTB234, email sobot@sobot.com and mobile No. 19999999999. The system creates a customer automatically to generate the customer's userid3;

The priority of the docking ID is higher than that of the email and mobile No., and no known customers are retrieved through the docking ID, so it can be successfully created.

Step 4: The customer generates a ticket via email sobot@sobot.com again, which will be associated with the customer's userid1;

The userid1 and userid2 are retrieved via sobot@sobot.com, but the ticket can only be associated with one customer. The system prioritizes customers with earlier creation times, so they are associated with userid1;

Step 5: The customer makes an inquiry through the APP and brings ID with email sobot@sobot.com and mobile No. 18888888888. The chat record will be associated with userid1; The priority of the email is higher than that of the mobile No., so the higher priority will be taken.

Event Table:

Steps	Docking ID	Mobile No.	Email	Result
1			sobot@sobot.com	Generate the customer's userid1
2		18888888888		Generate the customer's userid2
3	wubnwYTB234	19999999999	sobot@sobot.com	Generate the customer's userid3
4			sobot@sobot.com	Associate with the customer's userid1
5		18888888888	sobot@sobot.com	Associate with the customer's userid1

Final Result Table of User:

userid	Docking ID	Mobile No.	Email
1			sobot@sobot.com
2		18888888888
3	wubnwYTB234	19999999999	sobot@sobot.com

Special Note

1）This rule is only applicable to the latest version of Sobot system (only the old version exists in Chinese Mainland);

2）For enterprises registered after October 26, 2023, there will only be the latest setting rules;

3）After setting this rule, it will be applied to all product lines of the Sobot system;

4）After setting or updating the rule, only data after that time point will be executed according to the rule, and historical data will not be cleaned again.