What’s a manager bot?

“Manager bot” is a widely used term, but it’s a bit of a misnomer because the term “manager” has more to do with the bot agent than it does with the bot itself.

A manager bot is simply a bot with an agent connector that’s configured in a specific way that allows the bot agent to listen to all consumer messages on the account. This is the case for automated conversations with other bots, and for conversations with human agents.

In the bot itself, there is no specific design that’s needed. No specific dialogs or interactions are required. The bot can do whatever you need it to do. There is also no difference in the way the bot works. Once the bot receives a message, it processes the message just as it would if the message were passed via a regular bot agent. If the message triggers a dialog in the bot, the dialog’s flow begins.

Use cases for manager bots

Typically, you use manager bots that listen to all consumer messages to invoke actions such as:

  • Send a message or email to managers. You might want to alert managers that a consumer has triggered a critical intent (such as “self harm”). You can include the conversation ID, what the consumer said, etc., in that communication.
  • Transfer the conversation to a manager. You can check to ensure the manager is online before transferring.
  • Send a private message to the agent. This message can provide guidance on how to handle the conversation.
  • Report on an event. This might involve tagging the conversation with an engagement attribute (SDE).
  • Trigger a LivePerson function (FaaS function) or integration, i.e., call an external API.

Common use cases include:

  • Logging/escalation bot in a vulnerable consumer scenario: This solution involves detecting statements of self-harm in the consumer message, so the conversation can be transferred immediately to a specialized agent or team. The solution can also involve logging the event in Bot Analytics via custom events, messaging the consumer, and/or sending a private message to the agent.
  • Queue management/wake-up bot: If the conversation meets specific criteria (that is, it’s been in the queue for a certain number of minutes), this solution uses a LivePerson function to send a message via the Web View Integration API to the manager bot. In turn, the manager bot either sends a message to the consumer, or transfers the conversation to another bot that does. Note that this solution requires that LivePerson enable some functionality behind the scenes. Contact us to explore this solution.


You create and implement a manager bot just like any other bot. There is no difference in building the bot.

What’s different is how you set up the bot’s agent connector. For Role, select “Manager,” not “Agent.”

The Add Agent Connector window, with a callout to the Role field

Also, make sure that the assigned user (set in Agent User ID in the agent connector) has only the Agent Manager profile (and no other profiles):

The Add User window, with a callout to the Profile Assignment area

That’s all there is to the setup of a manager bot. With these two things in place, the bot agent will listen to all consumer messages on the account.

Keep in mind the default value of the maxConsumerMessageDelay custom configuration field. You might want to change the value in the bot’s agent connector.

Also, there are several custom configuration fields for manager bots that you can configure in the bot's agent connector as well.

Best practices

  • We recommend that you have LivePerson assist with the configuration of any manager bot, or that you have LivePerson review the configuration before you release the bot into Production.
  • Use one manager bot per account. This mitigates the risk of two manager bots conflicting with each other.
  • Control the load capacity: In the manager bot’s agent connector, configure the filterPatterns custom configuration field. If set, the bot agent will still listen to all consumer messages. But the bot itself will process only the consumer messages that match a Regular Expression in the list that you specify. If a consumer message doesn’t match an expression, it’s ignored by the bot. Use this field to control the load capacity, so the bot acts on only the messages that you care about.

    For example, if your filter patterns include the word “bill,” the bot will ignore “I want to change my shipping address,” and it will process both “thanks a billion” and “I want to pay my bill.” But if only the latter triggers a dialog flow due to a “pay bill” intent match in one of the bot’s dialog starters, then only the latter will result in an action taken by the bot.

  • Plan and build carefully to ensure that the manager bot doesn’t send the consumer undesired messages inadvertently.


  • Due to an enforced limit, a single bot agent connector can handle a maximum of 999 concurrent conversations. If this is exceeded, the conversations in the overflow aren't assigned to the bot agent because it's at capacity. To control the load capacity, we recommend that you configure the filterPatterns custom configuration field. For example, if there are 1,000 concurrent conversations, and 100 match the patterns, then the manager bot still has a capacity of almost 900.
  • Manager bots listen to all consumer messages on your account. If you add two agent connectors for a manager bot—in an attempt to distribute the conversation load—this won’t work. It will result in both agent connectors joining all the same conversations. Again, to control the load capacity, we recommend that you configure the filterPatterns custom configuration field in the agent connector, so the bot processes and acts on only messages that match specific Regular Expressions.
  • Manager bots listen to only consumer messages. They don’t listen to agent messages, so you can’t trigger actions based on agent messages. This precludes you from listening for and acting on bad language used by agents, agents ignoring policies, etc.

Solutions using the Web View Integration API

Using the Web View Integration API to post info back to a manager bot? Provide your account ID to your LivePerson account representative, so they can get that added to our backend configuration list.

Conversations on accounts in the list take longer to expire. Adding your account to our list can avoid a situation where the Web View Integration API tries to send a message to the bot runtime, but the conversation has already expired.

When calling the Web View Integration API, you must prefix MANAGER::: to the userplatformId to ensure the Web View message is processed. This is to satisfy underlying architecture requirements. Otherwise, the bot becomes stuck.