@jbrons - you can, but you won't be able to respond when it comes out of snooze. You might want an operational change to both let the customer know you won't be able to respond after 7 days unless they message you back - or maybe you want to snooze for 6 days and then let the customer know you are still thinking of them and won't be able to respond again until they message you back.
@EricFe - In the immediate future when FB enforces this rule, the way error will display after the agent attempts to send a message. The error will display in the usual place at the bottom of the response area and is self-explanatory.
In the future, we expect to make this similar to the error message we current provide for WhatsApp - WhatsApp has a 24hr period. This message is displayed proactively to the agent - they see if before they begin entering a message:
Also, it is pretty straight-forward to monitor for conversations that are approaching this 7 day threshold. You want to use the "Conversations Waiting Response" widget filtered with a SmartView for( Facebook AND Private) with the SLA threshold set at 168 hours (7 days).
Anything in the yellow/orange before the right-hand side is approaching the 7 day window. From there you can drill-down and decide what to do - response, close, etc.
Note, based on how we calculate TAR - from the *first* unanswered message, there might be some false positives (ie, conversations that you have a little more time to respond than the chart indicates). If a customer messages you one day - and you don't response - and they message you again the next day, the conversation will show up in this chart based on the first message to you (not the second).
... View more
I got a question recently about how to use author tags to filter data in analytics, and I thought I'd create this short video to show how you can do this.
A key thought to remember is that tags on authors are used to filter conversations / posts just like post-level tags.
... View more
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:
... View more
@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.
... View more
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.
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?
... View more