Conversational Intelligence – Business Case Study with Dialog Flow

Introduction

Artificial Intelligence is playing a key role in providing automated and quick services for users, especially for functions like customer service, across all verticals. Conversational Intelligence using supervised machine learning techniques is allowing users to make a really quick and helpful experience—in some cases, more so than opening an app or website. A conversational experience allows for that personal approach. It brings warmth and personality to conversations with the users.

This article provides a technical case study detailing the approach how Zencode Solutions helped an enterprise service provider to build rich conversational agent using Google Dialog Flow powered by Google Action SDK, integrating with third-party support systems and using automated push notifications based on user permission.

Business Situation and Challenges

The enterprise service provider helps their customers to provide home assistance services like plumbing services, cleaning service, electronic device repairs, etc. The customer support team receives an extremely high number of requests for electronic device repairs request ranging from air-conditioners to laptops, via different channels like Facebook Chat, emails, phone calls, etc. When the request gets raised by the user, a human agent from the supporting ticketing system may or not be available; hence the whole process becomes offline, resulting in a bad user experience.

Only when the agent becomes online/available, they see the requests by different users and can start speaking to the user (if available), then creates a support ticket, updates with details for the technician and available timings, confirms with the user, sends a notification and closes the tickets on completion of the repair work. The overall process is extremely people intensive, non-scalable, understanding the huge volume of request requests and hence and tight response time. Generally, the Turn-Around-Time (TAT) is way beyond SLA. Also, there is a high cost of training ad-hoc support resources as part of the Customer Support team.  It has been a semi-automated process in terms of data management and communication to their users.

A solution needed to:

1. Provide 24*7 support to end user
2. Conversational and better user experience
3. Reduce the SLA time
4. Lower the cost of operations

Approach

Zencode Solutions determined to innovate and keep pace with ever-changing consumer behaviour; building rich conversational experiences powered by natural language understanding (NLU) and machine learning.

Smart Service Advisor, powered by the Machine Learning Team of Zencode Solutions would help registered users to get authenticated via Google assistant enabled phones, request for services related to electronic device repair, at any point of time, answered online. At their core, Service Assistants are software services that engage in automated conversations with users in self-service environments.

Following functionalities were provided as a part overall solution

1. Registered Users were synced up with the application backend
2. Users would be triggering the service advisor from their Google assistant enabled phones.
3. Users would be authenticated with necessary credentials when asked by the service assistant.
4. The user would converse with the smart advisor and provide details regarding the request
5. The request would be accepted, invoking the application API, invoke the third party customer system creating support tickets.
6. Smart Advisor would request user if they would want to get notified about notification about tickets
7. The human agent would be able to notify users via the same channel (user enabled phones) about any updates in the ticketing
8. The smart advisor would accept all requests, not only for specific identified/trained use cases. All the other requests would still create support tickets, helping agents to understand what kind of queries us being requested, thus helping to build and train these use cases over a period of time.

Smart Service Advisor empowers consumers on their journey for answers and task completion by simplifying the process of information delivery in multiple channels, including the online website, mobile, and social environments.

Smart Service Advisor is often the first point of contact between a customer and an organization and excel in guiding customers toward the information they need, in a way that is fast, efficient and enjoyable. The smart advisors do all of this at a fraction of the cost of human-assisted service and they deliver a combination of benefits that businesses just can’t get from live support channels

 Technology Concept

  Technical Architecture

Before we started using Dialog Flow, Zencode Machine Learning Team investigated several competing technologies. We recognized the pros and cons of many of them and decided on Dialog Flow. The team had three main reasons for choosing Dialog Flow:

1. Quick and easy to start: The team saw nominal effort and coding needed to get their conversational experience up and running.
2. Good developer experience: The intuitive development environment allowed the team to easily choose how the experience should look, feel, and sound.
3. Easy to scale: The experience would be able to scale well as the user base grew.

Implementation Details

Agent Creation & Testing

1. Using Google Dialog Flow, creating an agent with necessary intents pertaining to the electronic repair use case. Parameters were defined to accept the values like what electronic device, what type of issues, details of the device, timing selection, etc. Prompt was enabled for mandatory questions, also with an option to enable optional parameters webhook was enabled, only when the conversation is complete.
2. Define granular entities like laptops, television, air conditioners, etc.
3. Define authentication intents, enabling the webhook for authentication check; also a context specific to auth that will be used as input context to other intents, essentially making sure that queries are being answered for requests that are only authenticated.
4. Create intents general appreciations, greetings, valedictions, vague and very generic questions
5. The fallback intent, which comes as default, is extremely useful for getting requests/queries which are not trained/curated. We have enabled webhook to create support tickets in the backend, making sure the data is persisted, provide a better user experience, and understand over a period of time, what kind of use cases can be built and trained later.
   1. User receives a response in such case: “Although we are currently serving bookings for electronic repair devices via this channel, but we understand you need something different, we have accepted your request and our agent will get back to you as soon as possible”
6. Created three specific intents for notifications and webhook is enabled for all of them:
   1. Notification: This intent is used to be configured in Google Actions, based on user permission for this intent, user will be notified. This setting is a must for Google Action SDK to handle push notifications.
   2. Setup Push: This intent will be trained with certain training examples like: “Please notify me”, “Notify me” and will be used to update the permission of the user (using a user storage object) Sample code in the backend.
   3. Finish Setup: This will provide the user with an update response, “Ok I will start alerting you”

The notification intent will be applied automatically to all the intent (business relevant intents like electronic_repair for that user. That permission is updated in the user table in the backend

API Management

1. The API has been built using Python Django framework. The important modules built here:
   1. Authentication Check with Database
   2. Request Persistence in DB
   3. Third Party API invocation
   4. Handling User Permission for Notification
   5. Synchronization of user DB from Registration system (by invoking third party API) into Database. This triggered via a cron job which eventually calls DJango Rest API
   6. Receiving information via an API when a notification is actually being sent from an external system, back to the same channel and device.

Push Notifications

Sample code of the API for handling setup_push notification:

if (intentName.lower() == 'setup_push'):
resp1 = {
"data": {
"google": {
"expectUserResponse": True,
"richResponse": {
"items": [
{
"simpleResponse": {
"textToSpeech": "PLACEHOLDER"
}
}
]
},
"systemIntent": {
"intent": "actions.intent.PERMISSION",
"data": {
"@type": "type.googleapis.com/google.actions.v2.PermissionValueSpec",
"permissions": [
"UPDATE"
],
"updatePermissionValueSpec": {
"intent": 'Notification'
}
}
}
}
},
"contextOut": [
{
"name": "_actions_on_google",
"lifespan": 99,
"parameters": {
"data": "{}"
}
}
]
}
return Response(resp1)

Sample code of the API for handling finish_push notification:

if (intentName.lower() == 'finish_push_setup'):
res_start_alert_you = {
"data": {
"google": {
"expectUserResponse": True,
"richResponse": {
"items": [
{
"simpleResponse": {
"textToSpeech": "Ok, I'll start alerting you."
}
}
]
},
}
},
"contextOut": [
{
"name": "_actions_on_google",
"lifespan": 99,
"parameters": {
"data": "{}"
}
}
]
}
response_json = req
action_name = response_json['result']['contexts'][1]['name']
if (action_name == "actions_intent_permission"):
permisssion_status = response_json['result']['contexts'][1]['parameters']['PERMISSION']
print(permisssion_status)
parameters_len = response_json['result']['contexts'][1]['parameters']
print(parameters_len)
uuid_val = response_json['originalRequest']['data']['user']['userStorage']
data = uuid_val.split("'")
print(data[1])
if (permisssion_status and (len(parameters_len)) == 2):
# code for update userID
print("inside if block")
vals = []
user_ID = response_json['result']['contexts'][1]['parameters']['UPDATES_USER_ID']
print("data")
print(data[1])
print(user_ID)
uuid_data = data[1]
intent_name = "Notification"
updates_id = user_ID
push_permission = "yes"
try:
db = MySQLdb.connect(unix_socket=config.unix_socket, user=config.user, passwd=config.passwd, db=config.db)
c = db.cursor()
c.execute(
"""INSERT INTO updated_userID(id, intent_name,updated_id, push_permission) values(%s, %s, %s, %s)""", (uuid_data, intent_name, updates_id, push_permission))
# Bulk insertion
c.close()
db.commit()
except Exception as e:
print("Error storing user details: ", e)
return Response(res_start_alert_you)
else:
print("inside else block")
return Response(res_start_alert_you)

Deployment Methodology

The agents need to be tested at a unit level using the Google dialog flow integration settings page using the device of your choice. We used phones, for our requirement.

Alpha & Beta Testing

1. It is extremely important to have this released to alpha users, around 20. Send an email to the users, to get early feedback. The users, when clicked on the link, will receive a notification on their Google assistant app. On their phones and can try out easily
2. Based on early feedback form alpha users, beta testing needs to be implemented, for 200 users, post that submits it for production, to be available publicly.

This is provided in the Releases Section in Google Actions Console.

Google App Engine

The complete backend, APIs and database are deployed using Google app engine. This deployment technique will help, since:

1. Will automatically handle and balance all instances and data centres for web applications
2. Provides support for 4 popular programming languages: PHP, Python, Java, and Go
3. Will automatically scale data storage or instances to meet the needs of the programmer
4. Provides App Engine SDK to produce applications locally
5. App Engine can be integrated into multiple IDEs
6. Has a secured Internet Infrastructure to store code and application data safely

Challenges

• Dialog Flow 

• • Integration issues with Google Assistant 

                  Conversation Enablement for GSuite:

    • For personal gmail accounts, the Web&App activity, when turned on, it automatically gets enabled.
    • For gsuite accounts, even when the Web&App activity turned on, it needs to be enabled by the admin of that organization. Only after when it is enabled, the simulator will behave as expected.
    • https://support.google.com/a/answer/6304876 (Web & App Activity needs to be enabled by Admin account for GSuite)
    • App Invocation: https://myaccount.google.com/activitycontrols
  • Webhook Integration
    • The service must use HTTPS and the URL must be publicly accessible. Refer: https://dialogflow.com/docs/fulfillment

• DJango Deployment (Python 3.5 & higher) of App Engine with https support

  • https://cloud.google.com/python/django/flexible-environment
  • https://cloud.google.com/appengine/docs/flexible/custom-runtimes/build#listen_to_port_8080
  • https://cloud.google.com/appengine/docs/flexible/python/configuring-your-app-with-app-yaml

Key Benefits

Consumers can use the Smart Service Advisor to ask questions related to services for electronic repairs, but not limited to that.

• Automated rich conversations with users in self-service environments
• Seamless Integration with any device/channel supporting Google Assistant like Facebook, Cortana, Skype, etc. which can be extended.
• Simplifying the process of information delivery with 24*7 Availability for Consumer Queries
• Lower cost of training operations

Conclusion

Zencode Solutions Machine Learning Team began working with Dialog flow, we were able to move so quickly that we met or exceeded every milestone or goal. The implementation was efficient because Dialog Flow was easy to train people on and easy to use. The smart advisor efficient surpassed original expectations, but innovation at the enterprise service provider is a continual process. They recognize the importance of improving and fine-tuning the conversational experience to meet their customers’ needs.

About the Authors:

This article has been jointly contributed by Anshuk and Kartick.