Docs »

Bots »



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.

Interaction points

Interactions are triggered from interaction points, which provide context (e.g. who, what, when, where) and establish the initial intent of a conversation.

For instance:

  • 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.

  • In an email, a personalized link could start an interaction with survey. The conversation would adapt based on a respondent’s answers, and results could be saved to custom fields or custom records.

Interaction lifecycle

There are three events in the lifecycle of an interaction: get interactions, handle interaction, and conversations.

Get interactions

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?”.

Because this process is implemented using bot behaviors, decisions can filter the possible interactions situationally based on the current worker, the target record, the time of day, etc.

For instance, certain interactions may only be available for open ticket records in the Sales group.

These options are generally displayed in an interactions menu on a record’s card or profile.

Handle interaction

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.