How To Use Google’s Dialogflow CX For Your Voicebot & Chatbot
An Enhanced Environment for Telephony, Collaboration, Design Canvases And More
Introduction
Currently Google offers three chatbot or Conversational UI development environments; Actions SDK, the familiar Dialogflow ES (Essentials) and the newly added Dialogflow CX (Customer Experience).
In principle, the main differences between ES and CX are:
- Cost
- Collaboration
- Enterprise Orientated: Google Cloud Integration & Cognitive Services
- Design Canvas
- Telephony & Enterprise Integration
Cost
From the two tables below, detailing cost, it is evident that the cost of running CX is exorbitant, to say the least. The only explanation I can think of, is the fact that CX is aimed at an enterprise environment and implementation.
Where ES often serves as a starting point for individual users.
Another element is that CX is much more integrated with the Google Cloud environment than ES.
Audio input and output for CX is priced at more than double compared to text. There is an element of, use the cloud you’re in. Organizations already invested in Google Cloud might default to CX.
Collaboration
CX is geared towards collaboration, where larger groups of developers can work together in creating a virtual agent. There are three levels in a CX application. Within the project, you can have multiple agents, within the agent multiple flows. And each flow with multiple pages or states.
Agent
Within CX you can have various projects. Projects are the highest order of organizing your assistant. Within a project you can have multiple Agents.
You need to think of a CX agent as a company wide virtual agent handling customer interactions. For an assistant the top building block is the Agent. This is analogous to the approach followed by IBM Watson Assistant to have an agent with various skills constituting the agent.
The agent facilitates the conversation with your user. CX will translate the user text or audio into structured data for the flows to understand.
A Dialogflow agent is similar to a human call center agent. You train them both to handle expected conversation scenarios, and your training does not need to be overly explicit.
Flows
Within an agent there can be multiple flows; again, this is analogous to skills in some other solutions; Watson Assistant being a case in point. An advanced assistant will be constituted by multiple conversation topics.
For instance, an assistant for a bank will have multiple complex dialogs which can be arranged according to conversational topics.
These topics can include transfers, forex, bonds, credit card etc.
In turn, each topic demands multiple conversational turns for an agent to acquire the relevant information from the end-user.
Flows are used to define these topics and the associated conversational paths.
The advantage here is that the assistant can be divided into different flows, and these flows can be assigned to different teams or squads of developers.
Pages
A CX conversation is developed and visually represented as a state machine. The states of the conversation is represented by pages.
Any any point in time, in the conversation, one page is the current page, considered as the active page.
Dialogflow CX conversation (session) can be described and visualized as a state machine. The states of a CX session are represented by pages.
Within the page, intents and entities are collected. This is a huge step up from ES. ES really lacks a design canvas to map out conversational paths.
Enterprise Orientated: Google Cloud Integration & Cognitive Services
There are a few reasons alluding to the fact that CX is orientated towards enterprise use. As mentioned before, one is collaboration via the new design canvas.
The second and most compelling is how CX is imbedded and managed from the Google Cloud environment.
For any organization considering a Conversational AI solution, whilst being invested in the Google Cloud ecosystem, CX will be very compelling. Again, cost associated with CX is high, but combined with the total Cloud payment might make it more palatable.
Medium Integration: Dialogflow ES
ES offers the following integration options…
One-Click Telephony
Google Assistant, Dialogflow Phone Gateway, Avaya, SignalWire, Voximplant, AudioCodes
Telephony
Genesys Cloud, Twilio
Text Based
Web Demo, Dialogflow Messenger, Messenger, Workplace, Slack, Telegram, LINE.
Open Source
kik, Skype, Spark, Twilio IP Messaging, Twilio (Text Messaging), Twitter, Viber.
Medium Integration: Dialogflow CX
CX is definitely focused on enterprise telephony based virtual agents. The built in deployment options are:
One-click Telephony
Avaya, AudioCodes
One of the reasons is that in an enterprise environment, standard and one-click integration offered, like in the case of ES, will not suffice.
Enterprises will prefer to have a mediation layer between Dialogflow and the different mediums.
Having the mediation or abstraction layer will allow for customization, and easy of agent propagation. The more control you have over the integration detail, the easier impediments to scaling and introducing new functionality can be solved for.
Dialog Design Approaches
Currently in the market there are four distinct groupings in approaching dialog design and development, they are listed and discussed here…
Dialog Configuration
Dialog configuration is an approach where you don’t quite have a canvas to design on, but conversational nodes are defined. IBM Watson Assistant follows this design principle. For each dialog node conditions can be set and certain outcomes defined. Dialogflow ES also reminds of a more dialog configuration approach together with Microsoft Composer.
Design Canvas
A design canvas environment is part and parcel of the new Bot Society design environment; designs can be deployed to solutions like Rasa, Microsoft Bot Framework and more.
Dialogflow CX leverages this canvas approach where you can map out a complex conversation and expand pages or conversational nodes.
Native Code
Native code makes the case for a highly flexible and scaleable environment. Solutions which come to mind in this category is Amazon Lex, and to some extend Alexa skills.
But especially Microsoft Bot Framework running on native code.
ML Stories
Here Rasa finds themselves alone in this category. Where they apply ML, and the framework calculates probable next conversation node from a basis of user stories.
Dialogflow CX: Intents
The process of defining intents and entities is where most chatbot environments converge in terms of functionality. Categories of user intents are straightforward to setup and examples can be added with entities defined contextually.
The process of contextually defining entities reminds of the IBM Watson Assistant approach.
The color coding of entities is similar to Amazon Lex and Alexa.
Dialogflow CX: Entities
More time needs to be spent on entity types within CX. Suffice to say the entity structure within ES is similar as to the approach followed in CX.
We see the continued merger of intents and entities, and entities living contextually within the intents.
The power of detecting entities with a contextual approach is immense from a conversational approach. Where you do not want users to re-enter information you could not extract.
Conclusion
Perhaps there are factors which adds gravitas to selecting CX as your virtual assistant platform are:
- A voice first approach and not text/chat.
- Existing Google Cloud implementations.
- The power of Google Speech-To-Text (STT) & Text-To-Speech (TTS)
- Collaboration of large teams.
- Ease of hosting.
- Leveraging other Google Cloud Cognitive Solutions.
Detractors are for sure cost and support for smaller languages and vernacular.
Read More Here…
