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?
There were some major decision to make in conceptualizing the Chatbot. First, there was the question 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 the 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 ≠ Bot
After clarifying all the personality and soft parts, we finally had the go for the hard parts – building the bot.
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 I have the possibility to hand over messages from different packages to another to facilitate a structured processing of the input to the output.
The Austrian Airlines Bot therefore has 4 lifecycle modules:
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.
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 aquired 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 to the user.
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.
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 in the messenger platform is. Is it a carousel?, An image? Just an emoji? Or is 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 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 to 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.
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 were 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 Bots
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 Feb 2017.
Jakob from TheVentury