[UX Labs] Chatbot OVH: artificial intelligence in support of customer experience
As part of the OVH UX Labs, a new R&D collaborative space dedicated to the improvement of user experience, we’re happy to give you the details on our very first project: the OVH virtual assistant. Now available through and , this chatbot can perform a diagnostic as well as answer a certain number of questions about your web hosting service. But this is only the beginning: we now need your help to increase its functional coverage so we’ve made it available as open source. More on this here.
We’ve created this chatbot because we want our customers to feel less frustrated when facing certain issues - at the moment we’re only referring to web hosting but it could be extended to other OVH services eventually if the original project is a success. The interest for the user is to get an on-the-spot diagnostic if a web hosting service goes down or is being affected by a configuration error, without having to contact support or open a ticket.
When it comes to designing the chatbot, we first started by focusing on the main causes of web support calls. It’s not surprising to learn that the first cause often goes like this: “my website doesn’t work anymore”. By putting this call category under the microscope, we’ve been able to isolate a few different cases, from the simplest to the most complex. Some causes of failure are pretty basic and can be diagnosed automatically, whereas others require the development of an artificial intelligence in order to be accurately identified. From a partially configured SSL certificate, to DNS configuration issues, to database connection errors, this virtual assistant can detect the root cause of your problem with only a few questions. In the event that an incident is affecting either part of the OVH infrastructure or its entirety, it will soon be able to direct you to the appropriate task on the OVH status web page so that you can monitor the evolution of the incident resolution process.
Now let’s see what’s hiding under the hood of that chatbot.
The technologies we use
• Language processing
In order for our chatbot to understand your intentions, it must use Natural Language Processing. This NLP is useful to the chatbot to extract the meaning behind a sentence formulated in human language. We’ve used the wit.ai service, which is not only free but also provides a REST API (note that there are a few competitors such as api.ai, [url-"https://recast.ai/"]recast.ai[/url], luis.ai). In short, this NLP engine takes a sentence and ignores any word that isn’t necessary to understanding the intention such as determiners, plural form, personal pronouns, etc. Then, after deleting these words, the system searches for the intention among the remaining words, based on the “catalog of intentions” it’s been taught. In fact, for the artificial intelligence to work properly, a learning phase needs to occur beforehand. For example, the sentence “my website doesn’t work anymore” corresponds to the intention “website_break”. Learning simply consists of feeding the artificial intelligence engine various examples of sentences by matching them to the corresponding intention.
• Communication platforms
Now that our chatbot “understands” sentences from the human language — or at least is able to match them with an intention — it’s time to provide it with a channel where he can communicate with a user. We quickly chose Facebook Messenger because of its popularity. Messenger provides an HTTP API to retrieve various events such as receiving a message, reading a message, logging in, etc. These events are escalated with the help of an HTTP webhook we provide during the creation of the Messenger application on the Facebook Messenger developer interface. Answers are then sent to the Messenger API through HTTP calls. The Slack API works in the same way, apart from a few different concepts in terms of authentication and rights when it comes to the Slack teams.
To reply to the event sent over the webhooks, we need an HTTP API. The one we’ve developed was made in Node.Js.Js using the Express.Js framework and is connected to a MongoDB database as a service provided by OVH. Each communication platform has different routes we have identified on the Slack developer interface and Facebook Messenger. When we receive a sentence, we detect the intention with wit.ai and perform the appropriate processing, notably by searching information on api.ovh.com. All our logs are sent to Graylog using the Logs Data Platform service offered by OVH. This allows us to monitor our service to quickly detect any failure or error on our API.
Here’s an important point regarding this API: for security reasons, Facebook and Slack require it to be accessible in HTTPS. In order to activate HTTPS, we used another OVH service available in beta and called SSL Gateway. This service can speed things up significantly both with the SSL installation and its maintenance (certificate renewal), since OVH takes care of everything. In practice, simply make it point to an IP address and a domain name and that’s all there is to it! SSL Gateway will send an email with the details to enter in your DNS zone so that you can communicate in HTTPS through that domain.
The OVH chatbot code is being open sourced: it’s now up to you!
Using a chatbot to feed you information or answer questions opens up a world of possibilities for us. At this point, everything has yet to be done and imagined. What we want is to develop those ideas with you.
This is why we’ve made the code open source after refactorizing and open sourcing a few internal dependencies. What kinds of contributions are we expecting? How are we going to enrich the project on our side? Find out below.
Since the project’s launch, we’ve collected some interesting suggestions in-house when it comes to increasing the functional coverage of the service and expanding its use. We will soon give our continuous improvement managers - who are spread across all our product departments and constantly in contact with the technical support teams - the opportunity to build a database with new intentions based on recurring requests from users, as well as inputting the appropriate answers.
The use of the chatbot will eventually be extended to all OVH services and, beyond the diagnostic mode, it will be possible to be directed to a guide or a thread from the OVH Community forum when searching for an answer. It will then be possible to replace the online chat available at ovh.com with this chatbot, which works based on a limited amount of pre-saved questions.
What’s more, some Customer Advocates have come up with a way to use the chatbot’s AI to provide some basic sales advice based on customer needs... before offering to schedule a phone appointment to continue the conversation with a human being if needed.
Your contribution is welcome!
Alongside this work done inside OVH (which also includes the implementation of a feedback module in the chatbot that is necessary to the tool’s assessment and continuous improvement), we would like to collect your contributions. Thanks to the provision of the chatbot code in open source under the BSD 3-Clause Licence, you now have the opportunity to add intentions and answers as well as diagnostic ideas. This will apply to all OVH services thanks to the information available in the OVH API. For example, your customers could benefit from using a virtual assistant as a white label solution if you’re a reseller of OVH services, or you could let everyone take advantage of it by offering us your code bits through a pull-request on GitHub.
But that’s not all! Why not come up with a monitoring or alert system that would be based on the chatbot and would notify you about a full disk or a CPU overload on your server? And what if you made the chatbot available on some new applications like Twitter? Don’t be afraid to surprise us... and if you get in a jam while implementing your idea, ask for our help!
Developing your own chatbot?
And finally, as you may have found out in our previous article, this chatbot was designed using standard technical components available at OVH (SSL Gateway, DBaaS MongoDB, Logs Data Platform…). There will soon be a beta version of another component which will make the deployment of your chatbot even easier: Function as a Service. In other words, a serverless computing service capable of executing on-demand computing in reaction to specific events, without your worrying about the underlying resources.
We hope that many of you will attempt to deploy your own chatbot. Because beyond the buzz - a lot of people from various sectors are talking about this phenomena as being revolutionary - it is a powerful tool whose lack of interface opens up an infinite number of possibilities.
It's now up to you!