The idea to the Austrian Airlines Chatbot was born right after the announcement of Facebook opening up their Messenger API. To us it was crystal clear from the beginning: this is going to be huge! And because we already realized a rather big innovation project with Austrian Airlines (see flymeto.austrian.com) we approached their social media agency ambuzzador to partner with us once again to bring this innovation to Austrian.
Said and done. Austrian Airlines were very quick in realizing the huge potential and allowed us to start the project.
What should we do? Where to start when building a Chatbot?
There were some major decisions to make in conceptualizing the Chatbot. First, there was the question of which functionality we should provide. What is the scope of the bot? We quickly identified that a minimal viable bot (MVB) for an airline should:
- be able to search for flights
- provide excellent answers to the top 5 customer support questions
- be able to handle other questions reasonably well
- do small talk on a basic level
Keep in mind that this was the MVB specification. It was clear from the start onwards, that we wouldn’t be able to handle 100% of the requests successfully. So we needed an additional option:
- If the bot fails, hand the conversation over to a human agent for further processing
This system differs entirely from the setup that KLM is currently believed to operate on, which is: Let an AI make a suggestion and a human sign off on the message. While it is obvious that their system (for now) is more precise – because a human is still in the loop – the future potential makes our approach more powerful. Only in a solution like this one can fully materialize the potential of an AI, but keep the human capacities for edge cases and complicated requests.
Hello, who is speaking?
Now that we knew what to speak about, the next question was: who is speaking?
There are two main strategies here:
a) You create an avatar, and let that avatar speak
b) The brand speaks for itself
Both have their advantages and disadvantages and I leave that to another discussion, but in the end, we opted for B with Austrian Airlines: the myAustrian Messenger Service was born. Interesting side note: The decision was made not to use the word bot in the name because Austrian Airlines users aren’t accustomed to this term yet.
Ok great, but how do we speak?
So now that we clarified what to speak about and who is speaking, we arrived at the question: How do we speak?
Most companies have a set of rules for their Corporate Design – but now we are talking text. So you need a “non-visual branding guideline”, which, in most cases, exceeds the guidelines in a Corporate Design handbook. And that is exactly where our partner ambuzzador comes in. They provided domain-specific knowledge for Austrian Airlines, which includes standard greetings like “Servus” or certain ways to communicate. This domain knowledge is always an important part of the personality of the bot. Because only the personality makes the experience something unique and hopefully outstanding.
MVC ≠ Chatbot
After clarifying all the personality and soft parts, we finally had the go for the hard parts – building the chatbot.
But soon we realized that we had a major problem: A classic MVC (Model View Controller) structure of software projects doesn’t work!
What is your controller? – You only have 1 view (the Messenger API so to say). It was really hard for us to press the structure of a bot into this excellent model of building software. So at some point, we gave up and did what every developer does: Rethink everything!
What we came up with is, IMHO, a clever system to structure big bot architecture: a lifecycle model.
Only in a lifecycle model do I have the possibility to hand over messages from different packages to another to facilitate structured processing of the input to the output.
The Austrian Airlines Bot, therefore, has 4 lifecycle modules:
- Enhance
- Understand
- Knowledge
- Decide
Enhance
In this first model, we aim to correct and “enhance” – duh – the user message. We convert payloads to objects, emojis to a readable format, etc. This is also where you correct spelling and grammar mistakes or add additional context information for the next module.
Understand
In the “understand” module we try to understand the user intent and extract entities we are working with. This is mainly done by the NLP/AI service api.ai, which was recently acquired by Google. We decided to go with api.ai because back then when we did our market analysis, they were the ones we felt most comfortable with concerning the quality of their modeling (though they are expensive). In addition to this external service, we had to work around a couple of glitches and specialties of the platform to correct and further customize the results with our own little NLP engine. This was necessary since a general AI/NLP provider can’t handle all the cases we wanted.
Here is also the point in the software where we try to generate a first answer for the user.
Knowledge
In this module, we aim to improve the result from the previous section even further – either by finding better answers in the knowledge base of Austrian or by simply enhancing the output by e.g. quick replies that are fed from the long-term memory. The latter is especially powerful since it drastically increases customer satisfaction and speed. In this module, we work a lot with different IBM Watson APIs (which are extremely powerful, #fanboy). Here we also decide whether the content should be enhanced with a web view (e.g. a date picker in a web view) or not.
Decide
Now that we have finished the lifecycle, it is time to decide. This module now looks at the different answers that the previous modules produced and tries to decide what the best way to present the information on the messenger platform is. Is it a carousel? An image? Just an emoji? Or is the text just fine?
What you see in your message window is the outcome of this decision.
We failed – happens – how do we recover?
As mentioned in the beginning, it was clear that the bot wouldn’t be able to handle 100% of all use cases. So it was important to define an exit case that would hand over to the excellent support staff of Austrian Airlines. This in turn creates a few problems with the bot dynamic. Since the bot would automatically answer every message, we had to “silence” it in these situations. This, and waking it up again, are some of the finer processes that are crucial to ensure a good customer experience overall.
SUMMARY
Overall, we were really happy with the results of this short 3-month innovation sprint with Austrian Airlines and are incredibly excited about what’s to come. We recognize that the bot performance we deliver at the moment is not yet where we want it to be – but that is how innovation and early prototyping works. We are constantly improving the setup and the confidence the system produces and are currently seeing more than 1.5k messages daily.
Side Note: Vienna the City of Chatbots
One amazing side note here: Vienna’s Bot Community. We are very proud to be located right at the center of bot activity in Europe. The City of Vienna was voted the most livable city in the world 8 consecutive times and now we are proud to say that we – as a community of bot developers, designers, writers, and product owners – are the capital of bots in Europe too. Our monthly meetup is probably the biggest meetup in Europe and events like the ChatBotConf clearly establish our position. We (TheVentury) are excited to also launch Europe’s first chatbot-centered accelerator in Vienna. We hope to further foster sustainable growth for this technology in Vienna, the City of Bots, and are inviting everyone to apply to our first batch that starts in Feb 2017.
Bots regards,
Jakob from TheVentury
