This is another blog post of a series around the enterprise mobility IT team at SAP. We are an internal team focused on managing mobile devices, mobile applications, and developing custom apps for SAP’s 100,000 employees. I have been a part of this team for the past six years and believe we have some unique stories, software, tools, and insights to help others in the community considering, or currently undertaking, some of the challenges which surround mobility and its adoption in the enterprise.
This post is also a follow on to the post about SAP Relay, our internal realtime chat application, if you are interested reading that post might provide some context.
Conversational UI
In 2015 & 2016 when conversational UI’s became a hot topic, we developed integration options and support for Bots in Relay. Conversational UI’s are designed to provide a simple and conversational way to interact with systems. For reference, Chat bots alone are not considered conversational UI, but it is rather a culmination of a Chat Interface, Bots, NLP and AI. During this time we had just started our implementation of Slack at SAP, so instead of developing something proprietary and closed, we decided developed a bot platform which would support a variety of chat applications. By building a platform rather than a point solution, we positioned ourselves as enablers rather than creators in the space and encouraged our business partners to use our tooling to develop their own bots. We forked Hubot (originally a Github project), developed some integration components and a few simplistic scenarios around some ideated business use cases. Some of which included: A vacation bot: “Take today off”, “how much vacation do I have left”; A person bot: “Who is Paul Aschmann”; Github Bot for push, pulls and commits, IT Help Bot for chat support before creating a help ticket; A Downtime Bot for periodically checking critical systems availability. A few others were more generic like Weather, Inspiring quotes or Trivia. We did recognize some unique benefits to bots for simple scenarios, as it can be rapid way to deliver innovation:
- No UI to develop (Truly responsive?)
- Nothing to install for end users (Pending they have your chat app)
- Managed runtime platform
- Available from multiple platforms/clients via an existing client (in our case, Relay)
- Fast development and delivery iterations due to decoupled components
- Reduced development costs due to above points
We also recognized some unique challenges early on with a enterprise scenario around security and authorizations … how do we propagate a users request through a bot, and their credentials from a chat client, which is a hosted webapp and to a on-premise backend system, or in some cases, multiple systems? To solve some of these challenges, we developed a completely stand-alone authentication gateway which supported SSO and user certs, which was a fairly large effort. In addition to the security aspect we also found some interesting challenges:
- A complete corpus of training/learning text for enterprise is scenarios is quite difficult to find.
- Conversational UI is still relatively young, making it hard to decisively pick components.
- Catering for multiple languages is not easy in a multi-national company.
Conversational UI Component: Chat Interface
In our instance our custom developed real-time chat application, Relay was our UI. We modified our server REST APIs to support additional calls for bots. On the front-end we implemented the concept of a Card message type. We had a variety of others types including Text, Image, Location, Document, Audio, File and Events, but in order to better format responses from our bots, we developed a an additional type which gives bot developers the ability to return an object based message to the system and have some guarantee that the Client UI would render their content as expected and in a rich, and visually appealing way.
Mockups
Implementation
Our custom UI controls which we implemented to support JSON based response message types allowed developers to send messages which were formatted client side and drastically improved the UI experience of our bot responses.
 |  |
| Before | After |
Conversational UI Component: NLP
We tested multiple NLP services and initially implemented API.ai, but after doing some POC work, we did not want confidential information leaving our our control and company network. This lead us to RASA, a on-premise and self hosted AI and NLP solution which we found to be perfect for our scenario. Keep in mind, this was prior to SAP acquiring Recast.AI. If you do use RASA, check out a small Admin tool I wrote for it in my spare time called RASA UI on Github.
Some of the core components of NLP are listed below. [Source: https://www.hackerearth.com/blog/developers/natural-language-processing-components-and-implementations/] and might be a helpful primer if you are considering implementing Bots in your enterprise.
Entity extraction
Entity extraction involves segmenting a sentence to identify and extract entities, such as a person (real or fictional), organization, geographies, events, etc. NLP APIs use online data from sources like Wikipedia or other repositories to match these entities.
Syntactic analysis
Syntax refers to the proper ordering of words. Do the words you’ve put together form a “correct” sentence? It deals with the structural roles of words in the sentence. And then you use a parsing algorithm to produce a “tree,” which gives you the syntactic relationships between the constituents according to context-free grammar.
Semantic Analysis
After a sentence is parsed to extract entities and understand the syntax, semantic analysis concludes the meaning of the sentence in a context-free form as an independent sentence.
Sentiment Analysis
Once the syntactic and semantic analysis has been completed, we try to understand the sentiment behind every sentence. Sentiment will include emotions, opinions, and attitudes. We are talking subjective impressions and not facts.
Pragmatic analysis
If you go to your editor and ask her to suggest a better sentence structure for a line, her immediate question to you will be, “What’s the context?” Most of the time, due to flexibility of the natural language, complexities arise in interpreting the meaning of an isolated statement. Pragmatic analysis uses the context of utterance—when, why, by who, where, to whom something was said.
Failure Management
Failure management is extremely important in chat scenarios which is often overlooked. An NLP algorithm with 80% accuracy fails on average 1 in 5 times, and for every failed interaction, could break your user experience. The purpose of a bot is to simplify a specific process. If users are using your bot, failing and then subsequently using a manual method to successfully complete the task, you are essentially making them do double the work. Current APIs do not provide significant support for actively managing failure scenarios during the conversation, so it is important to recognize when these instances occur and attempt to fail as gracefully as possible. We have learned a few things writing usage scenarios for our bots:
- Structured responses are easier to comprehend
- Simple messages which are Short and Sweet
- Variety is the spice of life
- Conversation Trees are helpful when building a chat user
Summary
We recognized that our mobile app portfolio already had a lot of the information being requested through the bots, and using the app was sometimes easier or faster. While natural language processing has come along way, the discovery, education and constant flux of changes being innovated on, it can be difficult to educate the user base on yet another information access tool. Our Bot platform did not make it much further than some basic POC’s and while it was fun to demo, we had other tools in SAP pop up which became more popular – one was Tobi. After SAP’s acquisition of Recast.AI we quickly decided to sunset our platform in favor of using it.
