Modules are the main building blocks when you design your chatbot’s conversation flow. There are two different types of modules: collector modules and statement modules. We will give you a short definition of collector modules in this article.
This smart type of bot response can be created by either right-clicking your mouse and selecting Collector module or by going to the right sidebar menu.
Collector modules are great tools if you need to check or verify the end user's input. Often, collector modules are used to ask the end user for a certain type of information such as their email, order number, or telephone number. Once the end user has provided the requested information, the bot validates whether the user input matches the format selected.
Bot Error Messages of Collector Modules
Bot Error Messages of Collector Modules are an important feature to collect the required information in a human-like manner. Assuming that the end user´s input cannot be verified, the bot can ask the end user again for the required information.
If the end user still does not provide the required information, the second Bot Error Message, as defined by you, will be shown. You can insert as many Bot Error Messages as you think would be adequate in order to simulate a human conversational flow.
It is important to note that the Bot Error Message(s) will be shown in all Collector Modules you are using. Customize the Bot Error Message(s) for each module by ticking the checkbox for each message accordingly.
Types of Collector Modules
You can set up the Collector Module in accordance with the information to be requested from the user. Read more about Multiple Choice Modules, Email Modules, URL Modules, Number Modules, Phone Number Module, and Date & Time Module in the following section.
Multiple Choice Module
Multiple-choice and statement modules are very similar, as both modules can accept freely written text from a user and both of them can have clickable answer options. Generally speaking, Multiple Choice Modules can be considered as traditional bot messages, since these follow a keyword-based logic.
Small differences compared to Statement Modules
The difference between Statement Modules and Multiple Choice Modules is that Multiple Choice Modules have the Bot Error Messages feature built-in. This means, if the end user sends information that cannot be understood by the bot, a predefined error message will be sent.
It is important to note that using Multiple Choice Modules, the conversation cannot continue without any end user input, which is possible when using statement modules.
How to set up a Multiple Choice Module
Using Multiple Choice Modules, a certain type of end user input needs to be verified. This can be done by either adding Suggested replies or Connection options. If the end user's input does not match the Suggested replies or Connection options, the bot error message will be shown, or if no error message is defined, a fallback message is shown.
The difference between Suggested replies and the Connection option is that Suggested Replies are persistent.
The use case for Multiple Choice Modules
The most frequent use case for Multiple Choice Modules is if you require a predefined end user input in order to continue the conversational flow. In a very simplified example, if a bot only consists of conversational flows for product recommendations, product clarifications, and product suggestions, it is necessary to know which of the three options the end user would like to learn more about. The end user has simply no other option to choose from. Thus, if the end user would not click on any of the suggested responses as illustrated below, the conversation would end very quickly.
Please take a look at this example.
The Email Module is especially helpful if you would like to create leads during your conversational flows. You can use it to verify the email address of an end user, which is extremely useful if the email address is the only contact detail you are collecting from your visitor.
Difference between verify and collecting of the email address
Using the Email Module, the email address will not be collected automatically. As described above, it is a tool to check the format of the email provided by the end user. If you would like to store the email address, go to the Connections tab of that Module and set a Custom Variable as for example User_email.
Read more about Custom Variables in our article Storing the end user reply in a Custom Variable.
This example can help you to understand the setup of Email modules.
URL Modules are very helpful to refer to for example support tickets on other platforms. As with all Collector Modules, the main benefit lies in checking the format of the end user input in other words if the end user indeed provided an URL.
In many use cases, number rows serve as a unique identifier to understand the customer case better. A Number Module supports you in verifying unique, number-based IDs such as an order number so that you can ensure a valuable service experience for your customers. As previously explained in the section on the Email Module, the Number Module does not store any information automatically, but only verifies whether the user input is comprised of numbers.
Read more about how to store number rows in Storing the end user reply in a Custom Variable.
Additionally, you can define how many numbers the row must contain. You can do so by typing in the desired restriction in the text box Number length.
Take a look at this example. Here the user can only respond with a number row consisting of exactly ten numbers.
Phone Number Module
The Phone Number Module has a comparable setup to the Number Module. It reads the end user information and checks if the format provided by the users matches the format of a phone number. Again, the phone number will not be stored automatically when applying a Phone Number Module. Go to the Connections tab of that Module and set a Custom Variable as for example User_phone.
Read more about how to store phone numbers in Storing the end user reply in a Custom Variable.
We recommend you to specify the date and time format required from the end user.
The example question could be edited as follows: "When would you like to book a table at our restaurant? Please write the date (dd-mm-yyyy) and time (hh:mm am/pm)."