PRIYANKA VERGADIA: A typical customer service experience
requires multiple conversational twists
and turns to achieve the required outcome.
Stick around to learn how Dialogflow CX simplifies
a complex conversational experience.
[MUSIC PLAYING]
Hi.
I am Priyanka Vergadia, and in this episode of "Deconstructing
Chatbots," we will help our friends at PUggs
understand exactly how a Dialogflow CX
conversation is defined and visualized as a state machine.
Like any e-commerce company, PUggs
has customers that call in for ordering cute dog shoes,
and for returning or exchanging them.
As you can imagine, each of these topics
require multiple conversational turns for the virtual agent
to acquire necessary information for that customer.
That's where flows come in.
Flows are used to contain and control
the definition of these topics and their associated
conversational paths.
Here's how this works.
Every agent is automatically created with one flow,
called Default Start Flow.
Sometimes this single flow may be all
you need for a simple agent.
Look at this example.
Default Start Flow here provides store hours, store location,
and helps place new orders.
But PUggs' case is a bit more complicated.
They have different development teams handling orders, returns,
and exchanges.
For situations like this, agents require additional flows.
In this case, the Default Start Flow
which is automatically created for the agent
leads to the three additional flows for orders, returns,
and exchanges.
So the three teams can manage them independently
and use the Default Start Flow as a single entry point
into the conversation.
Now, if we double-click on any flow,
we find that it's a collection of pages which represent
the state of the CX session.
At any given moment, exactly one page is the current page,
and the current page is considered active.
And the flow associated with that page
is considered active as well.
Every flow has a special Start page.
When a flow initially becomes active,
the Start page becomes the current page.
And depending on where the user is in the conversation,
the current page will either stay the same or transition
to another page.
Now let's understand pages.
Think of pages in CX as web pages.
When we fill the fields in the form on a web page
and submit it, we receive a corresponding response.
Similarly, a page in CX has a form
that is configured to collect information or parameters
from the end users.
This information is relevant to the conversation
state on that page.
Transition routes decide where we
want to route the user from the current page.
Now, let's see this in our PUggs use case in the CX console.
I've created an agent already to explain these concepts.
But don't worry, we will be creating this agent
from scratch in the next episode.
For now, if we go in the Order flow,
we see the Start page, which will become active
when the Order flow triggers and routes
to the Collect Information page, which
collects the parameters shoe size and the color,
and routes the customer to the Confirmation page.
If the user confirms, we end the flow with the End Flow page.
And if the user does not confirm,
then the page routes them back to the Collect Information page
to capture those parameters of shoe sizes and the color.
For more details on the lifecycle of a page,
I've added the links in the description.
The transition routes would depend
on intents, which represents something
our users want to do during a conversation with our agent.
For example, here in PUggs' order flow,
the Start page has a transition route to Order intent,
where we expect the user to provide us
the size and the color of the shoe they want to buy.
Here we also add the multiple training example phrases
for what customers might type or say.
Depending on what they say, the intents
are matched appropriately and the parameter values
are extracted, such as the size and the color of the shoe.
Now, if you've used Dialogflow Essentials,
then I want to point out here that the intents in CX
have been simplified to make them more reusable resource.
Going back to the parameters, they
have a name and entity type.
Entities are used to control how data from the end user input
is extracted.
So here, the @sys.color is a system entity
that refers to color, and @size is a custom entity
that refers to the shoe size.
Now, back to the page for a second.
If the transition route from the page leads to a form
where we collect some parameters from the user,
we need to either do something with these parameters
or provide the user with a response.
In PUggs' case, we call the Order intent
and have the user provide us with the size
and color of the shoes.
Then in the Collect Information page,
we check the condition, if both of these pieces of information
are collected, and only then we route to the Confirmation page.
Until then, we stay on the page to get
those pieces of information.
On the Confirmation page, we actually get back
to the user using the fulfillment.
Here I've added the static text, but this would ideally
be a dynamic text based on the information coming from PUggs'
back end through a webhook.
All right.
So that was a quick summary of how pages and transitions work
in Dialogflow CX, along with a glimpse of the PUggs
virtual agent.
Now that all the foundational information is out of the way,
I am excited for the next episode, where
we will start building the PUggs conversational
experience in Dialogflow CX.
Until then, comment below to let me know
your thoughts on this episode.
[MUSIC PLAYING]