Index:
- Introduction
- How to define the rule?
- Data source
- Operator
- Expected value
- Target team
- Practical examples of service rules
- Teams for different cities
- Teams for different subjects
- 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:
- Targeted message content
- Name of customer who requested service
- E-mail of the customer who requested service
- 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. 😊