A chat bot’s primary goal is to determine a human’s intent (what they want to accomplish) from their utterances in natural language, and then to fulfill those requests in a helpful way.
Interactions are short conversations between a chat bot and a human user with a specific intent. They help avoid the challenges introduced by open-ended conversations.
Interactions are triggered from interaction points, which provide context (e.g. who, what, when, where) and establish the initial intent of a conversation.
In Cerb, an interaction could trigger when a worker clicks “Remind me” on a specific record. Through the interaction, the bot would know who the worker is and which record they’re looking at, so it could simply ask when and how they would like to be reminded. The bot also has access to the worker’s record, so it wouldn’t need to ask about contact details like an email address or mobile number.
On a website, an interaction could trigger when a visitor clicks a “Sign up” link. The bot would guide the visitor through the steps of creating and verifying a new account.
There are three events in the lifecycle of an interaction: get interactions, handle interaction, and conversations.
When a user is near an interaction point, the Get interactions event runs on every bot to fetch the list of available interactions for that point. This allows the user to choose an interaction directly, rather than having to precisely answer the open-ended question, “How can I help?”.
For instance, certain interactions may only be available for open ticket records in the Sales group.
When a specific interaction from the above list is selected, Cerb runs its associated handler.
A single handler behavior can be shared by multiple interactions. The common convention is to have one “Get interactions” and one “Handle interaction” behavior per bot.
The handler takes parameters from the interaction and passes them to a conversational behavior.
If an interaction is being started from a link in email, a signature may be verified to detect tampering, etc.
With customer-facing bots on websites, the get interactions step is skipped and the handler is called directly when a link or button is clicked.
The conversational behavior then starts, with its initial state provided by the interaction. It prompts the user for input, does something useful, and provides output. This process may repeat as many times as needed to achieve the desired outcome.
For instance, imagine a troubleshooter that has a user try multiple solutions to uncover a root cause. In some situations it may find a common issue right away, and in others it may need to ask many follow-up questions to identify an uncommon issue.
Conversational behaviors aren’t inherently associated with a specific record type. That means you can reuse the same conversational behavior for multiple interactions and adapt it to different record types.
Consider a “Remind me” interaction. With interactions, you can register a single “Remind me about this” interaction on every record at the same time (with interaction point
record:*), which uses the same handler, and the same conversational behavior.
The ability to use wildcards like this is another reason why the handler step exists, rather than directly linking interactions to conversational behaviors.