How We Built Burger King Bot
Building a complex bot is not as easy as it seems.
These are the decisions we had to make to build an excellent bot and everything we learned during the trip.
Disclaimer
Bot runs on Spanish so screenshots are on Spanish too. we provide a small translation below the image when necessary.
The problem
Building a bot for food industry has certain inherent problems. In addition to the issues specific to the development of a bot we have several business restrictions. We will mention some of them below.
Business Restrictions
The bot should work on Facebook Messenger .
The associated Facebook page receives a lot of traffic not related to food orders but with commercial proposals, job orders, advertising campaigns, trolls and so on.
What is more the page has its own community manager so we only have to deal with food orders and delegate control in a human otherwise.
The product selection on food industry is very visual. The menus should be able to be chosen with succulent images and appropriate descriptions.
The bot must be able to receive orders with rich native controls but also must be able to process natural language.
The virtual assistant must comply with the business rules regarding prices, combos, promotions, dishes order, promotions and discounts, etc.
The company has multiple shops, each with its open hours and corresponding delivery ranges.
The channel must be kept bi-directional, that is, it must receive orders but also warn the customer when the food is on its way with estimated delivery times. We should also remember the addresses where the orders were placed to retain customer and make recurring orders easier “Please. I want to repeat the last order to the last address”.
The order must be notified electronically to each shop on real time. Likewise, each shop must state its completion time in order to notify the customer, so the integration between systems must be very deep.
The challenge was very big and we had to make many decisions. Here are some of them:
Welcome and guide
The bot has a clear call to action along with a welcome message that sets the customer’s expectations.
The conversation can be initiated from an organic search, a Facebook ad (with its campign reference), by a friend’s suggestion using the share button, or from the website. It is necessary to save the reference to be able to match it with the later conversions.
It is expected that a significant amount of messages will not be related to a food order. We must take care of them quickly and guide them towards the corresponding channels.
Knowing the traffic origin and making appropriate decisions is essential to have flexible and unique experiences for each customer.
Ux vs. Customer Satisfaction
We took advice with a UX specialist who recommended us to put food order first (which is the main objective of the customer) and then ask for accidental data such as the delivery address, payment method and so on. However this was opposite to the business rule stating that we must check in real time if the branch responsible for sending the order has the products available in addition to estimating the correct prices (which may not be uniform). Faced with this dilemma we decided that it was more important to reinforce business rules over UX’s decision to better satisfy the customer’s needs.
It is very important consider UX guides but more important is to properly support business processes.
Natural Language Processing
After passively monitoring the Facebook page we decided to create a knowledge base and train our processor to determine the intents both in case of a recurring conversation and in a new one (where we had to determine if the customer was about to place an order or needed to communicate With the mark with some other purpose). For this we evaluated several alternatives and we decided to use Microsoft LUIS Which works excellent in Spanish and has a very good level of support. Training of the ‘brains’ is a constant task and the performance of the tool improves considerably over time.
The set of answers and knowledge grow constantly and we should not think of a setup process but one of continuous improvement.
Voice Processing
One of the design decisions we made was to accept voice commands in addition to the text. For this we incorporate a layer of SpeechToText present in most interactions. The chosen tool was Wit.ai.
Monitoring conversations
Peak meal times matches with noon and night and increases on weekends so we develop a series of early warnings for (possible) crisis detection. We also decided to use a replicated architecture with an elastic load balancer in the cloud to automatically cover the high demand for orders.
Food comes through the eyes
All menus that include dishes show high resolution images. These images are uploaded once to the Facebook servers using the upload attachments api. This greatly improved response speed especially in a geographical areas where communications are not optimized.
Delivery areas and addresses understanding
Processing addresses based solely on natural text is an arduous and complex task. We perform multiple iterations until we reach an acceptable solution by adapting the texts in order to guide the user to the exact address. We also added the possibility of sending us the customer’s coordinates using the native control provided by Facebook (although it is incorrect to use this location as accurate data — for example, it does not work for a building — allows us to restrict the search radius of a possibly ambiguous address) (For example, there are fourteen streets called ‘San Martín’ in the city of Buenos Aires.) In order to perform reverse geolocation, we decided to use Google services .
Customer loyalty
The quote says that it is harder to retain a customer than to get a new one. The bot is designed to stimulate the customers return remembering their last orders as well as the delivery addresses avoiding this step in successive orders.
The channel must be a means of personalization giving different answers to different clients.
Keyboard shortcuts
The selection menus used were buttons at first, then quick replies and finally a combination of keys and quick replies. We discovered by doing A / B testing that certain people prefer an option while others chose to type a letter. The bot is flexible and recognizes both options.
Product Loading
Initially for the food choice, we implemented a series of guided questions for customers to place their order. However it is difficult to make order checkouts using only native text and controls so we decided to replace all product selection with a webview using Messenger Extensions . This fact significantly improved the number of conversions and decreased the total interaction time which is one of the objectives we are looking for.
By changing the controls through a microsite, we significantly increase the number of conversions.
Keep it simple
Initially to make the closing of the order we use the native control of receipts. However we found that people were confused so we decided to use a simple text indicating the summary of the request.
Do not be tied to a decided solution in design stages. You have to launch a test aproach and do A / B Testing.
Conclusions
Performing a complex bot for a customer with high demand required us to understand very deeply the existing tools as well as develop our own solutions.
This note is obsolete as it is published because the bot is constantly evolving. You can try it here and write us your own opinions on the bot.
All comments are welcome!
