Bots for Messenger: The good, the bad, and the ugly
[Edit July 2017 — This post still seems to get a lot of views, and I wanted to point out it’s 15 months old, so many of the negatives in this list no longer apply. ]
Facebook launched their widely anticipated Messenger platform on Tuesday 12th April, which is focussed on enabling businesses and developers to build and deliver services for Messenger users.
Obviously there is massive potential here, not just as another live chat platform (of which we already plug into plenty), but also with the added benefits of the identity data and social graph that Facebook has.
I spent Tuesday building our integration for Messenger, so this is a brief recap of my initial thoughts on it, good, bad, and ugly, a quick proof of concept I built with our platform:
Good
Documentation
As you can probably imagine, building out the integrations for Converse means I’ve built against all kinda of APIs with varying degrees of complexity and maturity (some still give me nightmares!)
Facebook’s documentation for building a bot is actually very well laid out, and significantly easier to get started than when I previously integrated with their Page API to deliver similar functionality in the past.
The only headache I’ve seen several people trip up on (including me!) is stage 4 in the getting started guide, ‘Subscribe the App to the Page’ which although the simplest thing in the world to do, lots of people seemed to skip past, so watch out for that one.
Speed
My biggest frustration with the previous Page API for messages was that it was slow and inconsistent in regards to how long messages would get batched for until a webhook was submitted. From memory it suggested it should never be longer than 5 seconds but I frequently saw it take significantly longer (30–60 seconds). Not exactly real time, and not particularly helpful for building a bot.
I haven’t benchmarked it but with the new API nearly all my calls were coming through in less than a second, which is quite acceptable.
Images
Not all messaging platforms support sending inline images, and unsurprisingly they all integrate this in different ways.
Some require the image to be uploaded via an initial API call, and then a second call submitted with the UUID to the uploaded image, this also means of course handling the image in your bot script/engine directly, rather than referencing it elsewhere.
Facebook has taken the opposite approach, which is just to let you specify a link to an image and for them to handle retrieving it, which gives you the freedom of handling the image hosting however suits you best.
I’m sure there are pro’s and cons to that, so feedback welcome.
One issue that isn’t clear though is what image types are supported, how and what does it do around resizing/scaling images, caching etc. I tripped up on this when attempting to use an SVG image which failed with an OAuth error for some reason, which wasn’t particularly clear.
Facebook needs to document more clearly how the image handling works.
Buttons
Facebook has followed the lead of several other messaging networks here in providing the ability for buttons to be used as well as text input, for users to respond, e.g:
Overall I think their implementation of specifying buttons is ok, including the ability to send a payload as a callback when a button is pressed, however buttons aren’t a panacea for guiding a user through a conversation, especially if multiple options exist, so use with caution, as equally expecting a user to jump from buttons to text input and back again may be more confusing than no buttons at all.
Interacting with buttons has several issues though:
a) Pressing a button immediately triggers an ‘is typing’ response, which if the bot/human doesn’t respond within a few seconds looks confusing.
b) Apart from (a) there is no feedback to confirm a button has been pressed, so if you were to look away and come back a few seconds later, without a response, you are likely to believe you didn’t properly press the button
(c) Related to (b) there is nothing stopping you repressing a button from a previous point in the conversation, or an entirely different conversation in the same stream, even if the context has completely changed and time has passed. This I have no doubt will cause all sorts of headaches in managing state and context, and thus cause user confusion.
I would propose that Facebook make two changes here:
a) Allow the ‘is typing’ option to be configurable on a button press
b) Allow buttons that have been pressed to change colour for traceability, and be locked to avoid being re-pressed
c) Document how to trigger the ‘is typing’ option via the API.
Templates/Bubbles
Bubbles are the framework for providing other rich media (e.g graphics with a button as per the image above). They are opaque enough that they offer a reasonable degree of flexibility in presenting options, and the carousel option (for swiping left and right) give additional options without wasting screen real estate.
Discoverability
I think Facebook has been sensible here to begin with, in pushing businesses and brands to drive people to messenger from their existing sites with plugin buttons:
Bot Stores
I think there is definitely a place for a ‘bot store’ and indeed some are starting to appear, but I suspect they will go through several phases
a) Lack of actual bots.
b) Abundance of bots of relatively low quality.
c) Bot overload, with discoverability and ranking being an issue.
(Sound familiar?)
In the mean time, brands can get on with driving customers directly to interact with them via the buttons, strengthening existing relationships, which is a very different situation to the previous App Stores, and with significantly less friction.
User Details Privacy
An obvious question is ‘what information can a bot discover about me’ from what I can see this breaks down into two categories.
a) What a bot can find out when you interact with it from within Messenger.
b) Customer matching via phone number outside of Messenger.
Facebook has done a good job on both of these:
a) The API only allows access to first and last name, and picture
b) The user is sent a messaging request which only allows access to their details if accepted. This is of course the only sensible approach, but I do wonder if there should be an option for ‘don’t allow this’ for users to prevent external requests, for those truly concerned.
Bad
Some of these comments relate to Messenger, some to the examples and bots launched so far, so make of them what you will!
Conversation Flow
The official Facebook examples seemed to overly depend on buttons to progress the conversation. I wonder if that is because of the underlying need for an NLP capable bot engine underneath to handle text options.
Disclaimer: We (Converse AI) solve this problem for companies wanting to build semi or fully automated bots without having to dive deep into writing code, other bot platforms are probably available :)
Prompts
When messaging a bot for the first time in messenger, if using the mobile client it has a nice summary of what to expect from the bot:
Unfortunately, when using the web client, that is simply not there, so you are left with a blank page, and no clue how to start.
It then gets worse, if a user does start a conversation with a bot, the absolute key thing to do is help guide the user on what the next steps are.
Not to pick on Poncho, but this is not exactly helpful:
I’m looking for a weather report, I’d expect it to be asking for my location, or something at least, but then I want to use a bot to achieve something, rather than get to know it, which is perhaps where the difference lies.
Failure Modes
One of the other major conundrums for bot usability is what happens if a user doesn’t understand or doesn’t follow the expected input, especially if it’s free form text.
The last thing anyone wants, is an endless loop of ‘I’m sorry Dave, I’m afraid I can’t do that’, so if not deploying a human fallback option (see below), bot builders need to ensure they both guide users sensibly, and deal with failures in a sensible manner to avoid frustrating their users.
Humans vs Bots
Some of the criticism that has been levelled at these examples is around response times, and that is partly because it isn’t clear when it’s a fully or semi automated process with human backup (and in that respect the term ‘bot’ is clearly confusing).
We are big believers in the need for both solutions, potentially within the same brand/company, depending on the task required. (Writing lots more about this in future posts).
One thing I really like about how Intercom works, is you can clearly see who is replying to a request. Now I’m not suggesting that Facebook enable you to see exactly who the human is behind it, but allowing different personas within a single messenger conversation would be highly useful.
Sometimes a user is happy to talk to a bot, other times they want to talk to a human, technology should be used to enable that, not obfuscate it.
Facebook needs to find a way to make this distinction clear, possibly using personas or avatars, perhaps even just an indicator to specify if its a bot or not.
Group Support
Not a massive criticism, but it’s clear Facebook will need to allow and support bots in Groups, obviously this depends on the use case as to whether it’s sensible, but they are lagging behind here.
Receipts
As well as the other forms of markup, Facebook has also launched a specific type for Receipts. This has several nice features (e.g click to expand) which work well in the flow in messenger, but the reason I rate this is as bad, is there is clearly bigger plans at work here that aren’t clear.
If I attempt to send a message with a receipt reference that I’ve already used, the API rejects the request as not unique.
This is:
a) Slightly annoying as there appears to be no way for a user to ask for a copy of an existing receipt from a business, or to change a receipt in any way.
b) Revealing in that clearly Facebook is storing the receipt data for other reasons, which are not clear to the user or to the business at present.
Facebook need to be clearer about what is and isn’t possible with that data, and what they are using it for.
Ugly.
Ok, so the good thing is nothing is really truly ugly, but it’s clear that more attention has been paid to the mobile Messenger client than either the Facebook or Messenger Web Interfaces.
This is not surprising, but there is a few things that I would suggest are considered:
a) Prompts on messenger.com need to be implemented
b) Facebook need to decided how to manage messages within the Facebook web interface, does it need to change or should it be split out like on mobile, both have their issues.
c) Welcome messages should be mandatory when starting a conversation if initiated by the user to frame it appropriately , ideally as an initial response from the bot, similar to how Telegram achieves it.
d) It should be possible to allow a user to selectively share their metadata through Messenger to add context as needed, e.g location.
In Conclusion
Bots are very much on the beginning of the hype cycle that comes with any new technology.
The question is now, how long will it take us to get past the hype and to see seriously useful bots be developed and in widespread use.
Right now it is anybody’s guess, 18 months ago Microsoft, Kik, Telegram & Facebook all making major announcements on bots within the same month would have been unthinkable.
One thing is for sure, whether you like it or not, 2016 is definitely the year of the bot, and Facebook’s announcements have bought bots into the wider focus, outside of just the developer ecosystem.
These are just my views, I’m quite sure there are a wide range of thoughts out there around Facebook’s Messenger Platform launch, bots in general, and how this industry will look as it progresses, so feel free to agree, disagree or be insightful in the comments!
