Hoy, el tema fue pensar en la conversación y cómo construir
realmente conversaciones en este caso.
Me ayudaré, mi nombre es José Luis.
No estoy codiando directamente, pero estoy ayudando a manejar
el equipo de IT, el equipo de desarrolladores y también
vinculando con el cliente, así que escuchando desde el mercado
lo que los compañeros están buscando,
especialmente para Airlines, que es nuestro equipo principal
y core de negocio.
Alejandro.
So, mi nombre es Ale, en parte de la idea de la identidad
para el cadávero.
Y me voy a apoyar, por favor, en el escénico y el tópico
de cualquier cuestión de animación que hay en la presentación.
¿Cómo me voy a hacer la presentación?
¿Cómo me voy a hacer la presentación?
¿Cómo muchos de ustedes saben lo que es un chatbot, Raisa?
OK.
No, no, no.
Keep it up.
Down, the ones that have not interacted with a bot, never.
And developed a bot.
So, we will try to keep it both technical, but also
informa general knowledge, bro.
This is how we are feeling right now, because we have at
least 50 people looking at us, taking notes, recording.
And it's not that we feel like superstars, but it's a
bit impressive.
So, we really would like to keep it down.
We would really like to have it both ways and establish a
conversación.
You will see that the presentation in short, it's
going to be high level, inspirational, with some
technical details.
You won't see any line of code, just to
manage your expectations.
If you want, then we can arrange in our workshop, you can
even pass by the office and take a look at everything.
But we thought that it was better to first engage a
conversation, show our experience, and then go deep
dive into the coding.
What do we do?
Why we are here?
We are at Caravello.
We built software for airlines.
And the latest development is airline concierge, airline
assistant, airline chatbot, you name it.
Agents that are available 24-7 in all languages, in all
channels, et cetera.
So basically, we are behind this opportunity, building the
time being, I think it's around six chatbots for the
airline industry.
Grasping a bit what is a challenge about and how we
have built the platform, multilayered, business as
usual, but thinking about the challenge that we are
facing, which is mainly serving airlines that are global
and also a bit special.
We have had the opportunity to build a platform that will
support the growth of the servicing, no matter the NLU.
So in this case, we are not developing NLUs, natural
language understanding and processing.
We are adopting existing solutions.
And also, we are not being tied to one solution.
We need to be adopting more.
Reason why is because most of the airlines operate in more than
one language.
And as we take as an example, a North European carrier, it
will operate in Russian, Finnish, English, and maybe
Spanish.
So if you try to implement NLU that understand these four
languages, you are dead.
So this was one of the reasons to consider building a
platform that will support more than one natural language
understanding or processing.
We have our dialogue engines.
Again, depending on the carrier, you will face that some
has European or American presence, in other words,
messenger, but others has Asian presence or being relevant
line, we chat, et cetera.
Then on top of that, we build what is the business layer,
which is the purpose of our chatbots, which is basically
industry specific, where every airline can customize their
own specifications, and do the basic.
If you think on an airline con search, it will help you
search flights, book flights, and do the typical
management booking, at the back, flight status, all the
functionalities that are made for the travel industry.
Then we have the link, which for us is the layer where we
interface with all the relevant systems.
The chatbot, by its own, it won't be useful unless it
connects with an airline system and performs a purchase, a
change of the booking, et cetera, payments, accounting.
So this is, for us, the layer that interacts with all the
additional services and systems that we need to carry out
from airline specific to our own specific systems and
services.
And the latest is all the reporting, analytics, logs,
all the support to the business.
That add value at the end for understanding the real usage of
the platform and the bots, as well as the security and the
management of the platform.
But talking about technology, we have built this on top of
the Docker.
de la conversación en el interés.
Es básicamente, Ignacio Neo es
una separación de consensos,
como puedes tener en la botella,
por ejemplo, que tienes en el interés de un lado,
el sistema de la comunidad y la comunidad de las comunidades.
De nuestro lado, desde el lado de la empresa,
una de las más importantes cosas
fue el tiempo para el mercado.
Así que es por eso que tomamos la decisión
para adoptar todo o parte de las soluciones existentes.
Y como detalle, estamos ahora considerando
usar otro bot, analíticos, bot métricos y softwares
para complementar lo que tenemos que dar a nuestros clientes.
Nuestro objetivo, y esta es parte de la verdad,
parte de la aspiración,
lo que tenemos ahora es aquí,
tenemos 4, pero tenemos 6 botes en producción ahora mismo,
y la filosofía y el propósito de la arquitectura
es para eliminar las bandas diferentes,
así que quiero buscar simple,
buscar calendarios, precios, familiares,
todos los especificos de nuestro negocio,
es muy fácil de placer y jugar,
es muy cómodo,
para poder deliberar la experiencia
sin embargo, el canal, en diferentes canales,
customizando la interfaz de usuario,
no solo las imágenes, pero los colores
y ciertos elementos que los diferentes canales
permiten customizar.
Y, por supuesto, usando diferentes puestos y sistemas,
estamos ahora platicados en Naviter,
que es un sistema de reservación,
pero también en las capacidades de NDC,
que son los especificos de airline.
Pero, de nuevo, en short,
nuestro camino es para construir una plataforma de nivel de peso
que todos los airlines pueden customizar
para construir el chatbot que quieren.
Entendiendo que todos están
viajando en el mismo domenio,
airline específico.
Entonces, ahora sobre todo lo que entendimos,
sabes quién somos, por qué estamos aquí,
taking advantage of the latest F8,
where we wanted to share our opinion
on the latest conclusions
and also built on the idea
of what is a truly conversational boat
or where are the boats heading.
Here we have one of the top managers,
BPs, in charge of the messenger and the boats,
and he is saying that at the end,
what we really need to understand
is beyond the hype,
the boats are not going to replace the apps.
They are simply going to be
doing things very different
or they are going to be very different.
And this is something that we have noticed so far.
We have the real perception that at the end,
this is going to be an evolution.
If the evolution means that you share
kind of the same origin,
we totally agree,
but at the end we are going to be building
different species with different context.
And if you take a look at reality,
while having the same customers
with three different experiences,
we will see that not only the webs,
but the apps and the chat boats
will share the need,
the same user could be using it differently,
but from the hardware to the experience
and the delivery will be completely different.
In one you will have the keyboard and the two hands,
but not only that,
you will be typically sitting in a desk
and having that nice experience
in a comfortable environment.
While with the smart devices,
you will be on mobility
and maybe you won't have all the elements
in the interface in the same way.
And this, it sounds pretty venial,
but for us it's pretty important to break the myth
and don't try to build a bot on everything.
We really need to think on the use cases
and the real need use context
that they are built for,
which sounds pretty trivial,
but at the end is for us the key point.
We have been live for about one month and a half.
Two months and a half with one of the chat boats in Mexico
and we have now thousands of transcripts
and interactions from your users.
And at the end we see that from the beginning
we were thinking on the usage in one way,
but at the end it turned
that the people are more easy to not manipulate
but to guide within the experience that you want.
And the use,
further than the discovery when they repeat,
is pretty straightforward.
So again, it's a matter of thinking
on different paradigms and use cases,
something that has not been done so far.
For us, the real use case of a bot could be shown
on the left side, which let's say you can search
for a flight in both a web
and app in a chat bot.
The purpose of the bot is that once you have proceed
with your search, with your booking,
the bot should be able to retrieve your profile
as the bot is doing.
So you are, these are your preferences.
But also, for example, in terms of booking,
he should be reactive and remind you
or offer you the possibility to monitor that price.
Again, for us, the mindset to follow
in terms of chatbots or bots
is to build on personalization
but also on being a human servant,
being a truly consider something
that websites and apps are struggling.
We were discussing on that
and we know that the app technology is not so far
but they are failing on delivering this type of solutions.
On the other side or the other flip,
the other side of the same coin
is that we have a huge responsibility to don't screw.
Here we have an example on experiences that go wrong.
So imagine that you are trying to interact with the bot,
I want a flight, okay?
Where are you departing from, Perth?
Where are you departing from, Perth?
Where are you departing?
And this is pretty annoying
and we have experienced this a couple of times.
So again, the beauty and,
so it's like the distance in between the success
and the failure is pretty tight
and the risk is pretty high
but our take is that the return,
when you have one successful experience, it beats all.
So again, bots are not here to replace the apps.
Yes, you need to think on the real cases.
Our guess is always go through the direction
of serving people through personalization, customization
and also being proactive, pushing you notifications,
relevant notifications
and the challenge and the real challenge
is to don't screw it on the way
because in the Mexican way,
we chinga tu madre y nos lo han dicho un par de veces
or failing.
So the updates are really high
but the risk also it's considerable.
Can I ask a question about that?
Sí.
From the two pictures that you have shown,
it looks to me that on the left side,
the bot is just bringing information
and on the right side, the bot is trying to understand
what is the problem.
We have used different screenshots of the same flow
which is a booking flow,
which is the key thing on travel.
It's one of the most difficult things
because you need to pick it right and pick it fast.
But on the left side,
what we wanted to demonstrate or illustrate
is the possibilities of personalization.
So you will see that on the third prompt,
we are retrieving the profile that we have built,
blah blah blah.
By building a bot profiling system,
you are able to identify the person by one
because you have your and Alejandro will illustrate that.
You have your means of amplification
plus the means of that channel.
So basically we store and we build
a meaningful profile for every user.
We use to build a meaningful and rich experience
for the user.
So we do, for example,
which are the common preferences,
if he likes or she likes flying
in a weekend on a Friday or Saturday
or what are the booking he has
and everything like that.
So that was part of the left part,
like the uptake,
getting it right, fast,
customize to the niche specific profile of the passenger.
And the other is that,
and this is the beginning of the conversation
before you go into the booking,
that if you miss that opportunity
because you get it wrong
and you get it wrong at the beginning,
this will never happen.
You will never reward it.
For example,
and this is more a personal experience,
but while pitching some venture capitalists about it,
you always have this clever than the rest manager
that tries to beat the bot,
which is pretty simple.
At the end,
if you try to be mean with the bot,
you will make it because it's simply a bot.
So misspelling can understand,
but it's very likely that you risk
to crush the bot and so on, so.
So we had this experience with one venture capitalist
that wanted to beat the bot
and didn't have the experience.
Well, for example,
on the other hand,
while explaining and validating the PCI compliance
with the bank,
I was showcasing the,
doing the demo for the manager in the bank,
and I was not touching anything.
I left the control to him
and he could complete with a good faith
the happy path of completing a booking.
He was not stopping saying, wow, wow, wow, wow.
This will change the world.
And at the end,
this is kind of the,
again, the flips of the same coin,
where you will have someone
that want to make it lose the attention,
lose the context and make mistakes.
So the experience will be horrible.
And the others,
if everything goes well and flows,
you will have the profiling,
the preferences, everything,
and will be fucking amazing.
Fast, clean,
and comprehensive.
But the point is that you have to write things well.
Not really.
And this will come later.
So you have the natural processing layer
that it will catch some of the variations.
And of course,
you can build on top of that additional service
to correct the misspellings and so on.
So again, we said one of the key things
is that bots are not here to replace apps,
webs and so on.
And then you have the other side of the coin
that which are the specifics.
One of the specifics are the channels.
You might hear a lot of people talking about Slack, Skype,
all the platforms that support bots.
And what's the take or what's the learning in this case?
For us,
other than the typical metrics of the people
that share the billions of users that one platform has.
And the type of specifics
and the understanding and the segmentation
of the user base.
For us, from the technical perspective,
once you got that right,
the important thing is to understand
that all the platforms play different rules
from the technical perspective.
It won't be only about structuring the message,
but also about understanding that,
and I don't have here the case of Slack,
but in Slack,
you will be able to put bots into groups.
So the bots should be listening to more than one user,
as well as,
and this is the stupid example of the templates.
On the left side,
you have the carousel,
or we call it the carousel,
but I don't know what's the name, carousel.
The carousel from Messenger,
the equivalent with Skype,
and the equivalent with Telegram.
Both platforms are completely
and continuously evolving the templates,
but at the end,
these are your constraints while building,
on one side,
the bot for that platform,
and also on the other,
while building an omnichannel
or a bot that needs to support all the platforms
at the same time.
And going beyond,
what we see is that NBC Philosophy,
it helps later to,
let's say extract the bot
from the conversational interface as Messenger,
and be able to treat not only chat,
but also voice.
So if you really care about your bot
and you want to bring it to the next level,
and being this next level,
maybe a conversation in Alexa,
or even the voice itself,
it's critical to really differentiate the logic
from the presentation level layer,
even if the presentation is,
or will be in the future, voice, no presentation.
So this was kind of the first takeaway from F8,
understanding that other than the hype,
the evolution might be,
or could be webs, apps,
and now bots,
without trying to replace anything.
And the second learning is,
even we don't need to replace humans,
because still artificial intelligence,
it's a promise,
it's not a reality,
and we are still cleverer than the bots,
or than the bots we can produce.
There are only a few that could be smarter than us.
So the main objective is that,
the bots you would be programming
would never, never have to fake that they are humans.
So there are some stupid things
that we did at the beginning,
like adding the typing,
while being able to give the reply,
it's a fact.
In some cases, now we are using the typing mechanism,
or something that could fake that you are a human,
when loading the flights from the reservation system,
or processing for one segment.
You can try to make it.
More human than human touch,
but you should never pretend
that it is a real human.
You have to really manage this expectation
with your users,
because otherwise,
as a previous example,
the users die.
When you get into the loop,
I mean, of course,
if you are a human,
you understand that,
from where you are departing,
Adelaide, Adelaide,
it's an airport,
so you should pick it up at the first time.
So trying to be real in the sense of,
I'm a bot,
it's the first thing you can do.
It's the thing that you must.
Then we can talk about the personality.
Of course, this bot can have a funny
or funky personality,
and this is what, at the end,
if you are building a bot for a brand,
for a company,
you can pursue it.
But at no situation,
we encourage people to try to be like a human.
As Alejandro said,
as a client,
it's a matter of managing expectations.
So you can name it on
preparing for the worst,
and then being surprised.
So I'm a bot,
and this is stupid.
You will try to,
you need to type everything
in the way I understand it,
to really typing it the way you want,
and at the end learning
that the bot can get it right.
When we say that
bots are not as humans,
or even a bit worse than humans,
we typically think on what they know.
As humans,
one of the things we typically say
is like,
these are my limits,
I know up to here,
the rest you need to check it.
So you should do the same
and expect the same from the bot.
So you cannot think on
building a bot for every purpose.
A bot needs to be domain specific.
So if you build a bot
for booking hotels,
it will be great at booking hotels
and don't expect them to book a restaurant.
If you build it,
and these are the,
make the maths,
but it will be eight,
four,
32 domains that API.ai is offering
by default,
that you can further expand,
but it's like,
if you build a bot for web search,
it will be nothing to do
with calendar and scheduling,
nothing to do to directions
and driving, restaurants.
I mean,
every domain has their specifics,
and you need to respect that,
and you should not be afraid
of limiting the use of that bot
to a specific domain,
which is from our site,
which is something compulsory.
The second learning or principle,
and this is more on my engineering,
mechanical engineering side,
you should follow either,
you call it the ABC analysis,
the Pareto, 80-20, whatever.
What we have seen at the end is that
20% of the inventory
of the intents you build
will add 80% of the value of the interactions.
You need to focus on that,
and you need to deliver
your key domain interactions,
rich content, images,
everything,
getting the context right,
the username, I mean, focus on that.
Then there will be 30% more of the content
of intents, of answers,
questions and answers,
that will add 15% of the value.
For that,
what we recommend on
is to build a knowledge base.
In our case,
I don't know how to name it,
but we have built a JSON file
that contains 1,000 FAQ questions,
that are airline-specific
and travel-generic.
What we do is to connect
on the frequently asked questions
from the airline,
and then we use elastic sets
of indexing on the queries.
So we can pull it from the bot,
from the other,
the right intents,
or the right questions are asked.
So we do kind of a cementing search,
on a custom build
for that specific bot,
knowledge base.
The experience, how it looks like,
is like, I want to know
if in Poland I can
drive on the left side.
No idea.
What I do is,
if there is no direct match
on any of my intents,
I go to that intent
that will do the semantic search
on my base,
and experience how it's
in the conversation,
it's like, I'm not sure about that.
Let me check on your behalf
on the knowledge base I'm connected with,
and you somehow verbalize
what is happening.
So at the end,
for us,
50%
so expect unexpected,
50% of the intents,
the remaining intents,
the remaining 5% value
to say,
this is perfect,
this bot is perfect,
will be impossible to manage.
And in those cases,
what we built,
in specific for our airlines
and brands that we
take care of,
it's the human takeover,
human handover, you name it,
but at the end is assuming that
the bot won't be able to answer everything.
So when the bot is blocked
and has no valid answer,
they can talk to a human,
which at the end is supposed to be
the perfect
agent
to serve their needs.
So these are our
kind of key learnings
and
the numbers are not very far from
the reality.
20% of the intents are serving
80% of the queries
and the value that performs,
mainly in our case, in the search,
booking and back allowance
and
the common frequently asked questions
with rich content,
picture of the bag and the key loads
and the root, the network,
everything that is important
for the airline, but also for the user.
Another learning in this case
is
it's pretty funny
how these conversations or these
bots are guiding conversations
and
these guidance
is kind of a root.
So if you design the conversation,
if you design the experience the way
you want,
the users will end in the point
that you want.
And this is kind of
a learning.
If you were in the
first workshops
you might hear that we were
using chatbots for
I don't know,
from the beginning.
In this case we're not
chatbots as we typically know now,
we're chat ops, operational ones.
So
our business also is about getting
upgrades for people.
So in order to get an upgrade, you first need
to make a booking.
If you try to make a booking in the airline website
you spend 10 minutes
inputting the credit card details
going step by step horrible.
So we basically use the API
directly from the chat using
command lines as the
old fashioned
black screens in the airport
and then you get a booking and then you can
use it on your service
which in this case was the upgrade.
So
the problem that we
saw in the beginning is that
me, I was one of the stakeholders
of the bot, of Tato in this case
this is the name of the
pet office.
So I was using the bot
and I was never aware
of the latest functionalities that
were added.
So I retrieved PNRs, buy PNRs,
change, add bags, etc.
I was never aware
because we're done
in between business and
for development purposes
so business was not always aware
of the new functionalities
and also as you can read
this is the book creation
all the parameters that were input
were horrible. So Merlin
or we hook with
a new airline and this airline had family
so you need to input
a new thing into the process
because it was optional for this
but compulsory for the other, it was horrible.
What we saw or when
I entered into the new
scene with the chatbots, messenger
and this new fancy style
I discovered that
it was completely different.
It was great to say I want
to buy a booking
and then complete the flow.
So I didn't have to
remember which was the parameter
from or even
this airline had to specify
the family fare etc.
I was simply being guided
through a conversation.
Question and answer, question and answer
and then I got it.
Time invested was almost the same.
So at the end
what we were
reading at the early beginning
so the new conversational
interface arise
was pretty
confusing for me because
I didn't know if it was
a conversational
interface, user interface
or a really
adaptive user interface
where you could only have
the elements that were
relevant for that part
and in that moment
I believed that
it was a mix of both.
It's a conversation because it happens in a conversation
but for Lakia
the conversation is adapted to our needs
to our function.
It's pretty interesting how you can
evolve.
Driving or thinking about
driving conversations
we see that
there are three key moments
when you need to drive
a conversation or how you can drive
the conversation. The first
key and most important thing
is the onboarding.
When you launch
a bot
first of all you need to be lucky
so they meet the app
and they access the platform
and they hook with your bot.
So then you get it.
Second is depending on how they get there
they might lose
the landing page where you explain all the functionalities
so the most important thing
when a new user comes
into the channel, into the bot
you need to onboard them and explain
what are you
what are you doing for them
So
this is what we call the tutorial
the bot roles etc.
Kind of a tour
that we can find in certain
web pages where they explain
all the steps, all the possibilities
in a conversational way
on demand. We launched without this
functionality
we did it one week later
when we saw that
So again
guiding at the beginning
guiding during the conversation
this is an example
from where are you departing Madrid
sorry I don't serve this
this station
look at the network and find the nearest one
Error handling
is very important
there is a white paper on error handling
that is wonderful
highly recommended for all
you need to do
both error handling
when there is no signal
so you might
or the bot has said something wrong
if the user doesn't input anything
but also
while managing wrong inputs
helping
maybe it's the formatting, maybe it's the content
maybe so working on
error handling is key
to drive the conversation the place you were
you want to end and then the latest
is the learning center
this again
this is a snapshot on
the last part of the booking process
so once you have purchased
then you have the thank you message
and we give kind of a tip
so maybe you have performed
the booking in 8 steps
and this is the explanation
on how to do it in only one
so
teaching and learning the users
how to better use the bot
and being empowered
and this is the last slide
so you can relax
our key learning so far
avoid the user loops
that end in
overflowing the user
where are you departing for
go and fuck off
so prevent this
from happening
so far we are building a little fix
on that where we cannot
encounter more than
x occurrences of the same input
message
so if you are asking
the origin
3 times
this means that something is wrong
so you need to handle
or one of the key things
the error handling
in the conversations
then the use
but not the abuse of the natural language
understanding
for example and we were discussing this
from the technical
perspective we have intents
that use the
the processing layer
and others that go directly from the back end
an affirmation yes
should not be channeled through
the natural
use of internal intents
that instead of passing through the NLU
and then coming back
just goes straight to the control
and the latest is
at the end some NLU
interfaces and some training exercises
are pretty tempting
for non IT people
but you need to keep it
controlled
so again for us
we are not developing NLU
we are adopting an existing solution
on the market
and the solution specific
is not open
so for us in some occasions it's black magic
and in order to control
the black magic you need to be
consistent
to be testing which are the differences
so before coming we played a bit
and we test if understood
the plurals no
the pluralization of the entities
then
basically
regardless
do we have the profile
of the board trainer
in our team
and these less technical people
and they
mainly with the static content same
but
we talk them how to
for example
teach the NLU to become
NLU intents
something like this
but then we realize that if you don't have
the right understanding of
the domain within the NLU environment
you can really scratch things
so
the core part of the NLU
I think should be restricted
only to technical people
and not only technical people
who know exactly
what they are doing
when they are creating an entity
mapping an entity at only 10 etc etc
by the way
how many people are familiar with NLU
and entity at the end
tools like this
because I was picking up
of intents
and things like this
so this is
it on our side