Facebook is putting serious efforts into making its Messenger (eco-) system way more than a way for friends to have chats. In fact there are features published all the time including payments via Messenger. Everything is geared heavily towards sales and supporting e-commerce in particular at the moment, end of 2016. There is a big opportuntiy for customer service as well which is not highlighted nearly as often. The presentation shall inspire you as to what to actually use chat bots for, and while Facebook's Messenger is all over it you could translate it easily into bots using Microsoft's bot framework, WeChat or anything that involves interactive machine driven chats. More on the whole matter: http://bit.do/messengerbots
3. Generic business scenario #1:
Auto-fill the shopping basket
originating in an earlier interaction,
resulting in sales uplift
Rationale:
Start the shopping naturally, not starting with the shop front.
The buying will follow as soon as you deliver what the
consumer wants.
4. Example on how driving online sales could work
FB Bot API
FB Messenger
<Retailer> Recipe DB (copy)
Recipe API on top of a
Recipe DB
1 2
1
<Retailer> e-shop
2
1
Consumer is looking for recipes – pulled out of a copy of <Retailer>‘s recipe DB with
SKUs attached for every single recipe ingredient. All SKUs are in <Retailer>‘s inventory. Every recipe comes
with a unique recipe id.
2
We offer the consumer to buy the ingredients for his desired meal right away online – and are able to resolve all
items for the shopping cart by utilizing the Recipe DB*, or to be more precise an API on top of it. This is done by calling an “inject”
request to the Recipe DB API. The Recipe API will use a webhook that sits with the <Retailer> e-shop‘s end. The webhook
creates a basket with all the ingredient items, ready for check-out and payment.
The consumer can then look for more recipes and add them consecutively into the basket, back to 1
Will people finish the check-out and buy with just the ingredients for a couple of meals? Probably not but on the other
hand they already started shopping in this scenario and chances are they’ll add some more articles to make it worth it and eventually buy.
5. Generic business scenario #2:
Extend your marketing reach
Rationale:
Give the consumer a reason to chat with your bot – and
collect the opt-in for chatting with the consumer in the future!
Remember, FB Messenger chats can only be used for
pushing messages if users pro-actively messaged your bot.
6. Example on how to extend reach by generating
new opt-ins for Messenger
1
The keyword is known to the e-shop / the Promo Engine. It is a link between: loyalty id and unique consumer id,
as far as the consumer is already subscribed as a Loyalty member.
The exact reward is predetermined via the Promo Engine, so this keyword is at least personalized by segment,
could be down to and individual level.
2
In this example mentioning the keyword triggers the redemption of the reward, all orchestrated in the backend.
Further flows, for Example subscribing Loyalty membership, can follow on the link posted/the landing page it leads to.
Meanwhile, at the moment when the consumer types in the keyword we get some profile data* and
more importantly his opt-in to message him pro-actively via Messenger in the future. Key constraint here is that
the user needs needs to keep interacting with your bot, will not receive messages if does not interact within a
certain duration that might change in the future and is 24h at the moment.
Your secret keyword is
OXYMORON. Try it with our
chat agent now!
1
Keyword Link DB
Promo Engine
2
* {
"first_name": "Zorro",
"last_name": "Montana",
"profile_pic": "https://(…)”
"locale": "en_US",
"timezone": 2,
"gender": "male"
}
7. Generic business scenario #3:
Extend your marketing reach
Rationale:
Let the consumers do the drum rolling on social media on
your behalf. Obviously dearly requires good incentives!
8. Example on how to run competitions for
social drumroll
1 Initiating a chat with the consumer: challenge to spread the word.
2
In the background, we‘ll constantly crawl for updates and evaluate posted links. Every link contains the recipient ID (or
any other shared id we know about and want to use). It is all consolidated in a dedicated database - and by the time
we detect that the challenge is fulfilled we trigger an event: pull in a valid voucher via the Promo Engine and make it ...
Crawl for posted links
Evaluate links
Consumer Link DB
1
2
Trigger events
2
Promo Engine
3
...available to the consumer by sending him a deep link to the e-shop, including the voucher coder retrieved.
(NB: The reward does not have to have monetary value, you can experiment with things like access to special video
contents on <Retailer>’s content platform.)
3
9. Generic business scenario #4:
Get rid of Loyalty points in your books
Rationale:
Loyalty currency can be worth real money and in that case
turn out to be a financial burden if it keeps piling up.
10. Example on how to run Messenger campaigns to
liquidate loyalty points across channels
1
Find out about the opted-in consumers with the biggest share of Loyalty
currency, e.g. Airmiles or Lufthansa Miles or anything along those lines.
Based on that, generate offers for that segment (or several segments) - with
the help of a Promo Engine. Personalization on segment or individual level.
2
Analyse consumers:
target the ones with
plenty of idle points
1
Promo Engine
3
Analytics
Systems
Consumer Opt-In FB
Consumer Opt-In email
Consumer Opt-In Push
conditional
Generate offer
1
2
(Other actions,
orchestrated)
3
Make a decision on what channel to use to address the consumer, based
on preferences or simply based on available opt-ins. Why not get in touch
via Messenger, for example? An easy to use channel that feels natural.
Prime a call 2 action with a clear incentive, like in this case via Messenger.
The link is connected with the Offer Engine/all systems needed for
Financial handling and management of vouchers. We assume here that the
Offer Engine is all we really need from a Facebook Bot perspective.
11. Generic business scenario #5:
Tie the consumer identity to an identity you already
know about
(as soon as possible in the conversation).
Rationale:
Make best use of the wealth of information you possess and
the consumer experience a lot better in the process.
12. Example on how to connect the consumer with other
federated identities
1
During the course of any given interaction with the consumer via FB Messenger,
generate a viable offer to present to the consumer – in case the consumer has not yet
logged on with his retail store credentials/identified himself as a retail store customer.
Experience tells that you will have to give out incentives to make that happen.
2
At any point of time of the
Messenger conversation, start an
attempt to link to other identities
1
Promo Engine
3
Initiate Log-In
conditional
Incentivize logon1
2
3
Present generated offer to the consumer. The consumer now has a choice to follow
that call 2 action and initiate the “login”. Implementation: Wait for the consumer to type in
a literal like “login” or present an action button saying something like: “Log In”.
Once the logon against the <Retailer>’s IdP has succeeded you can return the UID of the consumer as used by the Retail System
the user logged on to and use that ID for all further interactions, like abandon cart reminders or personalised interaction.
13. We‘re noteven done here.
http://bit.do/deluxebots
Check out this list of
awesome chatbots:
To make better sense of what the consumers are looking for, we‘ll utilize luis.ai to turn consumer questions into intent.
With this intent we will query the recipe DB.
Access to all databases on this diagram is impl. with the help of AWS API Gateways that
expose the DB via an AWS Elastic Beanstalk app or even better Lambda functions. If we do not want to implement any of this on our own we can use as well orchestrate.io
DISCLAIMER: All this was valid in August 2016. Things change, in particular for services in beta state – and FB Messenger bots were in beta by August 2016. So yes, there might be other appealing options by the time you read this.
The hosting of those links between the different ids can be done by us. For this purpose we could utilize DynamoDB – or, if encryption at rest AND in flight is demanded, utilize another storage type like AWS RDS Aurora.
There are plenty of technology choices on Azure as well if we want to rather venture into that.
DISCLAIMER: All this was valid in August 2016. Things change, in particular for services in beta state – and FB Messenger bots were in beta by August 2016. So yes, there might be other appealing options by the time you read this.
Technically, there are three components in play:
-The data crawler, could be implemented by a worker process we create or by utilizing Logic Apps on Azure (TBC) or AWS Kinesis streams with AWS Lambda functions for processing
-The consumer link DB: Access to all databases on this diagram is impl. with the help of AWS API Gateways that expose the DB via an AWS Elastic Beanstalk app or even better Lambda functions. If we do not want to implement any of this on our own we can use as well orchestrate.io
-Real-time connections to the Offer Engine or constanlty synchronized offers for that matter, could end up in the Consumer Link DB to stick to the used naming
Technically, this translates to:
1 – integrated 360 degree view on the consumer, this could come from the to-be or future Analytics Systems; if not coherent enough we can offer to create a recipient & offer database; implementation would be like for the previous DB examples; the important piece here is that all offers are in a DB like the one mentioned and that we track all offers by unique ids. Those ids are used later on.
2 – Like in all FB Bot cases there needs to be a backend webhook, all taken care of by Ice – again several options for hosting that, Elastic Beanstalk or API Gateway + Lambdas come to mind immediately.
3 – Push a Messenger note via Facebook Messenger APIs, using the predetermined „Air Mile trade offers“ ids created in (1) so everything can be resolved later – where that endpoint is finally implemented is not relevant, could be via the Offer Engine or the e-Shop or somewhere else