Once we had validated that the existing tools and frameworks will not be able to solve SAP enterprise specific problems, we embarked on a mission to create a framework grounds-up.

Although the mission sounded great, we were wondering, where do you start???

The team agreed that we need to begin with a broad vision and then work our way to refine and fine tune it as we build things and talk to users.

Product Vision - Starting BIG

---

To come up with a product vision for SAP conversational AI platform, the team conducted the following exercises:
- Competitive analysis of vision statements from indirect competitors and other companies.
- Brainstorm and synthesize the vision statement.

Competitive analysis

 

Brainstorming vision statement attributes

 

Product Vision

SAP CAI platform is a comprehensive bot building platform empowering SAP users to build and monitor bots for multiple channels.

It is seamlessly integrated with current SAP apps and systems that enables a flexible, collaborative experience for users to create chatbots to help run business fast and efficiently.

Having this vision statement gave us something to work with. Without this statement, we were shooting in the dark. Armed with this vision statement, our next task was to validate this statement.

User Interviews

---

We wanted to refine the vision statement and also understand user needs around conversational capabilities for enterprise applications. We set out to interview users and ask the following questions:

• What is their vision of conversational AI platform for SAP?
• How do they see themselves using such a platform (if available)?
• What pain points will such a platform solve for them?
• What steps do they envision for building chatbots?

During these interviews, we also asked them to draw, doodle, and sketch to make it easy for them to share their thoughts. We collected a lot of these ideas:

Navigation and Main Menu

---

Based on the stories the team decided to tackle two key features, to begin with.

• Entities
• Intents

To support this effort, the first version of our design was a simple navigation system with the main activity switcher on the left and the breadcrumb navigation on the top.

 

Once the intents and entities were up and running, we started incorporating more features into the application, like Dialog Designer, Deployment, and Testing sandbox.

Understanding Conversations

---

One of the most challenging parts of designing this platform was understanding and designing the visual conversation flows.

The problem with most of the existing frameworks is that it is really hard to design branching conversations. Most enterprise applications have some kind of business flow associated. For example:

   Apply for leave:
	- Employee creates leave request
	- System checks balance
	- Approves or Denies
	- Approval sent to manager
	- Manager approves
	- Employee gets an email confirmation.
	                    

Now that might look like a simple flow, but there is more to it. At each of the steps, the system needs to do multiple things, For example:

   When an employee submits the request:
	- User may provide insufficient information.
	- System may need to request additional information.
	- System may need to disambiguate (eg. which kind of leave).
	- System may need to do transformations (eg. calculate the number of days between given dates).

   Checking balance:
	- System needs to make an API call and process the received results.

   Sending Approval request:
	- System needs to first find out users manager.
	- Then compose and send out an email.
	                    

To further understand the complexities of a branching conversation, we wrote a dialog script using script writing tool.

 

Using this script, we created an interaction flow diagram for this conversation. This gave us a good understanding of the branching conditions and how the users expect them to be handled.

 

Fake it till you make it

These studies were a good starting point, but we also wanted to gain insights from real-life conversations. So I suggested the idea of creating a fake conversation bot which users can chat with. The idea was simple, we initiate a chat session and tell our users that this is an intelligent bot, whereas, in reality, a real person is sitting in another room pretending to be the bot and replying to the questions from the user.

This exercise further enhanced our understanding of how the users expect the bots to work for them. We found some interesting insights. People did not like when the bot always repeated things before taking action, eg. I am ready to book your ticket to NY from San Francisco on 24th July. Should I go ahead and book it?". Instead, they preferred that an action be taken by the bot and if the user finds something wrong, they should have the ability to rectify the mistake.

Variables, Transformations, & API's

---

As our users played with the first prototype, we realized that dialog designer is not as simple as it seemed. Our users were looking for:

How do we use variables in the responses?

How do we define what the bot is expecting from the user?

Is there a way to transform data before proceeding to the next node?

How do you make API calls during the conversation before responding to the user?

Since API's, transformations and variables are intent level activities, we added a panel on the left side of the dialog designer. This would allow developers to manage transformation functions, API settings, and local variables per intent.

 

Variables

Variables in a dialog flow will be used to store response data from the users. These variables can be used as part of the message text response or can be used as part of API URL string or can also be used in transformation functions. Here is an example of how developers can add variables and also use them in dialog designer.

 

Transformations

Transformations allow developers to run custom function to perform transformation on a set of variables. A very simple example would be, a user has provided start-date and end-date and the system should now find out the number of days between the two dates.

Our users also requested that whenever they would write such transformation functions, they would like to do a quick check to see if the function is performing as expected. Hence we allowed the developers to quickly test the function on the fly.

Here is how the developer can define these transformation functions.

 

API's

During the conversation, the bot may need to fetch additional data before continuing the conversation. For example, the bot may need to check if the user has enough leave balance before approving or rejecting the leave request. Do do this, the bot needs to call an API, pass some values to it, and process the response. The values from the processed response are stored in dialog level variables.

To allow the developers to do this, we divided the task into two parts. On the side menu, the user sets the API URL and authentication method. To consume the API, the user selects the API node from the dialog designer.

This is how it works

These functionalities were really appreciated by the end users. By this time parts of these designs were already getting implemented and we were now able to use them in real-world situations. API functionality was the first one to be built and tested. As the developers started using it, we received feedback that in many situations, the number of features we had provided were not enough. For example, in the current design, there was no way of sending additional header information to the API call. Secondly, the current design only allowed typed Key/Value pairs to be sent.

One of the engineers on the team came up with a great suggestion.

He notices that current design receives response values from API call, stores them in a local variable and then the developer has to use transformation function using those values and again store the results in another variable. So instead of doing so much work, what if we used transformation functions within the API node and store the results of transformation straight into a local variable.

This was a brilliant idea and would save a lot of developers time. So we started incorporating this change in the design and very soon realized that when users added multiple headers and transformation functions, the modal window became very complicated. So we decided to go for progressive disclosure of information and created an API node wizard. Here is how transformations can be used in the API wizard.

 

A quick video of the API wizard.