How to define attendance rules in Blip Desk

Index:

1. Introduction
2. How to define the rule?
3. Data source
4. Operator
5. Expected value
6. Target team
7. Practical examples of service rules
8. Teams for different cities
9. Teams for different subjects
10. Teams for different types of users

Introduction

A service rule defines how your bot directs human services among registered teams. Any member of a bot team who has write access to the Service module-can define the service rules for the teams.

How to define the rule?

To define a rule, go to the service module. On the left side menu, select the Service Rules option, as shown in the image below:

 

To add a rule, click the +Add rule button in the top right corner. A service rule is made up of:

Data source

Information that will be taken into account when defining the service rule. Possible sources are:

1. Targeted message content
2. Name of customer who requested service
3. E-mail of the customer who requested service
4. Extras of the customer who requested service

Operator

Comparison operator for the service rule. Possible operators are:

• Contains
• Does not contain
• Equals
• It is not the same

Expected value

Expected value for comparison with the data source using an operator. The expected value must be formed by alphanumeric characters.

Target team

Team of attendants who will receive assistance if the corresponding rule is true. Ensure that the desired target team has been created previously.

After defining all the service rules, whenever a user is sent to a human service block, Blip will analyze the rules and define which team should be responsible for providing the service. If there is no rule registered or no rules are met, the user will be sent to the Default team.

 

Practical examples of service rules

Check out some practical examples of attendance rules for different subjects;

 

Teams for different cities

Imagine an event company that has branches in several cities in Brazil. She needs customers to receive specialized and differentiated service, based on the city in which he is or would like to create an event.

Suppose that in this case, during the conversational flow, the user indicates the city for which he would like to receive assistance. This data was saved in the contact information, using the Extras field named City. Click here to learn more about saving data to contacts.

 

The rules will be defined as follows:

Source	Condition	Value	Team
contact.extras.City	Equal / Contains	Belo Horizonte	BH
contact.extras.City	Equal / Contains	São Paulo	SP
contact.extras.City	Equal / Contains	Rio de Janeiro	RJ

 

If the information contained in the City field is equal or contains any of the three cities (Belo Horizonte, São Paulo or Rio de Janeiro), the user will be directed to the team corresponding to that city.

Teams for different subjects

Imagine a large retail company that uses its customer service channel to support customers throughout their journey. During the creation of the conversational flow, the following subjects that could be attended to were identified: Complaints, Doubts, Ordering Information, Suggestions, and Feedbacks and Cancellation.

For this scenario, the source Message will be taken into account, which is the last message sent by the user before entering human assistance. For this, the company created a kind of menu with indicative numbers and text, to facilitate the user's choice.

 

In this way, the rules can be defined as follows:

Subject	Source	Condition	Value	Team
Claims	message	Contains	1. Claims	Claims
Doubts	message	Contains	2. Doubts	Doubts
Ordering information	message	Contains	3. Ordering information	Information
Suggestions and Feedback	message	Contains	4. Suggestions, Feedback	Feedback
Cancellation	message	Contains	5. Cancellation	Cancellation

 

If the last message sent by the user contains the subject number (or the subject, just in case), it will be directed to the team corresponding to the subject.

In the Blip portal, the rule will look like this:

Teams for different types of users

Imagine that an educational institution wants to have a smart contact to support its students, teachers and also interact and answer questions from people interested in the courses offered.

In this conversational flow, the institution identifies at the beginning of the interaction who is and who is not a registered student or teacher through authentication. This information is saved in the contact, more specifically in the extras field called Type.

 

The rules will be defined as follows:

Source	Condition	Value	Team
contact.extras.Type	Equal / Contains	Student	Students
contact.extras.Type	Equal / Contains	Teacher	Teachers
contact.extras.Type	Equal / Contains	Other	Default

 

If the information in the Type field is the same or contains any of the known types (Student and Teacher), the user will be directed to the corresponding team. If he is interested, the type will be given as Other, and he will be directed to the Default team.

 

On the Blip portal, the rules would look like this:

For more information, visit the discussion on the subject in our community or the videos on our channel. 😊