This article gives you an overview of what Conditional Blocks are and how to set it up with examples.

What are Conditional Blocks?

Conditional Blocks are the way to personalize messages in your dialogue flows based on a certain condition, or in this case, a parameter. How it works is that we set a parameter to be checked, as well as conditions that check for one or more parameter values based on the selected operator.

Example

In the example above, we are sending different messages to customers based on their location.

To set this up:

Add "Get Visitor Info" action in Settings > Actions, in Ultimate's Dashboard.
Add a conditional block in the dialogue flow of the intent of your choice and enter the parameter you want to use. We are using Country in this example.
Create different conditional paths by adding conditions. In the example above we have Germany and Japan as the conditions using operator Is, and a fallback path using operator Else.
- You can also add another condition right after the other to check for other parameters to make your messages more sophisticated. For example device type.

❗ Note that the system checks the conditions from left to right - just like other parts of our Dialogue Builder. This is why the fallback condition, or the broadest condition you have, should always be on the furthest right.

Parameters

Parameters can come from three sources:

CRM platform
Session data
Backend integration

Types of parameters accepted in conditional blocks

Strings - words
Boolean - true/false
Array/list - comma-separated list
Integers - a whole number
Floats - a decimal number

CRM platform

CRM platforms typically store chat visitor information such as name, email, location, etc. This information can be fetched from your CRM platform and saved as parameters to use for Conditional Blocks.

To fetch the information from your CRM platform, add an action to get visitor information on the Chat Started event. This means the information will be collected for every new conversation and applied to all dialogues in your bot.

Session data

Session data refers to the information chat visitors offer during a chat session with the Virtual Agent. At almost every point in any dialogue flow, as well as any reply, you can create custom actions to fetch session data and save it as a parameter.

Content Entities are considered session data params as well and the name of each content entity is a parameter. Any data captured via content entities is stored as session data until two hours after chat inactivity.

Backend integration

This means if you have custom API integration built with us, the bot can fetch any information from your back office system to create personalized dialogues flow based on your needs.

To learn more, get in touch with your Customer Success Manager or submit a request.

Operators

Operator	Definition	Example	Expected Parameter Value	Condition Value
`is / is not`	Use this for single values	`Country` `is` `Germany`	string	string
`is / is not (boolean)`	Use this for true or false statements	`loggedIn` `is` `True`	boolean	boolean
`in / not in`	This acts as an OR condition. Use this for multiple values, separated by a comma	`Country` `in` `Germany, Japan, Finland`	string	array
`includes / doesn't include`	Use this for list of values. It will expect an array in the session, and a single value in the condition.	`tags_Array` `includes` `VIP`	array	string
`exists` `does not exist`	Use this to check if a parameter is present in the session This is triggered when the value expected for the parameter is empty	`Email` `Exists` `country: ''` , `null` or completely undefined.	anything	N/A
`starts with / doesn't start with`	Use this for single string values	`Country` `starts with` `united`	string	string
`Greater than` `Greater than or equal` `Less than` `Less than or equal`	This works with all number types (integers & floats) with content recognition and actions. Differentiate whether a value exceeds a set value Differentiate whether a value exceeds or is equal to a set value Differentiate whether a value is fewer than a set value Differentiate whether a value is fewer or equal to a set value	`Number` `Less than or equal` `9`	integer or float	integer or float
`Else`	The fallback. This should always be added as the last condition		anything	N/A

Parameter values

Each parameter can carry none, one or more values. Meaning for parameter Country, the values could be:

None - , null
One - Germany
Many - Germany, Japan, Finland

It's important to understand what are the possible scenarios when outlining the conditional blocks, especially if you are using API-returned values.

Best Practice Examples

Avoid Loops

Loops are usually not helpful, as if a customer has been through a path once, they likely need more information in order to be successful in the request that is being asked of them or get the answer they need.

This helps personalize the customer experience to achieve the best result. You may wish to avoid the same conversation loop and help customers get to a set destination faster, for example, if they ask to speak to an agent. The first time they try to force the intent to speak to a human - you may want to say why they should give the bot a chance, but once they have passed that they can trigger it again and not have that same response.

Screenshot_2022-08-12_at_13.54.37.png

Content Entity Lists

In case you prefer not to/can't use buttons conditional blocks are great to use for different use cases such as contact methods where you are unlikely to train a specific Intent. By using lists you can segment information and then take users down a more specific/personalized path.

Personalize on Customer Type/Value

Depending on the type of customer that is contacting there may be different procedures or policies, such as merchant vs premium or new customers. Therefore, by pulling this information you can provide a more accurate and appropriate experience based on customer lifetime value or business relationship.

API Integration Value Personalization

Further personalize bot responses based on customer-specific information returned which can be pretty much everything, depending on the use-case, API, and information available to us. Such as; Parcel Status is “Shipped” + Courier is “DHL” + Shipping Mode is “Express”

Firstly, here you can provide more accurate information to the user, but also in the example of express shipping if you just return the value of shipped, you might provide a generic response like "please allow 2-5 days for your order to reach you" that could end up causing customer dissatisfaction when they are either a premium customer that gets it as part of a loyalty scheme or they personally paid for 1-day delivery.