Building a chatbot and trying to implement the handover protocol. SO far I have it handing off to the inbox, so that if someone asks for customer service, the bot hands over to the inbox and presumably someone who is monitoring the page can answer. Once the inbox is the primary receiver, I can't find a good way to hand it back to the bot ... I know that I can set a timer and have the bot request
for the conversation to be handed back, but this does not seem like the best approach
mark the chat as 'Done' in the Page inbox and thread control will be returned to the primary receiver app.
I was interested in this functionality, but I was also wondering is there any way of monitoring whether a question has been answered after handing over to the inbox? So my chatbot can check and then take back control if it hasnt.
Related
Messenger Platform introduced Quick Replies feature, that the User can tap to answer Page Owner's request instead of typing. However, I can make it work from the User view only. Will it work from Page Owner's view, like suggestion?
Flow may be:
1. User ask Page a question
2. Bot suggest some <quick replies> based on that question (maybe use NLP)
3. Page Owner can tap <quick replies> to reply
I may call this "semi-auto reply bot". For example, in the demo here, the shop owner may double checked the response and tap to send.
No, there is not a direct way to do this. Theoretically you could basically have a customer-facing bot and a business-owner-facing bot, and then orchestrate the a flow something like this:
user messages user-facing bot
bot forwards the message to business in business-owner-facing bot with quick replies
business owner selects a quick reply
user-facing bot replies with the text of the quick reply.
You'd want to be careful of privacy concerns tho since the user's message is being forwarded on.
I've a basic question about protocol transfer on Messenger.
How can a community manager takeover a conversation?
I don't want people to click on button to go to the second receiver. I want the community manager blocks the automated answers from the chatbot and go on a live one to one chat via Inbox Messages.
Currently, there is no way for a user to take control from the Page Inbox. The only way for the bot to be turned off in a scenario like this is for the bot to use handover protocol to pass thread control to the Page Inbox.
https://developers.facebook.com/docs/messenger-platform/handover-protocol
i am developing fb chat bot, and i want to mark the message as read so that when the moderator of our fb page view the message part, they won't see so many unread messages even though the fb chat bot has already replied that user and they don't need to click that message just to mark it as "read".
How can i achieve this? I am trying to use this API: but it doesn't work.
https://developers.facebook.com/docs/messenger-platform/send-api-reference/sender-actions
You can not mark message as read (as of now), but the best way I deal with this is to use Handover Protocol
When your bot reply the message, it won't appear in INBOX, but it goes to DONE box instead.
When bot cannot answer, you can let your bot pass thread to INBOX. Then the moderator of page manually answer it. (and mark as DONE afterward)
Follow the instruction here to set it up:
https://developers.facebook.com/docs/messenger-platform/handover-protocol/pass-thread-control
(Note: You can pass thread to page inbox and then take thread back immediately. I will notify to INBOX, but your bot can still work with users.)
When you use the API you sent here (Facebook's Send API), you only mark the message as "seen" from the bot on the Messenger Chat that you have with your users. This doesn't affect the messages inside your Page's inbox.
Unfortunately, there is no way to mark messages as read inside your Page's inbox.
Is this new feature of fb bot? Thanks btw! I will try to check this.
Is there any side effects in Marking the message as done ???
To answer your question:
There are some bugs within the Inbox/Pages Manager mobile app. You won't see the messages in DONE folder if your admins are using Pages Manager mobile app for now.
I've reported the issue and working with them to solve it. However, you can still see those messages in DONE folder if you use a computer and go into your page's Inbox.
NOTE: It seems that messages moved to Inbox will be marked as seen (not bolded). This may be a little confusing if your admins don't mark each conversation as DONE after admin finishes conversation with the users.
so this is something I've been trying to think through for about 16 hours. I am coding with PHP / CuRl / etc - the bot works and everything is fine. My current issue is figuring out how to disable the bot and allow a human to begin chatting with the customer/sender.
Has anyone successfully, created a route for this ? I mean it's pretty hard from what I see, you'd have to disable etc etc. A lot of effort for my clients.
Thanks for any input.
Facebook has rolled out a "Handover Protocol" which is supposed to facilitate a combined human/bot Messenger implementation.
https://developers.facebook.com/docs/messenger-platform/handover-protocol
It is a little unclear what actually occurs in step 5:
Pass thread control: At some point in the conversation, a user may choose to do something like interact with a live agent. To handle this, pass thread control from the Primary Receiver to the Secondary Receiver. The Secondary Receiver will receive a messaging_handovers webhook event to notify it that is now controls the conversation.
This doesn't actually disable the bot (as the OP requested), and isn't in the control of the Page owner but rather of the user. It seems FB envisions the user typing something like 'I would like to chat with a human' triggering the bot to pass control...but it would be nice to let the page owner simply put the app in standby and handle the messages herself.
Once you recognize someone wants to speak to a human, set a flag that disables all actions of your bot to on.
Then, have your bot message you, or whoever will respond, that a user ID needs responding to. Have your bot continue to send all messages received from them back to you until you enable the bot again.
Create some sort of way for your bot to interact with you that allows you to send a message to a specific user, and a way to once again enable the bot interaction with the user.
Probably something like "sendMessage104012301230'Hi, sorry you couldn't find [etc]', and enableUser104012301230
There may be a better way, but those are some thoughts on how I'd do it
If you enable messages echo, whenever a human respond using the page, a echo post is sent, and inside entry->messaging->message there's no app_id.
You can use that information to disable bot replies for a certain period, or disable indefinitely until you enabled is with some admin command (that's how I'm doing)
I thought a solution could be to label the message as "unsolved". Another solution could be to have the bot mark the conversation as unread. Does anyone know if it is possibile to add a label to a conversation or mark as unread through API?
I'm starting to work with XMPP, and one of the things that stood out right away to me was the fact that since subscriptions can be in just one directions, the roster can have a contact with a subscribe state of:
-none
-To
-From
-Both
The problem I have with this model is that a user can tell if someone "blocked" them (unsubscribed), hasn't approved a subscription or isnt subscribed back.
Looking at it from the messenger style, if you don't approve a subscription or remove one, you its seen as if it they had approved the subscription, but just send offline presence.
Also on the removal, XMPP states that the server must tell the contact client that you have unsubscribed from them. I know most clients wont act upon this, but it means they COULD pop up something akin to "X contact has removed you from their list". Which I think is a privacy leak. If I want to block/remove people I'd prefer them not to know and just see me offline.
Is there a specific reason of why this is this way? Is there an official way to get around it (not exposing subscription status)?
From a certain perspective, it's just always just been like this, mostly because the early Jabber developers all took the perspective that you should just say "no" when someone asked to see your presence, unless you were sure.
That said, you can use Privacy Lists to block your outgoing presence.