AdamCo
Khoros Alumni (Retired)
Joined 13 years ago
User Profile
User Widgets
Contributions
Re: Facebook Messenger: 24 Hour Response Policy Change
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).Re: Is there an API to send and receive messages for Lithium Messaging
jrash06 - If you are referring to the new Lithium Messenger offering - yes. In fact, we have a customer already live with this deployment pattern. Simply said, there is a web hook you register to receive new messages and an API to send a message - so essentially you just relay messages in both directions. Note that there is a server side solution for this as you ask, but our client-side SDK allows registering handlers for events -if that is part of your use case too. When you are interested, I can get you more docs (we have published them yet).Re: How Bots work with SMM Response
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:
