Behaviors

The following behaviors are specific to customer assistants.

Assigned

Assigned is a special behavior that executes when a conversation is first assigned to an assistant. This marks the beginning of the assistant's session with that conversation. Flow typically doesn't return to the Assigned behavior during the same session (although it's possible to configure it to do this if you wish).

The assigned behavior has a single rule handler where you can configure visual rules and actions, including a required location change to the next behavior in the flow:

If a conversation is unassigned from an assistant (e.g. escalated to a live agent) but is later reassigned to the assistant, this marks the beginning of a new session that will start from the Assigned behavior again.

Send Message

The Send Message behavior enables you to send a message to the customer and optionally wait for a customer response.

The Send Message behavior can actually send multiple messages and even execute other action types. Its defining trait is it's ability to block for a customer response. Messages have full access to Quiq's multi-channel Rich Messaging Support support:

The text of the message can include references to various variables, including session fields. This is very useful if you want to send content generated by an LLM through a visually configured message instead of a programmatically generated one. Use a setField action to set the text you wish to send to a session field, then reference it as a variable in your message text:

It's also possible to send standard messages defined in the Message Catalog.

When to use the Send Message Behavior

You've probably noticed that there are several ways to send messages from a customer assistant:

From the Send Message behavior
From a visual Send Message action available on many behaviors
From a programmatically generated Send Message action

The choice to use the Send Message behavior comes down to wanting to block for a customer response or wanting to elevate the important of a message onto the top-level flow graph.

Set Timer

The Set Timer behavior enables your assistant to perform a timed wait for a customer message and behave differently when the customer responds first vs. when the timer expires:

If the customer responds before the timer expires, the 'When the user responds' handler will execute. Otherwise, the 'When the timer expires' handler will execute. Along with Send Message and Call API behaviors, Set Timer behaviors are another way to block on user input (i.e. enter a state of rest).

Example use cases:

Waiting several minutes after answering a question to ask the user if it was helpful or not
Trying to keep a high-value prospect engaged in the conversation

Route

The Route behavior enables an assistant to escalate a conversation to another assistant or a live agent queue.

The Route behavior has three modalities:

Mode	Description
Re-Queue	Send the conversation to another queue (typically staffed by live agents)
Return to Sender	Send the conversation back to wherever it was prior to getting assigned to the assistant. This is helpful for 'backend' assistants like post-conversation survey assistants as opposed to assistants that are a customer's first point of contact
Transfer	Transfers the conversation to another assistant. For example, your business may have a general assistant that determines the customer's issue and then routes to an assistant specialized for handling that type of issue

The Route behavior clearly demonstrates the seamless integration between assistants and your contact center. When a conversation is escalated or transferred it is completely seamless to the user. All conversation and customer data is preserved because it's all the same conversation record passing through the system.

If you require complex routing logic to decide the routing target, a common pattern is to place an Execute Logic behavior in front of numerous route behaviors. It's even possible to reflect on current staffing levels when making escalation decisions:

Close

The close behavior closes conversations - either immediately or with a delay.

Mode	Description
Immediate	The conversation will be closed immediately upon reaching the behavior. Customer-scoped data obtained during the session will be propagated to any subsequent conversation, but conversation-scoped data is reset. If the customer returns, the assistant will start over at the Assigned behavior
Delayed	The conversation will be flagged as Inactive and automatically closed after the configured Close Time elapses. If a customer responds during this time, the current conversation will continue and Conversation-scoped data will be maintained. The delayed close requires a Change location action be configured in order to determine how the conversation should be handled if the customer responds

Note that the Close behavior is not the only way conversations can close while assigned to your assistant. Quiq's normal inactivity and close timers apply to assistants, just like they do to live agents. For example, if you ask the customer a question but they don't respond, the conversation will be automatically inactivated and then automatically closed according to your system timer configuration. This is colloquially referred to as dropoff. You don't need to explicitly handle it in your assistant flows. Use the close behavior when you have reason to believe the conversation is over.

Classic Design Elements

Customer assistants have full access to Quiq's classic bot design elements including NLU-based intent matching and entity extraction, as well as several behavior types that make it easy to create menu-driven bots and/or fill out forms.

Determine Intent: easily create menu trees with optional NLU-based matching
Gather Data: prompt the customer to answer questions and bind the data back to fields
Collect Data: Use NLU to collect data entities from the customer
Classic Special Events