PRIYANKA VERGADIA: Hi.
I'm Priyanka Vergadia, and in this episode
of "Deconstructing Chatbots," we will
continue to help the pulse team extend their single-flow agent
into a multi-flow agent that can handle not just orders
but also returns.
We will also see how they can manage multiple agent versions
and deploy to different environments.
[MUSIC PLAYING]
Before we dive into the console, let's lay out the Use Case
requirements first.
Most of Puggs's customer requests are of three types--
orders, returns, and exchanges.
Each of these requests have their own conversational twists
and turns and three different teams that manage those.
We recommend Puggs to create three separate flows
for these requests.
Multiple flows allows different teams
to be responsible for building and maintaining those flows.
And they provide better conversational control,
help scale quickly, and they don't
incur any additional cost.
We already created the order flow in the previous episode.
If you haven't watched it, it is linked below.
Stop and watch that one before continuing here,
because this is going to be the extension of that episode.
We will be creating a return flow
so Puggs can take return requests through the Virtual
Agent.
We will keep the flow simple by just collecting
the order number and providing a return confirmation.
So now that we know what we are building,
let's head to the Dialogflow CX console.
Let's continue working in our Puggs project.
Add two flows to it for return and exchange.
In our return flow at the start page,
we define our transition route to order.return intent,
which will understand the user's intent.
Add a few examples of training phrases,
such as I need a refund.
I would like to return my order.
Add a few more along the same lines.
And before saving this, let's add the transition to a page
to collect return information.
In this page, let's ask the user for the order number.
I've provided a few examples here.
To process a return, we need the order number,
so we will make that as a required parameter.
And for now, let's just select a system entity number,
although in real life, Puggs would probably
have a custom entity with a certain sequence of numbers
that would be matched to their back end through the web hub.
At this state, we check if the order number is
received by adding the condition,
page.params.status equals FINAL.
Once the condition is met, we want to transition
to another page to provide a return confirmation.
At the return confirmation page, all we do
is send a confirmation saying your return is processed,
adding our session parameter order number
in there using the dollar sign.
And we transition from here to the end page.
Although we could transition to another flow as well if you
wanted the user to, say, take a survey or order more things.
There's a lot more that you can do in returns,
you could add more parameters to collect,
connect to the Puggs' back in API.
But I will leave that to you to explore,
since the point of this video is to get you familiar with the CX
console and the concepts.
Now, we know that Puggs has multiple teams working
on the flows.
They need the ability to save progress
by creating different versions and then
deploy specific versions of their flows
to development, testing, or production environments.
Let me show you how versions and environments work
in Puggs agent.
We go to the Manage tab and in deployment we find versions.
Now here, since Puggs has multiple flows,
each flow can have its own version
so the teams can independently manage their own versions.
Versions are snapshots of the flow data
and associated agent data like intents, entities, web posts,
pages, [INAUDIBLE] groups, and a lot more.
Now, if we click on a flow here, let's
say return, create a version.
Give it a name and description and give it a few seconds
to become ready.
And if we want to use this version,
then we can just load it in our drafts load
by clicking on this button.
But let's make another version so we can actually
see these changes.
Say in this new version, we made a change to our entry dialog.
Then, go to the versions and load a previous version.
We see that the change we made is not there
anymore because we are now working in an older version.
So that's how versioning works in CX.
Now as a best practice, Puggs obviously
wants to separate their production and development
environments to make sure the development can keep going
while production is stable.
To do that, we go to environments and create
a new environment.
Let's say production in this case.
And we select the corresponding flow versions that
should be used in production.
We can do the same to set up dev and test environments too.
Now, once environments are set up,
make sure you are testing things in the right environment.
In the simulator, you can select the environment
and the corresponding flow.
If you're using the API, pass the environment ID
in the URL like this.
Otherwise, it uses the default environment,
which is your draft flow.
All right.
With that, we have created a multi-flow agent
for Puggs's team that takes orders and returns.
We also learned how versions and environments
work in Dialogflow CX.
Now, it's your turn.
Design the third exchange flow for Puggs's team
and share your experience with me in the comments below.
[MUSIC PLAYING]