Assistant Building

Click on any live support node in the assistant builder to edit it and access its settings.

Name

The name displayed on the node within the canvas. Not shown to end users.

Allow audio/video calling

This checkbox controls whether support agents can initiate voice or video calls to the end user during live chat. To disallow these calls, uncheck the box.

Default: checked, meaning support agents can initiate calls.

Auto-assign conversations to available agents

This checkbox controls whether incoming chat requests are placed into a queue to be claimed manually or are automatically assigned to available agents.

Default: unchecked, meaning incoming chat requests enter a queue and need to be claimed manually.

Agent group

Which agent groups will receive the live chat requests from this live support node.

Default: "All", the default agent group which contains all team members with the "use agent dashboard" permission

Resolution options

What resolution options will be available to to the support agent when ending a live chat.

By default, only one resolution option is available: "Resolved". Options can be added, renamed, reordered, or deleted, though there must always be at least one. Each option corresponds to an outcome of the live support node and has its own connector.

If there is only one resolution option, when an agent ends a chat the conversation will continue along the flow following that resolution option's connector.

If there are multiple resolution options, when an agent ends a chat they will be prompted to choose one of the options. The conversation will continue along the flow following the connector of the chosen option. This allows you to create multiple different paths for users depending on the outcome of the live chat. For example, you may add a "Warranty Claim" resolution option that takes users to a form to fill out to submit a warranty claim after the agent has verified that the claim is justified.

Each resolution option has a few other settings.

Default: A single option named "Resolved".

Resolution name

The name of the resolution option. This is only displayed on the node within the canvas and in the list of resolution options for the agent to choose from. Not shown to end users.

Make outcome selection optional

This checkbox controls whether agents are required to select one or more outcome topics during debrief after closing a chat with this resolution option.

Default: Unchecked, meaning agents are required to select outcome topics for chats with this resolution.

Outcome topics

A list of topics associated with this resolution option. Agents can select one or more during debrief after closing a chat with this resolution option. These are applied to the conversation within your analytics. Not shown to end users.

Default: None, which means agents will only have the special "Other" topic available for selection during debrief.

End user title

What label to use for the customer when viewing chats in the agent dashboard. Not shown to end users.

By default, chats are labeled with the conversation's hexadecimal ID in the agent dashboard. However, you might have the customer's name or email available in form data. If so, you can use markup to reference that data here. For example, if you have the customer's name associated with the form data key customer-name, you can set an end user title of "{{customer-name}}". Then chats will be labeled with the customer's name in the agent dashboard, making it easier to keep track of which chat is with which customer.

Default: None, meaning the conversation's hexadecimal ID will be used to label the chat.

Emails to be used instead of agent emails

This setting is deprecated and exists only for backward compatibility. Instead, use agent group settings.

SMS notification receivers

This setting is deprecated and exists only for backward compatibility. Instead, use agent group settings.

Offer customer to leave

These settings allow users to cancel a live chat request if they are waiting too long for an agent to join. If the user does cancel, the flow will follow the live support node's "Customer skipped" exit.

Waiting time before offering to leave

How long in seconds the assistant should wait before offering the user the option to cancel the live chat request.

Default: 60, meaning that if no agent joins the chat after one minute in the live support queue, users will be offered the ability to cancel the chat request.

Message

What text to display to the user when offering the ability to cancel the live chat request.

Default: "Sorry to keep you waiting. No agent seems to be available right now. You can continue to wait, or leave the chat to see other alternatives."

Button label

What text to display on the button that cancels the live chat request.

Default: "Leave chat"

Max concurrent conversations per agent

How many live chat chats a support agent can simultaneously handle.

This setting allows you to define how many chats your support team can take at once. This is useful so that if more chat requests come in than your team can cover, your team isn't overwhelmed and users aren't kept waiting.

If there are too many active or queued chats for the number of available agents in this node's specified agent group already, new chat requests from this node will not enter the live support queue. Instead, they will follow the node's "No agent capacity" exit.

The exception is conversations that were created via a conversation link. These chat requests will always enter the queue as long as there are any active agents in the relevant agent group. If there are no active agents, then even these conversations will follow the "No agent capacity" exit.

Default: Unlimited, meaning all chat requests will be allowed to enter the live support queue regardless of how many are active.

Max additional conversations per agent when their capacity is reached.

How many live chat chat requests may be queued up to wait for an available agent while all agents are at capacity.

For example, suppose "Max concurrent conversations per agent" is set to "2", your team has three active agents, and all three agents currently have two active chats. If a new chat request comes in at this point, what happens to it depends on this setting. If it is set to "0", the conversation will follow the "No agent capacity" exit. If it is set to "1", the chat request will enter the queue. Once an agent closes one of their active conversations or a new agent signs on, if the "Auto-assign conversations to available agents" box is checked, the chat will then be automatically assigned to that agent.

If all agents are at capacity, once the number of queued chat requests is equal to or greater than this setting multiplied by the number of active agents, any further chat requests will result in their conversations following the "No agent capacity" exit.

Default: 0, meaning that when all agents are at capacity any new chat requests will follow the "No agent capacity" exit instead of entering the queue.

Always allow chats to enter the queue (not recommended)

This setting is for testing purposes only. We strongly recommend leaving the box unchecked on live flows.

When checked, any live chat requests from this node will ignore the "Max concurrent conversations per agent" setting and enter the live support queue even if there are zero agents online.

This can easily result in situations where end users are kept waiting for agents who will never come, so we recommend using it only for testing purposes and never on a live flow. Leave it unchecked when you are not using it for testing.

Default: Unchecked, meaning that chat requests from this node will enter the live support queue or will follow the "No agent capacity" exit depending on current agent capacity.

Time (hours) until automatically closing conversations

How long a chat can remain open and inactive.

If a chat request remains in the queue for the specified amount of time without being joined by an agent, the chat will be automatically closed. The conversation will then follow the node's "Agent timeout" exit. This prevents chats that are assigned to agents who are not actually available from sticking around on the dashboard or blocking the end user indefinitely.

If a chat is joined by an agent and then goes the specified amount of time with no messages from either the end user or the agent, the chat will be automatically closed. The conversation will then follow the node's "Inactivity timeout" exit. This prevents old completed chats from sticking around on the agent dashboard even if the agent neglects to close them before going offline.

Default: 24, meaning that any chat that is inactive for a full day will be automatically closed.

Custom Image

What image to display to users while they wait for an agent to join their live chat.

If you do not set one, a default one is used.

Default: none, meaning your users will see the default drawing of a person wearing a headset:

Built-in node exits

In addition to the editable resolution options, there are several built-in node exits. Their behavior is configurable through the above settings.

1. The "Declined" outcome occurs if an agent declines the user's live chat. This can be done to clear out spam or chats that were started in error.

2. The "Inactivity timeout" outcome occurs if the chat goes too long with no messages on either side. By default, the wait time is 24 hours.

3. The "Customer skipped" outcome occurs if the user cancels the live support request. By default, the user is able to do this if the conversation waits in the queue for one minute without being joined by a support agent.

4. The "No agent capacity" outcome occurs if there are no available agents who are allowed to take more conversations. By default, this will not happen.

5. The "Agent timeout" outcome occurs if the chat waits in the queue too long without being joined by an agent. By default, the wait time is 24 hours.