How Bots work with SMM Response

Khoros Alumni (Retired)

I've had conversations with people about how Bots "work with SMM Response" - and thought I'd start a discussion about it here. My initial explanation is as follows – first at a business level and then a technical level.  Please comment / question as you have thoughts - we can go as deep as you want.

This isn't meant to replace the bot overview or the technical api doc.

Business Level

If a bot is registered with Lithium for a particular messenger handle (page), then:

  • Lithium assumes the bot is handling every new conversation for a user *until* the bot tells Lithium that an agent should be involved.
  • The bot (should) assumes Lithium is handling every message for that user *until* Lithium tells the bot that the agent is done.

Lithium and the bot can still “see” every message. In Lithium for example, supervisors (or anyone given permission) can see conversations (and their analytics) that the bot is having  prior to the bot "handing it off" to an agent.

Note: As the bot is developed, it needs to understand that Lithium exists and integrate with the Lithium Bot API, and when a bot is deployed, the configuration in Lithium has to be set-up to provide the workflow above. (Lithium offers assistance  through a services / fast-track offering).

Configuration / Technical Level

Lithium and the bot are both independently connected to the messenger API receiving messages and responses.

There are two primarily API interactions that matter – the bot telling Lithium that it is handing off to an agent, and Lithium telling the bot that the agent is done. This determines who is responsible for making sure the customer gets a response (and again, Lithium analytics can surface any conversation that a bot is responsible for that isn't getting a response.

In Lithium, the mechanics of the business scenario described above are simply that Lithium applies tags to conversations that have bot interactions and these tags change based on the API calls. For example, when a bot tells Lithium it is time for an agent to get involved (we call this a “bot hand-off”), a “Bot Hand-off” tag gets applied to the conversation and routing rules are re-run. Standard routing rules can then cause the conversation to be routed to a queue that has agents assigned to it.  Prior to this, the bot conversation still exists in Lithium and was routed to a queue, but the routing rules (should) have had it routed it to a queue that agents don’t belong to.

What isn't clear? Do you have questions?  Are there bot-related questions?

Khoros Alumni (Retired)

@AdamCo can you explain how the bot is alerted that the agent is done? Is that when the agent closes the conversation?


We recently started using the bot, but has some questions on the best strategies to use.  Our primary concern is reporting.  Mainly what is the start time of an interaction, and what is the end time of the same interaction?  We know that these conversations can be fluid and the customer may not respond immediately, so we are not sure how to measure agents performance, or even set a response time goal.  Is there anyone out there using the bot willing to share their success stories?

Khoros Alumni (Retired)

Hey @CKeith, we are working on building out specific metrics around bots, however in the meantime there are ways you can measure bot activity and your agent's response times for bot handled conversations using smart views and custom analytics dashboards.


At a high-level, we define agent response time for conversations handed off by a bot as the time between when the customer asked to speak to an agent and the time the agent responded. To ensure that TAR data is accurate from a team/agent reporting perspective, we pre-filter out bot response times from our response time metrics/widgets. Additionally, we treat the first agent response after a bot handoff as the first response for purposes of measuring agent response times. This allows you to get a clear picture of how your agents are performing across all conversations including those handed off by bots.


As an example of what you can do within our analytics platform today, you could create a Smart View filtered to show only conversations that have the "Bot Handoff" system tag, and apply this Smart View to the 'Response Times' or 'Responses Meeting TAR SLA widget’. This would show you what your agent response times are when conversations are handed off by a bot so you can evaluate whether you’re meeting your goal. 


Hope this helps to answer your question!


@AdamCo I have registered my facebook messenger bot with our dev Lithium Response using the Bot API. But still I am not able to see the bot conversations at Lithium end.

Is there any set up needs to be done on Lithium side to make the Bot flow work?


Thanks in advance.

Khoros Alumni (Retired)

@sunidevtest - yes, there is some back-end config required. please file a support ticket asking for this including the environment and the fb page (ideally the fb page id) of the page that you want bots enabled.


Hey AdamCo,


We have submitted our questions to the case #00151476. Please let us know if any concerns.




Khoros Alumni (Retired)

The following questions where raised by a customer


1. How do I ensure the bot conversations are captured in the desired workqueue? 


This is all based on the routing rules that you create. As soon as Lithium receives a both response and thread it into the customers' conversation, the "Bot" tag is added to the conversation - and assuming the conversation is not claimed by an agent already, the conversation is re-routed. Since the bot responds right away, the chance of a human grabbing it is small. If the bot is initiated via a structured msg, then you could also have a tag and rule for that and use it in the routing into the bot queue.


In this way, you can have all conversations that a bot is interacting with in a separate queue.


2. When the bot hands off to agents, how does LSW know which queue to handoff to?


When the bot handoff call happens, the "bot handoff" tag is applied. The rule for the bot queue would generally *exclude* the bot-handoff tag. As mentioned above, you could have the inclusion part of the rule not only include the "bot" tag but also a "bot initiation phrase" tag.  With this, the rule would look like:Screen Shot 2017-10-20 at 10.05.11 AM.png






Thanks @AdamCo, that's pretty much what I thought


@JessicaW  Thank you for your helpful post about response time.  Great to hear that this is being calculated to account for bot first responses in the dashboard widgets.

For the Raw Response report, will the agent's first response on a bot conversation have a TAR based on the time since handoff was requested or is it based on from the customer's first unanswered post?