Click on any live support node in the assistant builder to edit it and access its settings.
The name displayed on the node within the canvas. Not shown to end users.
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.
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.
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".
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.
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.
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.
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.
This setting is deprecated and exists only for backward compatibility. Instead, use agent group settings.
This setting is deprecated and exists only for backward compatibility. Instead, use agent group settings.
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.
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.
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."
What text to display on the button that cancels the live chat request.
Default: "Leave chat"
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.
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.
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.
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.
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: