What is Live Agent Message Brokering?

Live Agent Message Brokering (or Message Brokering for short) is a variant of the Moveworks Live Agent handoff skill, which connects users to agents upon request. While most live agent handoffs redirects the user to a browser or another bot before starting the conversation between the user and the agent there, Live Agent Message Brokering connects users to agents in the same chat as the bot for the most popular systems that can support it (ServiceNow, Amazon Connect, etc.).

This approach is generally easy to set up and works for numerous systems, however, there are advantages to keeping users in the same chat as the bot.

1. Pulling agents directly into the chat is the most seamless handoff experience possible.
2. It reinforces the idea that the Moveworks bot is the destination for all kinds of support, including getting connected to agents.

This experience is not only seamless for users of the bot, but also seamless for the agents as well. They need not learn any new tools or interfaces, they simply work in the same place and manner that they always do, and it will feel just like a user has opened up a chat natively with them.

Live Agent Chat Platform Support

• ServiceNow Agent Chat (Advanced Work Assignment + Agent Workspace or Service Operations Workspace)
  • Prerequisite: Access to the “Virtual Agent API” plugin—most commonly available to organizations that have purchased a ServiceNow ITSM Pro license
  • Limitations:
    • When agents type knowledge article or ticket numbers into their chat, they’ll usually see them unfurl into detailed summaries. These details are not sent to Moveworks via API, so this unfurling is not replicated on the Moveworks user side (the KB article or ticket number will simply be sent as a string).
• Amazon Connect
• 8x8

Chat Platform Support

• Moveworks for Web
  • ✅ Fully supported
• Microsoft Teams
  • ✅ Fully supported
• Slack
  • ☑️ Mostly supported
  • Limitations:
    • Attachments not currently supported

The experience

There are three phases to the Message Brokering experience: starting the chat, chatting, and ending the chat.

Starting the chat

How does a user connect to an agent?

To connect to a live agent, a user can ask the bot directly (e.g. “I’d like to speak with an agent.”) and a “Start agent chat” button will be offered or the button can be presented as an alternative to self-serve options. You can see examples of this below, though your exact flows may vary based on your deployment configurations and the probabilistic nature of AI.

Prompt the user for more details

When the user clicks the “Start agent chat button,” if the user asked to speak to an agent without first asking a specific question to the bot, then prior to enqueuing the user, the bot will ask for more details that it can pass to the agent with sufficient context about the request or issue the user is having.

Dynamically control the visibility of the “Start agent chat” button

The “Start agent chat” button can be configured to be dynamically shown or suppressed to meet the needs of your organization using the currently supported options:

• Check external system for agent availability
  • Generally Available in ServiceNow -The bot checks the Agent Presence & Capacity Dashboard (aka the awa_agent_presence_capacity database view) and only displays the button if one or more agents’ Available property is set to true.
• Check a rule defined within Moveworks
  • In Limited Preview - The bot checks a rule configured on the Moveworks side. For example, “only show the button from 8am-5pm PT,” which are your agents’ business hours.
• Always show the button
  • In Limited Preview - The bot never dynamically hides the button when it would otherwise appear.

Dynamic queue routing

Moveworks does not maintain queuing logic. Queues are defined and controlled in the external live agent chat system. However, when Moveworks attempts to connect to the external system, it can pass along additional key value pairs of context variable data that your live agent chat system may be able to use to route the user appropriately.

For example, if you maintain two queues, one for French speakers and one for English speakers, Moveworks can pass that context as something like language: french and your system may be able to be configured to parse that and route the user to the French queue.

Moveworks supports several common context variables out of the box, such as domain, language, and region. Custom keys can also be configured. Work with your Moveworks CSE if you have additional requirements.

Getting connected (from the user’s perspective)

Assuming agents are available, upon clicking the “Start agent chat” button the following occurs:

1. The user is placed into a queue in the external system and asked to wait for an agent to accept the request.
   • Note: In this state, the user can still make full use of the bot; they are not blocked from doing anything. The waiting is done in the background.
2. Once an agent accepts the chat request, the chat session has begun and the Moveworks bot is no longer participating in the conversation, with a few exceptions (documented in the Bot interactions during the live agent chat session section above).
3. System messages are passed to the user from the external system, including any automated greetings you’ve configured to be on behalf of the agent, and then both the user and agent are free to converse.

Getting connected (from the agent’s perspective)

This will vary system by system, but typically an agent will receive a notification of an inbound chat request that can be accepted or rejected.

The chat request’s title will be set to the main utterance the user used in starting the agent chat.

Upon accepting the chat request:

• The chat session will begin
• The chat request will be attributed to the Moveworks user (if supported by the external system)
• System messages will be delivered
• By default, the agent will receive the last 6 messages, including messages from both the user, and the Copilot. (chat history can be disabled if desired).

Message Types

• Moveworks messages will be displayed without any agent attribution.
• External system messages will be displayed without any agent attribution.
• External system messages sent on behalf of agents (e.g. automated standard greetings) will be attributed to the agent that accepts the chat request.
• Agent messages will be attributed to the agent that sent them.

Agent Attribution

Each message will contain the name of the agent, pulled from that agent’s profile in the external system. In the case pictured here, the agent’s first and last name is “Moveworks IT” as defined in his ServiceNow user profile. The agent’s image can also be pulled from the external system and displayed to the user. However, this is optional and can be disabled. You may choose to disable this for anonymity purposes, because you do not have agent pictures, or because the images are not accessible to Moveworks via API (e.g. hosted behind a company VPN).

Queue Timeouts

Moveworks supports queue wait timeouts from the external live agent chat system in addition to maintaining one itself.

• Each external system will have its own way of defining a timeout period and relaying that event to Moveworks.
• Moveworks queue wait timeout period is 2 minutes.
  • The user is not blocked from doing anything with the bot while waiting in queue, so this timeout period is intended to be long enough to accommodate most timeouts an organization might reasonably define in its external system. This timeout is simply a fallback.

Chatting

Sending messages

Users and agents can send text messages, including standard emojis, back and forth.

📘

Note on emojis: Some chat systems, like Microsoft Teams, make use of nonstandard or custom emojis. These will be stripped from the message sent to the user.

Attachments

Sending and receiving file attachments is supported to varying degrees depending on the live agent chat system and the user chat platform. The following is a summary of capabilities by system:

Most standard file formats are supported. Moveworks does not actively disallow any file type, as this configuration typically lives in the live agent chat system. Some platforms support unfurling image attachments in the chat, and all other attachments are displayed as links to files that can be clicked to open them. By default, there is no size limit.

Bot interactions during the live agent chat session

Beyond brokering messages between users and agents, during the chat session the bot can also do the following:

• Act on the “Stop chat” command to end the chat from the user side. This is a case insensitive keyword-based way for users to end the chat. It is deterministic rather than NLU-based so as to make it unlikely to unintentionally trigger.
• Deliver notifications and communication broadcasts. If a user receives any kind of notification or communications campaign during the live agent conversation, the bot will deliver it (to the user only, not the agent), however, any buttons or other ways to reply to them will be disabled while in the live agent conversation session. This is to ensure that no important notifications are missed by the user, while minimizing confusion as to with whom the user is chatting (bot or agent).

Ending the chat

Both agents and users may end the chat at any time.

• A user can end the chat by typing the keyword "Stop chat" to the Moveworks bot.
• An agent can end the chat, by using the chat platform native capabilities to end the chat, and this will be communicated back to the end user within Moveworks.
  • e.g: In the example below, using Amazon Connect, an agent would select End chat to end the chat with the user.
    

Configuration Options

Chat History

• Max number of messages to pass: You can override the 6 default messages to include more or less messages in the chat history by configuring Max number of messages to pass.
• Remove links from history: This removes hyperlinks before sending it to the agent.
  • For example, google.com would be stored as https://google.com|google.com in the Moveworks backend, and when this config is enabled, it would modify the string https://google.com|google.com to google.com. So all agents would see is google.com, which is the label of the url.
• Remove user utterances from history: For security purposes, you may opt to remove user utterances from history, and only include pass off the messages from the Moveworks Copilot in the context history.

Dynamic translation

If your organization leverages MLS (Multilingual Support), any chat messages sent between users and agents can be translated dynamically on the fly. This is a configurable option within MW Setup.

• Translation is from N-to-English, e.g non-english (user) to english (agent). In other words, all languages are translated to English and that's the only option.
• Also, a "Do Not Translate" keyword setting can be configured as well from agent to user ONLY. To be specific, the agent can prevent translation happening after a keyword. For example, the agent can type DNT //path//folder//file to the user and bypass the translation service.

File Size

Maximum file size for attachments can be enabled. e.g: 5 mb

Maximum number of attachments allowed per live agent session.

FAQ

Q: What security measures are applied to transcript data?

A: The transcript feature won’t be turned on by default. When turned on, Moveworks will persist the transcript in an internal s3 bucket with a TTL of 1 day. Also, the transcript data will mask PII.

Q: I have access to Moveworks on multiple chat platforms and on the web. Are agent chat sessions independent or shared across them?

A: Message Brokering chat sessions are ‘bot-scoped,’ meaning one can be talking to an agent in Slack, simultaneously talk to the bot in Teams, and open up another live agent chat on Moveworks for Web. As a reminder, Moveworks for Web is consider one bot if it is embedded on multiple websites, so one could, for example, start a live agent chat in Moveworks for Web embedded on ServiceNow and then navigate to the bot embedded on SharePoint Online and continue the same live agent conversation.

My system allows multiple agents to join chats with users. Does Message Brokering support this?

A:

• Yes, if another agent is invited to or barges into a conversation, all their public messages will be delivered to the user and attributed to each individual agent.
• Private messages sent between agents will not be shared with the user.