Hackfest leads to improving customer service for AON using the Bot Framework

Aon is the leading global provider of risk management, insurance and reinsurance brokerage, and human resources solutions and outsourcing services. To effectively manage inquiries from Aon’s customers regarding common frequently asked questions, a bot was designed to facilitate this need. Using Microsoft Azure Web App Services to host the bot application and the Microsoft Bot Framework to provide the communication channel between the client and Aon back end API’s, a solution was created to solve this problem during a visit to the Microsoft Chicago office by members of the Aon Development team and the Microsoft Developer Experience team.

Key Technologies Used

Core Team:

  • Vlad Keselman – AON, Systems Engineer
  • Kent Devine – AON, Developer
  • Rohit Masthipur – Microsoft, Cloud Solution Architect
  • Joshua Drew (@jdruid) – Microsoft, Sr Technical Evangelist for Startups

Customer profile

Aon is a global company with over 72,000 employees working in more than 120 countries. They are the global leader of providing risk management, insurance and reinsurance brokerage along with human resource solutions and outsourcing services.

This Chicago based team is focused on health insurance plans for retirees and wanted to further improve the customer service process when it comes to their client’s access to their portfolio and online systems.

Problem statement

The Hackfest kicked off early in the morning with an overview of what the team can do with the Microsoft Bot Framework and adding intelligence to the bot with Microsoft Cognitive Services. Since this Hackfest was happening over the course of two days, we wanted to make sure we could finish something that we started as well as can demo the solution back to the business for further discussions on developing more features to the project.

We looked at a few different solutions, ranging from internal ticketing to service requests but we landed on a bot for consumer portfolio requests. Aon Developer Kent Devine said, “my group focuses on helping our customers find the best health insurance plans for their personal needs and having a bot handle some of the standard, front-line questions would be extremely helpful before we hand those questions over to our service reps”

Solution Overview

The solution was to provide a Web Chat as the interaction point for the Bot and Aon’s customers to use when visiting the Aon retiree website. This bot would prompt the customer for scenarios that required more information. The customer would input their selection along with some common customer information and the bot application would retrieve the info from either Aon’s content management system or their customer management system.

Technical Delivery


The first step was to make sure the development team was up and running with the proper tooling. We needed to make sure the development environment was running Visual Studio 2015 or later to start building our Bot. The Bot Framework is just a ASP.NET MVC Web Application at the heart of it, but adding the Bot Framework project template, Dialog and Controller classes make the development go a bit faster.

Once we had the Visual Studio portion set up we also needed to download the Microsoft Bot Framework Emulator. The Bot Framework Emulator provides the ability to test your bot application locally as it would if it was being called by the Bot Framework Cloud Service.

The Bot Framework has a portal where you can configure your Bot Application for publishing. We did not need this early in the project but when we want to demo the project we would need to configure the application (more on that later).

We also signed up to access the Microsoft Cognitive Services, we plan to use the Language and Understanding Intelligence Service as a part of the Bot application.


We architected our Bot to use prompts to guide the user through the application. We also created a service controller that will call external files to bring in the appropriate responses based on the customers input.

We used this service oriented approach during the Hackfest to not only provide the appropriate data to be returned to the users but also as a starting point to build other services that might pull in data into the bot (existing Web CMS, Customer Profile DB, ECRM).

The first step of the development process was to setup a new project. We did this using the Bot Application template but we could have easily added this Bot application into an existing solution.

From Visual Studio, Choose FILE > NEW > Project > Templates > Visual C# > Bot Application.

The template stubs out the basics of the Bot.

  • Controllers/MessageController.cs – API endpoint for Bot communication
  • Web.config – App Settings for Keys for the Bot

Running the application will pull up a default.html page. Since we need the Bot Framework Emulator to communicate with the bot we will take note of the host and port name and add that to our Bot Framework Emulator during local testing.

The “hello world” style of the application will just echo back the number of characters you type in. If you view the MessageController, you will see the code within the Post method.

We will change this since we will not be coding our logic within this method, we will be using a notion of Dialogs. Dialogs will help provide the conversational aspect of interacting with the bot. The messages will be exchanged between the client and the Bot and we will provide logic based on some of the responses.

To wire up the Dialog we need to do the following: ADD > NEW ITEM > Visual C# > Bot Dialog. We call this RootDialog since we will be spawning child dialogs later.

We then can go back into the MessageController and in the Post method and we can remove the code within the if statement with the following:

This will launch the Dialog when we interact with the Bot.

We can jump back into the RootDialog file and we can start building out our conversations. However, if we read our code the post message will instantiate the RootDialog and run the task StartAsync. Within the StartAsync method the program is waiting for a prompt or message coming in from the user. This means the user experience would be the user connected to the Bot must start the conversation, we want the Bot to initiate the conversation. To do get that running we need to change a few items again.

Back in our MessageController Post method we can replace what was currently there with the following:

We are now allowing for the Dialog to kick off once there is activity. Then in the RootDialog we then can start building our first prompt to greet the user.

We decided to mix the use of different Prompts for this project. since the user will be interacting with the Bot differently during the process. The first prompt is a Prompt String. This takes in a “string” from the user and stores it in the activity that is passed into the resume method. The Prompt String is great for taking in a user name, customer id or other type of text.

However, your application will need to have smarts to either validate or parse the data that comes in. Prompt Choice is another type of Dialog prompt that we use to guide the user into a specific choice. We are using a String List of the options of Status, Claims, Appointments and Reimbursements. The user will be prompted with a UI of controls they can click on if they are in the web view but they can still type in their choices.

We opted to build a RootDialog that will control the main Dialog flow, but we will be using sub Dialogs for each of the options. We opted this route for easier maintenance and for upgraded the Dialogs to a LuisDialog when we add in the Cognitive Services aspect.

In our resume method, after we take in input from the first prompt, will with then issue a “context.call” to call a child dialog and add it to the top of the stack.

There are a few different ways to call child dialogs

  • Call – calls a child dialog and adds it to the top of the stack and then resumes to a method when the child dialog has completed
  • Forward – like the call method, but this method can post the item over to the child dialog Using the IDialogStack.Call and/or Forward is an explicit way to manage the dialogs and you can remove them by calling Done.
  • Chains – However, there might be times where you want to manage all the dialogs that are active implicitly and use Chains to manage this. Using Chains, it provides more of a LINQ style way to find Dialogs and manage them .

Within these child dialogs, we add in some logic to determine if the user is an active customer, if they are we then call our services to perform some additional data query.

The one item to note, is when we are done with the conversation within the child dialog we need to explicitly call Done to move back to the RootDialog and pick up the conversation there.


We are able to test our Bot locally with the emulator but for the public to be able to communicate with the Bot we needed to move it out to a public location. We were able to host this Bot on Aon Azure account under a Web App Service.

We first created a Azure Web App Service from within the Azure Portal by clicking NEW > Web + Mobile > Web App

Since we were already on the Aon subscription, we just needed to create a Resource Group for our project along with creating a new App Service Plan

After we gave the application a name we were ready to move the code out to Azure. This can be done in several different ways from FTP to using Visual Studio Publish tools. We chose to deploy from our local Git Repository. In your App Service app’s blade, click Settings > Deployment source. Click Choose source, then click Local Git Repository, and then click OK. After adding some credentials we were provided our Git URL. We then used git remote to add a reference and able to push our code out to Azure.


The Aon Customer Service Bot will serve multiple purpose for everyone involved.

  • It solved a real problem where customers wanted access to information regarding their account in a timely manner.
  • It also provided Aon a blueprint for building bots in other areas of their company.
  • The Aon Development team could use existing tools and skill set to build a bot quickly and deploy rapidly through their Azure subscription.

“We were happy to participate in Microsoft’s Hackfest. We knew about Bots and have implemented Bot services but have not developed Bots. This Hackfest allowed us to code and build a custom bot for a real problem we are facing” said Kent Devine, Aon Developer.