Dialog

Learn from given cases and get inspired to make your bot sound even more like a human

#1 A phonebot learns to speak from humans, so it should sound like them.

You write texts that will be read out loud, so: Don't write it to read well, write it to sound good: Keep it short and simple! Refrain from technical formulations or instructions If possible, use colloquial language (carefully) just as every human would do

Don’t:

“Is there a term you can give me so I can direct you to the right department accordingly?”

Do:

“What can I do for you?”

When creating your automated dialogs, always ask yourself:

Would a human person do and say the same on the phone?

A phonebot uses only words that all callers know. So even if you and your call center team are familiar with technical terms that help solve problems: Your callers aren't likely to use these terms on a day-to-day basis, so they certainly shouldn't be used by your phonebot.

The simpler the language, the better the bot experience for your callers!

Tip: Always read your sentences aloud, otherwise you will often fall into patterns that sound good when you write them, but are far too clunky when read aloud!

#2 A phonebot is not talkative.

Psychology has proven: The person who gives more speech to a dialogue is more satisfied with the conversation afterwards. And of course, this should always be your customer!

So even if the technology invites you to do so because it simply sounds good:

The design of dialogues does not serve your linguistic self-realization.

The trick is to let the phonebot speak only as much as necessary and as little as possible.

Every customer service call has a concern that should be answered/resolved as fast as possible.

So let your bot get to the point quickly. Ideally, even at the first turn there are no big greetings and explanations.

Don’t:

“Thank you for this information, I understood your customer number is 7153626, did I get that right?”

Do:

“7153626, right?”

#3 A phonebot is self-confident.

Avoid apologies and excuses. People currently still have reservations about making phone calls with a bot anyway. Your goal must therefore be to create the most positive experience possible - even if something goes wrong.

With Parloa, we even get to know the confidence level of our bot with every turn, so we can use it for the further course of the dialog as well!

#4 A phonebot always wants to make a step forward.

Advice: Check if each step in your dialog could start with an "And". Where this is not possible (e.g. because it is more of a "but"), ask yourself whether it really needs this step.

Even if you just want your bot to say something clarifying or explanatory, always have it ask a question at the end of the prompt, e.g.:

Did that answer your question?

or

Is there anything else I can do for you?

The conversation should only be ended by your bot under one of the following two circumstances:

1. The user explicitly says that he has no further request.

2. The call is handed over to human agents.

This also leads directly to Rule #5:

#5 A phonebot always ends its message with a question or request.

Your customers should be able to respond directly to any question or request. Explanations should be given beforehand, anything else will only lead to unnecessary confusion.

Don’t:

“What is your customer number? It consists of 9 digits.”

Do:

“What is your nine-digit customer number?”

But not only use questions in every turn:

Tip: Also try to work with human dialog tricks in a very moderate quantity, e.g. Bot: "All I need now is your phone number to call you back."

User: “Ah ok, yeah, that’s 017..”

#6 A phonebot loves implicit confirmations.

If confirmation of user input is necessary, always try to solve it implicitly.

Don’t:

“So your zip code is 10178, right?”

Do:

“10178, got it. And what’s the street and street number?”

It is usually sufficient to have one unique customer attribute explicitly confirmed (e.g., the customer number) to prevent misunderstandings. Further queries should then always be compared with the explicitly confirmed attribute first, in order to perform authentication as quickly as possible.

Of course, this only applies if backends are also connected for matching customer data. But even without a connection, check whether it is sufficient for you to have only one date explicitly confirmed, because, for example, agents can check the data manually and deduce whether it was a total misentry or "just a comprehension problem", which does not make authentication impossible.

Use Parloa's Dual Intent Recognizer (DIR) to make this possible!

#7 A phonebot allows further inputs at every turn.

Avoid lengthy "yes/no" answer chains, because with this, only one party in particular speaks: the bot (see Rule #4 on this page). And a good dialog always allows for further input in the case of confirmations and rejections, too:

Example

Bot: “10178, got it. And what’s the street and number?”

User: “No, it’s 10179.”

Bot: “Ok sorry, 10179 of course. And what street and house number is it?”

Idea

Try using next inputs as confirmations, e.g:

Bot: “If I got 10178 right, then please tell me your street and number.”

#8 A phonebot always assumes itself to have made the mistake.

If input does not match the awaited data or Intents are not matching, always assume an error on your part and not on the user's part!

For example, the Speech-To-Text recognition could have noted another date of birth, although the users have said it correctly.

Don’t:

"Unfortunately this is not correct, please try again and tell me your date of birth."

Do:

“Sorry, what was the date again?”

Even think about moving on with another user date on errors to check against your CRM without the users letting know that they have been misunderstood.

Bot: “Ok, and what is your address?”

Happy path: Authentication with errors

Let's assume you need to authenticate your users with 2 characteristics:

Bot: “What is your customer number?”

User: “It’s 8765181”

Bot: “Let me repeat: 8765181. Is that correct?”

User: “Yes!” --> database check: match --> receive birth date and zip code to check at least one characteristic within your dialog

Bot: “And when’s your birthday?”

User: “October 2nd 1996.” --> user said “November 2nd 1996” but ASR transcribed it wrong --> database check: mismatch

Bot: “Sorry, what was the date?”

User: “December 2nd 1996.” --> user said “November 2nd 1996” but ASR transcribed it wrong again --> database check: mismatch --> need to check third characteristic as second factor authentication

Bot: “Ok, and what is your zip code?”

User: “It's 10178.” --> database check: match --> authenticated

Bot: “Thank you, I was able to authenticate you successfully!”