We’ll discuss:

• The definition of ‘success’
• The most forgotten component in Conversational AI: the user themselves.
• You and your project team, jumping in head first
• Conversation-Driven Development
• Your chance to develop a chatbot that sticks!

Define success

The info that I am looking for is actually objective data that provide concrete evidence about the ROI. So not those testimonials or ‘demo cases’ posted on companies’ websites, claiming they have developed a great chatbot customized to the client’s case in no time. Ok, they might be good for covering the main best practices about chatbots (like the ones you can find on google when searching for ‘how to make a good chatbot’), but they’re very theoretical. You never hear about cases where it didn’t all go as planned (because, it won’t), the total time spent (which is probably double of what was estimated), hence final project cost and especially the effect or impact the chatbot had. Typically, only the successful cases are discussed (which is so unfortunate), with success often referring to the ‘success of implementing technology’. And yes, technology to create a chatbot has seen some great progress.

From chatbots to Conversational AI

More and more chatbots are actually using some form of AI. More than a year and half ago I published a blog post about chatbots, where I clearly crossed-out the AI part when discussing the state of technology. Reading it now, I almost feel silly, but at the same time it offers perspective and shows the evolution technology has made. Heck, it even made me not like the word “chatbots” anymore — instead I prefer the term Conversational AI now, because actually.. we are getting there (or let’s say, somewhere): due to the enormous progress in the field of NLP (Transformers, pre-trained models…), more and more frameworks are actually leveraging AI to build Conversational assistants.

Frameworks have made it to “level 3”: building contextual assistants (check out this blog if you would like more info about the different levels in Conversational AI. Rasa is on top of its game and by far the most convincing framework if you ask me).

We went from extremely closed scenarios, with only buttons to click or a fixed designed flow, to a scenario in which the topic is probably still fixed, but the way (being, the flow) a user gets their answer is fully up to them. And who knows what’s coming next. The GPT-3 model that got released by OpenAI, which is very impressive from a technical point of view, looks very promising and has raised expectations for the coming years. Next to this, you have the low-code or no-code alternatives to build a chatbot that started popping up everywhere, impossible to keep track of. All of these focus on enabling customers to create a chatbot without the need of technical skills. But also the development frameworks, that allow you to build a chatbot from scratch, offer more “built-in skills” out of the box (i.e. connections with other existing APIs). Conversation Design is getting more of the attention that it actually deserves. All this combined makes Conversational AI more natural and improves the chance of implementation.

It all makes me excited and disappointed at the same time. Because despite the many advancements in Conversational AI, and being around for approx. 5 years now, we still make the same mistakes. You still read about the same old ‘best practices’ that were already best practices 2 years ago. Today, it isn’t about ‘being able to (technically) create and implement chatbots’. When it comes to Conversational AI, or actually any form of AI, it is about finding a use case where this technology actually adds value to the end users’ experience. The question shouldn’t be: “can we build it?” but “should we build it?” or “is it useful to develop this kind of solution?”

“It is your end user who will make or break your chatbot.”

So what I mean when I ask “How many chatbots are actually successful?” is actually “How many chatbots actually resulted in added value for its users?”. And the only ones able to answer this question are your end users themselves. You know, the ones you are building the chatbot for. We don’t go into conversation with our end users when developing a chatbot. Pretty odd considering we are building ‘Conversational AI’.

The problem

It all starts with the actual problem. If there is any..! Still too often I get amazed by the fact that companies start from the technology, but don’t know what the problem is they want to solve. I call this “AI for prestige”, or in this case using Conversational AI just to… use Conversational AI. Because I can tell you right now, it will result in a demo case at the next board meeting at best, justifying Marketing to proclaim the company has “successfully implemented Conversational AI” and then, after a month or 2, it will end up in the closet, on the pile of “previous innovation projects”. Again, it’s not about the technology. It’s about making it stick!

But OK, let’s assume decision makers actually identified a clear problem or need that could potentially be solved by Conversational AI. The next question you should find an answer to is: does this problem also exist for your end users? Double checking does no harm! And while you’re at it, you should also check “if it is possible to chat about it?” Because that’s pretty much a prerequisite when it comes to Conversational AI. And last but not least: do they want to ‘chat’ about it (with a chatbot)? Certainly because ‘improving customer experience’ is one of the classic benefits predicted by business, so you better make sure it is. Chatbots have burned some bridges in the past, don’t forget about this!

Jumping in, head first!

But it’s not all your responsibility. I am still waiting for a solution provider that challenges a project team and the decision makers to find out whether working together is actually worth both parties’ time. And by this I mean, questioning the actual need to build Conversational AI. Teaching them about Conversational AI: the technology, the labelled data part, the human factor that is unpredictable when it comes to automating conversations… Giving a super enthusiastic project team a heads-up and getting them to realize: building successful Conversational AI is just. hard. work.

Unfortunately, this is how it typically goes: Most solution providers will take you through a Discovery workshop where you try to define the scope, give your Conversational AI some personality and design the necessary conversation text and flows. This info gets summarized and the development team kicks off, starting a… “never-ending-journey”. Ok, sounds a bit too harsh, but actually… it is! A Conversational AI project is a story that never ends (unless you actively stop it). And I at least hope solution providers have gotten you up-to-speed with this fact. But first things first! Let me break some things down for you about what’s lacking in today’s approach.

Let the experts talk

The Discovery workshop is a good thing! And ideally, “understanding conversational AI/ML” is the first thing that gets touched in the workshop. This is definitely the responsibility of the Conversational AI expert or solution provider. And if it all sounds too much like sunshine and flowers, it should ring some alarm bells, triggering you to ask some simple questions like 🕵: What is the success rate? How many chatbots are in production today? Can you show me one (live-demo)? How long did it take to get them into production? Are they being used? And how many conversations ended up helping the end user? What happened with the ones that didn’t find help? It will be beneficial for both parties to get some straight answers to these questions, so the full team is up to speed with the “dos and don’ts” of Conversational AI.

Other experts that should be in the room - but are too often forgotten - are the Marketing/Sales and Customer Support representative! Wouldn’t it be a pity, developing a great solution but putting it on a page that never gets any visits? Or why would you not involve the ones that will be on the front line when your Conversational AI solution fails? Because it will. Conversational AI today is not strong enough to automate your full first line Customer Support service. Some users will probably even call a support agent the second they know the chat service is replaced by a chatbot (like mentioned before, something with “chatbots, burning and bridges”)! Customer Support agents not only have the knowledge to create and maintain your chatbot’s Knowledge Base (read ‘brain’🧠). They know your end users best, as they come into close contact with them every single day.

Conversation-Driven Development, from day 0!

Scope definition, conversational design and personality, ️check? Ready to develop, you think? Well, hold your horses! Please 🙏🏼, I hope you went further than ‘Google Analytics’ or ‘Top support issues’ to define the scope of your chatbot.

It’s like giving a speeding ticket to a car based on its location, instead of looking at its actual speed. Meaning: totally beside the point and based on assumptions!

In the ideal world, you have actual chat conversations to build your case on. If not, go and get some! It’s an approach that works best in my experience and unfortunately until now, there is only one Conversational AI framework who’s on the same path with me: Rasa. They like to refer to this approach by calling it Conversation-Driven Development (CDD), and actually, I couldn’t think of a better name for it!

When designing the conversational text and flow from scratch (or based on relevant data), you are making lots of assumptions. You will constantly be “pretending to think like a user” and “predicting what they will ask and how”. You can consider it being very creative, but actually you are… trying to predict the unpredictable! Go into conversation with your end users and collect data and facts to base on. Putting up a survey isn’t sufficient. The best way to get valuable feedback is by confronting them with the actual idea/solution in the circumstance you assume they will use it. Do not create an IT support bot and test it with volunteers, when in some cases, if you actually need IT Support, it is rather urgent. So the emotional state of the user will be totally different. The feedback you will get here is not how it will be when your bot is in production. You should drive your development by actual conversations in circumstances as close as possible to how it will be in production.

Conversational AI — ‘A story that never ends’

Would be a great headliner, no? Developing a chatbot that fits in with business expectations and getting it into production is one thing (although the increase in low-code, no-code tools definitely helped), but the maintenance that goes hand in hand with Conversational AI is highly underestimated. Recently I talked to a company who told me how they tried creating a chatbot to inform their members about COVID & the government’s rules and decisions. Getting it up and running was not that hard, but each week the decisions changed (in our country at least 😊) and it was impossible to adapt the bot’s content at the same speed. Something the project team definitely didn’t think about, leading them to end the project after 3 months, with the following conclusion: ‘it would have been more efficient if we offered a live-chat service on our website”… If you created a Conversational AI solution that is actually getting used, you better think of structured processes to keep it like that. You should appoint a responsible ‘Bot Trainer’ for it and make sure his/her life will not become a living hell!

Conclusion

Conversational AI. It’s not a question anymore about building it technically. It’s a matter of finding a legit use case that actually brings added value to the table, and does it in the most efficient way. You should realize by now that when you are thinking about Conversational AI, you are making a long list of assumptions.

What if I tell you right now that there is a way to get all these assumptions cleared out, without even writing 1 line of code? Not only that, you’ll get immediate feedback from the ones that will determine your success, as well as a chance to check if your Conversational AI is designed well and sufficiently trained. In other words: I am offering a door for you to peek into the future and see for yourself how your Conversational AI solution will be used, and most importantly, perceived by your end users. Whether your formulation is clear for them, the flow feels natural, your AI model is sufficient, and if it isn’t, you can capture data about what should be improved. A structured framework that will not only prevent you from burning money on something that will never work, but to keep developers motivated and increase the chance of success (in my definition of the word). If you ask me… an offer you can’t refuse!

Sticky Lemon

With Sticky Lemon, we take Conversation Driven Development verys seriously! Keep an eye on our website, as we will soon launch Sticky Chat, our Conversational AI training tool, focused on continuous improvemening your chatbot, in production.

In case you are curious → go and check out our website, follow us on LinkedIn or contact us for more information at hello@sticky-lemon.com

For those that are kept up at night, wondering if artificial intelligence would be the answer to their problems: here’s a short overview based on my experiences and several significant leaders in the world of AI. It should give you a heads-up about what to expect and where to start when thinking about using AI, so you can cut through the buzz and fuzz.

Summary

• Abundance of buzz, lack of understanding
• Machine Learning or also called ‘Automation of Labelling’ by examples
• AI Theatre
• How you should avoid wondering up in ‘thoughtland’
• How you can unlock the potential and feasibility of your AI solution in a matter of weeks!

Artificial Intelligence, or in short AI. Smart automation. Digitalization. Machine Learning (ML). Deep Learning (DL). Computer Vision. Natural Language Processing. Internet-of-Things (IoT). Conversational AI… They all join the club. The club of being one big pile of words, creating so much buzz and fuzz. But AI is definitely a winner here! Working as an innovation manager, it’s like the “elephant in the room”. The one thing everybody is waiting for you to talk about. And not just talk. You better fill in the expectations with a bunch of ideas and use cases relevant for their industry which will make them an innovative company!

The easy way would be to fill in these expectations and promise them great things. However, I refuse. Instead, I start off with explaining the basics of AI (in plain English). To be more precise, I explain the difference between AI, ML/DL and business logic. More specifically, supervised learning, and hence the big difference between data and labelled data. I acknowledge what is possible today, but also what it isn’t (yet).

You will catch me being bloody honest. People need to start realizing that AI is not like magic. It’s not about throwing a bunch of data in the direction of a data scientist, who on its turn gives it to a computer and voila.. magic! Even today, with all the data generation and advancements in computing power, ML is still Research & Development. There are no “one-fits-all” solutions, on the contrary, applying ML is just hard work. And even despite the fact that researching AI for more than 50 years now, it is clear to me that still the same mistakes are made.

Abundance of buzz, lack of understanding.

We can’t ignore it anymore.. AI is part of our lives already and it is here to stay. It’s shown by the amount of resources government invests in getting AI-things done (e.g. In my country, Flemish government invested 30 million euros in AI last year). Next to this, social media, LinkedIn, reports of Gartner, Forbes.. They all offer a daily portion of information and emphasize the urgent need to innovate. It all shows we are in the middle of an “AI Spring”, a period of hype and trends, with lots of resources and funding going to R&D in AI (check out this great book of Melanie Mitchel if you like to know more!). All this buzz (and fuzz) is feeding decision makers to believe that AI is the way to go to be future proof: “we have data, so we should use AI !”.

However, the definition of AI exceeds its reputation. It creates the misconception that having data and an idea for a use case is good enough to get some data scientist(s) going and to expect significant results in a couple of weeks. Don’t want to burst any bubbles here, but it’s just not. that. simple. It will take time, and the less understanding amongst decision makers, the longer it will take. Not necessarily development time, but time to collect the necessary specific data.

Still, at least once a week, I get amazed about the lack of fully understanding the concept of AI by decision-makers, asking to apply AI.

The importance of having a qualitative dataset that fits the problem you try to solve is still an underestimated building block. An idea should be translated in data and depending on the desired outcome, it should be labelled for your specific use case. If you don’t have a framed problem or a well-defined objective.. forget about it or at least don’t expect any results in the next coming months. Cassie Kozyrkov (Chief Decision Scientist at Google, love her articles by the way, go check her out!) has mentioned it many times in her speeches already, but instead of the poetic name ‘Machine Learning’, this technology should be called ‘Thing-Labelling’ (or how I like to call it ‘Automation of Labelling”). It would prevent the misbelieve that “a machine is (self-)learning”. ML has little to do with ‘learning things by itself’, ‘sci-fi’, ‘humanoid’, ‘able to reason on its own’… At this point in time, it is still all about Supervised Machine Learning (or Semi-Supervised), meaning it is all about.. humans labeling things.

Machine Learning aka “Learning by examples”

So why would we even bother about ML then? Well, before ML came to place, it were engineers, mathematician, scientists or other brilliant minds, handcrafting rules and logic based on stats, research and guts to enable a computer to make decisions (i.e.: classify data, make predictions or…) However, not all problems were well understood: How to discriminate between “a river” or a “financial institution” when reading the word ‘bank’ in a sentence. How do we classify a set of pictures (which are in essence pixels) into the sun versus the moon. How can we link a certain sound to a certain object (for instance a train, air-plane,..). What should the rules be, if we don’t even know how our brain is doing it?

This is where ML kicks in. Machine learning is all about learning by examples (i.e. labelled data). Today, this still implies a human intervention: showing the computer a bunch of examples for “each class of your problem” . You need to show the computer examples and say: ‘this is the sound of an airplane, this is a bicycle,…’. This is what is referred to as labelling or annotation, and at the time of writing still a prerequisite in today’s world of AI. From brain lesions in a MRI that need to be labelled by a radiologist ‘till an e-mail that should get some tags to route it to the right department… AI still needs humans to show examples and is (not yet) capable of working its way through a bunch of unstructured, non-labelled data.

So yes, there are a couple of steps your project team needs to take before a ML Engineer can even start training a model. Making sure business and all other members of the project team understand this well up-front is one of my top priorities. It will help designing the project in the right way and therefore increasing the efficiency and chance on success.

AI as a means, not as an objective.

I’ve noticed that too often, companies start from the technology itself. “Let’s create a SaaS-product. It should use AI! Let’s think, maybe we personalize the experience with AI recommendations and use AI to process the data and provide them with insights”. Unfortunately, literally a situation I have been in. Because hey, mentioning AI 3 times will definitely convince investors and future customers, right? Let alone the media attention we could get when the world sees we are using AI in our product! Other examples are companies with the best intention of actually solving a real problem or optimizing an existing product or service, but still choose to use AI just to use AI. While actually, in some cases, a simple business rule can probably do the trick.

This is what I like to call ‘AI Theatre’ or ‘AI for Prestige’, where the objective is rather to get mentioned by the press or claim to apply AI, instead of making sure technology will actually create an added value. Sadly, AI for Prestige is a common thing today (the more the better, hooray!), but it is doomed to fail, leaving passionate developers (and/or paying end users) with a sense of being deceived or getting demotivated. Hack, we don’t like our work to be all for nothing, right?

An idea? Reality check, ASAP!

But it’s not always the ‘man with the idea’ his fault. When looking for advice or help to achieve this AI-idea, solution providers or consultancy experts will always have their answers and solutions ready! In the last 3 years, I have never heard one expert questioning if we were sure the problem we were going to solve with AI even existed? Discussing whether this is the responsibility of a solution provider is out of scope for this article, but assuming it would serve both parties well: How can we know this? How do we know an idea is ‘the right it’?

Let’s say that I have learned to not take things for granted just because “decision makers said so”.

Make sure you and your team are not assuming too much or you start wandering up in “thoughtland”[2]. List your assumptions and validate them asap: do customers really want to confirm whether or not the fruit in the smart weighing scale is a banana or not? Is it possible to ‘chat’ about the problem they are having? Do they like speaking in public to a smart speaker to get info about their financials? The only ones able to answer those questions are your end users: They are the ones confronted with the issue and most of the time also the ones that are paying for your product or service.

Too often there’s a huge mismatch between business wishes and end user’s needs. All this because there is a lack of involvement of end-users in the analysis and development phase. Last couple of years, methodologies like Service Design, Design Thinking or Design Sprint won in popularity, addressing this lack of customer-centricity and emphasizing the customers’ experience. Despite these methodologies being commonly used for (web) app development, they are highly unexplored in AI related projects.

AI Design

So how can this match? And what is the right approach? On the one hand, we have the fact that building an AI-solution will take manual effort and time and has some degree of uncertainty (R&D). While on the other hand we need to get end users involved as soon as possible to make sure the solution sticks. Sticky Lemon solves this by offering a data-driven framework where it is all about getting Subject Matter Experts and the right set of tools in the proper setup. The framework is centered around gathering labelled data while checking the business potential of your idea. It offers a fast forward to the future and helps to identify the technical requirements and the practical impact on the existing process (and hence how it will affect other stakeholders). All this in a matter of week(s).

We have learned that, despite us wanting to jump into the technical part ourselves as well, investing some time and money in a well-designed experiment to validate the assumptions will not only increases the chance of success and satisfaction of the whole team, but speed up development time as well. It’s all about making sure you start of with a actual and well-framed data problem, and gathering the specific, labelled data necessary asap. By using this framework, I want to make sure we build an AI solution that sticks!

Sticky Lemon

In case you are curious → go check it out on my website, www.sticky-lemon.com or contact me for more information!

Footnotes

[1] A pretty neat example is the one of Dataroots (a ML company based in Leuven, Belgium) training a model for face mask detection. Considering the last 6 months, this is very applicable topic, however… the amount of photo’s with people wearing masks to train the model is very rare. Go check out there very nice hands-on YouTube tutorial in case you are interested how they solved this!

[2] “Thoughtland is an imaginary place where every potential new product begins as a simple, pure, abstract idea. … the idea starts to attract opinions, .. opinions about an idea are not data, but are subjective, biased judgements.” — Alberto Savoia (former director of engineering at Google), ‘The right it’.

Because of my professional experience (Lead Chat- & Voicebot developer & AI Engineer), checking the market for new technical solutions related to chatbots is a permanent task on my todo-list. Despite chatbots being a personal interest, it is striking how many times these publicly feared* “virtual assistants” are mentioned during an innovation take-off meeting with clients. The hype and buzz continues, so it seems! So sharing my honest opinion and technical experience “in plain English” is a first, when it comes to launching an Innovation Track.

(* Because, lets admit.. How many successful chatbots have you already used?)

You can read more about my do-s and don’t-s in my previous blog. One of the things I mention here is “Design, develop, dare to deploy.. repeat!” and I am constantly looking for tools to encourage this! Main reason why Microsoft’s Power Virtual Agents has been on top of my todo-list!

Top Articles on How Businesses are using Bots:

- 5 Inspirational Startups Using AI and Chatbot Technology

- 21 Best Telegram Bots That Everyone Should Know

- 12 Amazing AI Chatbot Trends for Business in 2019

- The road to a conversational banking future

Power Virtual Agents

In November 2019, Microsoft released the newest feature of their Power Platform: the Power Virtual Agents (PVA). Due to my developing experience with Microsoft Bot Framework, I was very curious about the possibilities. Fellow chatbot developers will confirm: developing chatbots can be fun, but on the other hand is just hard work. 😰 Especially, when wishes & expectations of business are not clearly managed from the start, the development process of a chatbot can become very lengthy (read: dreadful). With PVA, Microsoft enters the “no-code chatbot builder”-market and promises to enable anybody within an organization to create and publish a bot in minutes. For me to find out!

Getting started

To get started, navigate to Microsoft’s PVA platform https://powervirtualagents.microsoft.com/en-us/ and ‘Start Free’. Remark: you need a professional account to register for the free trial, unfortunately personal accounts won’t work. If you don’t have a professional account, you can sign up for a 30-day trial version.

Once registered, you will be redirected and a pop-up window will appear, asking you to ‘Create a new bot’. Just give it a name, click on ‘Create’! and voilà.. you are good to go! The creation process took several minutes. Once finished, I got immediately redirected to the PVA Portal.

The portal

On the home page you get an overview of the potential of the platform and some tips & tricks are shared. You can start by following the suggested steps or open the official documentation as a guide in a second window, like I did. In the next part of this blog, I will report the main functionalities and how I perceived them (positive or negative). FYI: As a matter of demo purposes, I tried the tool to build a chatbot to help user with authentication problems, like resetting your password for instance.

Main Building Blocks 🛠️

There are 3 main building blocks in to get started with creating your first chatbot:

Topics

First, you start off with providing your chatbot some use case specific content (i.e. Topics it should be able to understand). When navigating to the Topics-pane, a list of predefined topics is presented. These are prebuilt and you can use or re-design them, as you wish. Two types of Topics are available:

• User Topics: these are topics related to the scope of your project: in my case these will become topics all related to authentication problems: password reset, forgot password, token renewal…
• System Topics: these are topics related to what I call the ‘standard flow’ in each chatbot: Greeting, thank you, goodbye, human-handover,…

For demo purposes and to experience the full potential, I manually switched off all 32 existing predefined User Topics. System Topics cannot be switched of (obviously, as these are best practices and should be in your chatbot by default), but you can modify the trigger phrases or response message for each topic.

Now let’s get started with adding some content to our chatbot! 👉

There are two ways to create a custom topic:

1. Create “+ New topic”: After clicking the button you need to provide the following:

• Give your topic name
• Write down a short description (optional)
• Add ‘Trigger phrases’: You can consider these as examples of utterances/sentences of the end-user for which the chatbot should identify and trigger the current topic flow(they recommend to give at least 5)
• Go to the ‘Authoring Canvas’: this button gets you redirected to the flow canvas, where you can start creating the conversation flow for this topic. Remark: no need to save, all provided info gets saved automatically and your topic gets created.

2. Search for “Suggested topics”: This is an easy way to get started when you already have an existing FAQ or list of common questions and answer. You can provide the ‘search engine’ with a link to your FAQs (I just took an example of Microsoft). The engine will then scrape the questions and answers of your website automatically. (For the developers among us, this is the same feature as for the QnAMaker Cognitive Service). As a result (±3min waiting), you get a list of suggested topics: literally each question (so they have very long names 😅). Automatically, the flow for each question gets designed,a you can see in the right-side of the picture below.
⚠️ These are just suggestions, you need to ‘Add to Topics’ before they are added to your chatbot.

Authoring Canvas

This is a second and very important building block! The Authoring Canvas is the place where you can design the flow you would like your chatbot to execute when a certain topic gets triggered. ! This is per topic ! There is unfortunately no way to get an overview of all Topic flows.

Each flow will always start with a box showing all the Trigger Phrases for that Topic.

The boxes are officially called ‘Node’ according to the documentation of Microsoft, so for convenience I will use the term Node from now on.

By default, the Trigger Phrases Node is connected to a Message Node, but many other type of Nodes are available as well! You can add a new node by hitting the plus (+) icon on the branch at the end of the node. This will open up a dialog box from which you can choose the type of Node. Let me give a quick overview of the possibilities:

1. Question Node (Ask a question): As it speaks for itself, this option creates a Node for which you can edit the following fields:

• Text that should be send to your user (i.e. you question itself)
• Identify: This field enables you define what you expect as a response of the user and how the chatbot should handle it.
  By default, this is ‘Multiple Choice Options’, allowing you to predefine some options for the user to choose from (which will be showed as buttons). Many other prebuilt entities are available as well, being concepts the computer is already trained for to recognize in text (like: date, city name, phone number, color…) → for you to use out-of-the-box. 💪🏻
  I decided to go for ‘Multiple Choice Options’ to get the exact ‘Type of Password’ my user wants to reset: ‘Bitlocker’, ‘Windows’ & ‘Pass’

😊 😊!! When testing I noticed that you were also able to: Write the option or write a sentence containing the option. In case of a typo → the question got posed again with the option you tried to mention, as a double check.

• Save Response as: This allows you to define under which variable name you would like to save the response in the memory of the chatbot (to use it in a later phase of the conversation again).

2. Condition Node (Add a condition): Allowing you to make decisions based on the response of the user. For example: to skip a certain part of the flow or check whether a given date is in the past or future.

3. Action Node (Call an action): to connect your chatbot to Power Automate (part of the Power Platform, previously known as: Flow). For example: if you would like your chatbot to send an e-mail or create and upload a file.

4. Message Node (Show a message) — Default: In case you just want to send a message to your user. You can change the layout, add bullet points, show a link… You can also insert a ‘Context Variable’ in your text, which are the variables you saved in the chatbot’s memory.

5. Switch Topic Node (Go to another topic): To force the trigger of another Topic and change the current flow to another Topic’s flow.

6. End Conversation Node (End the conversation): To finish the conversation you can choose to end it with a survey or transfer it to an agent.

By using these different type of nodes, you can design the conversation flow as you wish. In the image below, you can see the flow I created for my ‘Password Reset’ Topic. Ready for the next, very important step: Testing!

Test your bot

At any point in time you can test your designed conversation flows. By selecting the chatbot icon in the bottom-left of the portal, the Test-window will open up. Here, you can start mimicking a conversation to try-out your chatbot. There is a possibility to switch on the ‘Track between topics’. A great feature, allowing you to look under the hood and see which decisions your chatbot made based on your input! It shows you the Topic that got triggered and what step in the flow he executed successfully.

Next mission: being a pain in the ass and forcing my chatbot to make mistakes! 😈 This led to a big (BIG) surprise! As you can see in the previous image, I trained my chatbot for a Topic ‘Password Reset’. In this Topic’s flow, I designed it to ask an additional question before showing an answer. This is a Multiple Choice Option to specify the type of password he or she is having issues with. The test-devil in me couldn’t resist of trying to make the chatbot look dumb and in a first message I already mentioned the specific type of password I wanted to reset. Expecting it to fail and offering me the options again, the chatbot understood that I already provided a Password Type and thus skipped the additional question! In other words, a built-in Natural Language Understanding feature. That’s awesome 🔥 🔥 and is really a game-changer for chatbot developers!

Other great possibilities

Publish

With just an easy click on the button you can publish your chatbot so it can be accessed from outside of the platform. You can configure a channel of your choice to push the chatbot on. Another possibility is to make use of the demo website provided by Microsoft. This shows you a basic website with an in-built WebChat version of your chatbot and allows you to share and perform some tests with externals!

Analytics

The analytics look promising, but I think they need to improve the performance a little. They are not “real-time”, meaning: there is a delay of 1 hour before conversations gets processed and stats are visible. After 1 hour, stats about the conversations executed (including the in-portal and demo website tests) are processed and visualized with Power BI! You can also access the raw data of your sessions and download them as csv-files, containing transcripts and other details of each conversation.

Remark: For analytic purposes, I would recommend always to end your flows with or a ‘End Conversation Node’ or a ‘Switch Topic Node’ in which you redirect the flow to one of the System Topics (i.e. Goodbye, Start over..). In that way, you create better stats about the success & failure of your chatbot. I didn’t provide clear ends to my flows. As a result, many of my tests were considered as ‘abandoned conversations’, although they were successful.

Some current downsides

Re-training and improving your chatbots ability to recognize topics. While testing I noticed that my Topic ‘Password Rest’ wasn’t trained enough (i.e. not enough Trigger Phrases were provided). As a consequence my chatbot showed a default ‘I don’t understand’-message.

It would be a great feature if all the utterances that were not understood by the chatbot get summarized and you would be able manually appoint the utterance to the correct topic (if possible). So adding them as Triggered Phrases and hence, re-training your chatbot to improve its performance.

A button to go to the Authoring Canvas you want, directly. Now you can only do this by: first navigating to the Topics pane → selecting the Topic you would like to see → In the Topic Detail view clicking on th ‘Go to authoring canvas’ button. Only then, you are able to view the Topic flow in the Authoring Canvas. If you would like to switch to another Topic’s flow, you need to perform all these steps again…

Modifying the default ‘I don’t understand’ message. I‘ve tried to search the Message Node of this default ‘I don’t understand’ message, but unfortunately I wasn’t able to locate it in the portal. Maybe it is in there, so any tips or guidelines would be very helpful!

My personal conclusion

Loved it! ❤️ It is really a game changer, very easy to understand and to work with. It enables a chatbot project team to visualize the chatbot more quickly and try it out with a limited amount of people (→ “Design, develop, dare to deploy.. repeat!” 😉). The demo website with built-in WebChat example is a big plus! The fact that the Natural Language Understanding part is built-in and automatically enabled for your custom entities is great! Very promising tool and really happy I found some time to test it out. Already have some clear ideas in mind how to use this tool to let my clients’ chatbot wishes take off!🚀

Don’t forget to give us your 👏 !

Unboxing: Power Virtual Agents was originally published in Chatbots Life on Medium, where people are continuing the conversation by highlighting and responding to this story.

A quick background check

As this is my first post ever, I will quickly introduce myself.

So I studied Sports at the University in Leuven (Belgium) (because I ❤️ sports). Realized that it would be very difficult to create a profession of this specific passion in Belgium, so decided to go for a second master: Human Health Engineering. During this study we learned to combine human physiology, engineering and technology focusing on healthy and ‘sporty’ human beings. Just my cup of tea! Anyway, I learned to write code in Matlab and Python, gained more and more interests for programming and data science (data processing, clustering, dimensional reduction..) and in the end, finished doing my master thesis about decomposition of 3D motion captured data of place kicks performed by the South-African National Rugby team using PCA (did I mention I love sports? 😍).

I can already hear you thinking: “Well how the hell did she ended up writing this blog?!”. As a matter of fact, I got a job at a small start-up focusing on Artificial Intelligence (AI). And, despite the fact that AI is such an intriguing and exciting world, apparently chatbots are a very common species! Don’t understand me wrong. It’s not that chatbots are not exciting, but whether they should be considered AI.. That’s a different question.

Top Articles on How Businesses are using Bots:

1. Chatbots: What Happened?

2. Fifty of the best chatbot use cases

3. How Businesses are Winning with Chatbots & Ai

4. Chatbot Conference in San Francisco

But lets not jump right into conclusions! I will start explaining what a chatbot is to get every reader on the same track. Then I will break down my experience into pieces of best practices. So let me introduce you to: the ‘Hello world’ of chatbots!

Chatbo(t/x)s?

I am still suprised about the typical reaction I get when I try to explain my job to (non-technical) people. At first, I tell them I am an Artificial Intelligence (AI) Engineer and in order not to sound like a chinese speaking person, it should be quickly followed by some explanation. To illustrate the type of work I do, I often refer to a chatbot. I don’t know why, but first of all they always think I said ‘chatbox’ (which can perfectly be because of my pronunciation, so I am ok with that). And second of all you can clearly see them wondering “What in the world is a chatbo(t/x)?!”. In which I quickly continue with:

“Did you ever noticed that small chat window popping up when you visit a website? Well most of the time, the one you are chatting with is a person or employee of that company. What we do, is replacing that human person with a ‘robot’!”.

Simple, right? Although people instantly get the picture, I have to admit after being fully involved with designing and developing chatbots for more than a year: we’re not there yet!

Buzz, hype, next generation of apps..

Chatbots have been a major buzz the last couple of years. Since 2015, chatbots started popping up like corn in big and small companies and this on many different channels. Facebook Messenger, Skype (for business), Slack, Team or as a traditional web chat hosted on a website.. you name it! Even Whatsapp for Business has chosen the chatbot-path since September 2018. Chatbot are not only used for marketing purposes (e.g. to promote and make the experience of customers more personal), but also to make internal company processes become more efficient or to share info with users in a more interactive and natural way. We can’t really deny it anymore that chatbots start to become part of our daily lives.

But it hasn’t been all bright and shiny. With the initial launch of the hype, the expectations were high. Too high. The chatbot technology wasn’t ready at all to achieve the things they were expected to achieve. A major setback, making some people to disbelieve the future and ability of chatbots.

Expectation management is key to get a chatbot up and running (live)…

To prevent this love ❤️ to turn into hate 🔥, please, make sure to manage the expectations! Not only for the end-users, but also the company paying you to develop a chatbot. It are mainly their employees that will be using (read: testing) the chatbot in the first place.

Before chatbots are exposed to the end-users, lots of testing and (re-)developing will take place. It will be members of the project team and maybe other colleagues that will face the chatbot many times before the launch. Keeping them motivate to continue testing is crucial. If they expect too much, motivation will drop and the chatbot will never improve. In my opinion it is even the major reason why chatbots don’t make it to production. Managing the expectations from the start and getting everyone of the team aligned with the strengths and weaknesses of a chatbot will determine the success or failure of the chatbot. My best practice would even be: let them talk with an existing chatbot as soon as possible. Whether the chatbot is related to the one they will develop or not.. It will only make it more clear and easy to understand that a chatbot at this point in time has its setbacks and will take a lot work and effort.

… and actually being used!

When end-users will use your chatbot, you will not be able to be there and sit next to them to give guidelines how to use the chatbot or say “This question is one that can be answered, but that one isn’t”. So it is again crucial to manage their expectations. Everyone knows the cliché quote:

“You’ve only got one chance to make a first impression!”.

This also counts for a chatbot. I even dare to say that the welcoming message is maybe the most important message your chatbot will send. It gives you the opportunity, not only to welcome the user, but also to give them already a glimpse of the chatbot’s personality (e.g. the tone-of-voice) and some guidelines of how the chatbot will work and what it can be used for. Give hints about the answers it can handle or define the possible actions by using ready-to-go buttons and encourage them to click one.

In this way, users know what to expect instead of letting them dive into the conversation head-first. If not, disappointment and annoyance will overrule the experience of the user and your chatbot will end up somewhere far below in their Facebook messenger chat list, left alone and eventually to be forgotten. Chatbots just ain’t perfect (yet!) and accepting and being honest about that fact will only work in your own favour.

Low effort — High impact

When starting with the design of a chatbot, clarify the context with the project team by answering these questions first:

• Why do you want a chatbot?
• Is a chatbot the best way to achieve this, now you used one yourself and know the strength and weakness of this technology
• Who will be the end-user?
• What will be different with what the end-user is doing today?

Based on the answers you need to define a limited scope that can be achieved with the lowest effort and the biggest impact. If this means your chatbot will only be able to answer 75%* of the questions typically being asked, or help the end-users until a certain point in the companies process.. Just Do it ! Just make this clear to your user and try to catch the other 25%* in the most elegant way as possible. Limiting and accepting this scope, will make it more easy to put the chatbot in production. And please, don’t create a chatbot just for the sake of chatbots.

“Design, develop, dare to deploy.. repeat!”

I can imagine you thinking: “Why in god’s name should I put that thing into production, knowing that it will only perform 75%* in the right way?”. Well, designing a chatbot will ask for you and the project team to make a lot of assumptions. You have to try and think like the end-users and design the conversation like you think it will happen.. But let me assure you.. It is impossible to imagine all the possible scenarios that can happen. Putting the chatbot in production and making sure you are able to catch the actual behaviour and feedback in a structured way is the most valuable step you can take with a chatbot. If you really can’t get your head over this 75%*, put a human in the loop! Enable human-handover to cover the other 25%*. It is again a crucial ingredient to success. You will have true feedback and a better view of what the chatbot should be able to do and in which part you shouldn’t put too much effort!

(*The percentages being used here are a matter of speaking and depend on the usecase, but you get the picture..)

Where are A̶r̶t̶i̶f̶i̶c̶a̶l̶ ̶I̶n̶t̶e̶l̶l̶i̶g̶e̶n̶c̶e̶ and chatbots today?

No it is not a typo.. To be really honest, you still need to scratch the AI part when it comes to chatbots at this point in time. A good design, nice copy writing and calling existing APIs in the backend, that’s what defines a good chatbot today. Natural Language Processing (NLP) can of course be used, but limited. It can be used to recognize the intent of the end-user and route the conversation to the right branch in the flow, but in the end this flow will always be something you and the project team designed. The limitations are still to big to only rely on NLP to handle the conversation in a good way. Secondly, not to burst your bubble, but today, there is no such thing (yet) as Natural Language Generation (NLG). A chatbot is just hard work! Designing the flow and formulating the answers the chatbot should sent back are all done manually today and take a lot of time to think through. Chatbots are still human driven web applications with a conversational interface and are not even near the ‘Intelligent assistants’ they often refer to.

Conversational UX developers are the next generation of copy writers

Ok, so I went from breaking down an intelligent chatbot into a web application with a conversational interface. That’s maybe a little bit harsh. To create a successful chatbot, you actually need more than that of course. The conversational user experience(UX) should be as natural as possible.

One way to achieve this is giving the chatbot an Understanding Character and therefore to take human psychology into account. Humans need empathy. If ones bike has been stolen, this person is mad. If someone wants to change her address, she will probably not be mad. So the chatbot should react differently in each situation by showing the right empathy. Depending on the scope, the chatbot should encourage (for example: when users go to a long flow of answering questions), persuade by reward, sell, convince.. and all of this can be achieved by copy writing techniques. Never expect a user to use the buttons to answer a yes or no question. And if they don’t, please avoid answering: ‘you need to respond by yes or no’! You need to foresee fallbacks for every level of your conversation in the most natural way and the best way to do this is to make use of the history of the conversation!

It means that the person (or team) developing the chatbot should not only have technological skills, but should be able to combine it with human psychology and copy writing. These three ingredients define the Conversational Designer, a new role in the team of a chatbot development project. So focus on the basics first, but for the ‘wow’-effect: anticipate, be proactive and care for customer!

If you like to dive deeper into the Conversation Design part, Robocopy, a company in the Netherlands is always my top of mind. I have been able to speak with and follow a presentation of the founder at the Chatbot Summit 2018 and I was intrigued from start till end!

Death of websites and apps?

The answer is no. They will not replace websites or apps, they just offer another channel to get in contact with your end-consumer in a more intimate way. It can provide more context about a user, making it able to approach them on a more personal level. So chatbots can have a hugh potential, IF they are designed in the right way!

So why should you hook up with a chatbot in the end?

• They are fast! If it’s build in a good way, chatbots can answer questions more quickly than humans will ever be able to. And in society of today: Time is money! Giving the right information in a fast way to the users will be one of the most important values of a chatbot. If the user experiences there is another, faster way to do what she wants to do, she will not use your chatbot..
• The fact that they can be used 24/7
• Cooperation: take over small tasks, those typical FAQs, while employees can focus more on the complex tasks and bigger things.
• Chatting is our (second) natural way of communicating: we all tap our phones 3000–5000 times each day.. And I bet 95% of the readers of this blog have at least one messaging app on their front page of their smartphone. We can’t deny that the conversational interface is and will stay part of our daily lives (until voice takes over, but let’s discuss that some other time 😉 ).

Pssst.. just one last thing

From one Conversational Designer to another (future) Conversational Designer.. just want to give you want last tip to keep in mind when developing a chatbot:

“You will fail, technology still needs to catch up, but when failing try to catch it as elegant as possible! 😉”

Don’t forget to give us your 👏 !

“Hello world (of chatbots)!” was originally published in Chatbots Life on Medium, where people are continuing the conversation by highlighting and responding to this story.