As Eliza showed 55 years ago, and Nass and Reeves showed was generally true for technology, we are easily fooled into anthropomorphising and reading agency into chatbots and technology in general. In truth, chatbots don't talk to you, they pretend to talk to you. They are tricksters. In a sense all human-machine interaction is trickery. It is, in the end, only software being mathematically executed with some human scripts thrown in. Nevertheless, they are surprisingly successful. Even simple Alexa has been a massive hit, and she (well it) only answers simple questions, with little or no dialogue.
Interestingly, this immediately raises an issue for chatbot deployment – setting 'expectations'. Do you tell users that it is just a piece of software or do you keep up the 'magic' myth? How honest will you be about its capability, as you may set the bar too high and get lots of disappointed users. Here's a few other practical things to think about when you enter the weird and wonderful botland….
1. Domain knowledge
First up – on expectations - and this is really important. Remember that chatbots are not generalists. They are domain specific, good at specific tasks within defined domains. Google Duplex works only because it does domain specific tasks – call a restaurant and book a hairdressing appointment. Some services offer domain specificstores of messaging transcript data, with detailed tasks for each industry sector, such as Dialogueflow and Liveperson. Some even focus on core use cases, which are mostly designed around customer service. Most are a long way off being a genuine teacher, coach or mentor, as they lack the general ability to deal with a breadth of unexpected queries and answers. So dial your expectations down a notch or you'll be setting yourself up for failure.
2. Voice
Your chatbot needs to have a voice. It's too easy to just throw a jumble of responses into a database and hope for the best. In organisations, you may need to be on brand, talk like an expert and not a teenager, use humour (or not). Define a persona and build styleguide. At the end of the day, lots of responses have to be written and they need to sound as though they have a single voice. In learning especially, you have to be careful in tone. Too many chatbots have a surfeit of phrases that sound as they're trying too hard to be cool or funny. In learning, one may want to be a little more serious. This depends, of course, on your intended audience and the subject matter. Whatever the project think about the 'voice' in this wider sense.
3. Manifestation
Linked to voice is the visual and aural manifestation of your chatbot. Think carefully about the appearance of the chatbot. Some stay sex neutral, others are identified as male or female. Many, perhaps too many, appear like 1950s square robots. Others have faces, micro-expressions, even animation. Then there's the name. Be careful with this – it matters. And do you want one name or a separate name for each domain or course? Giving your bot a face seems a little odd and I prefer a bot identity that's a little more hidden, that leaves the persona to be built in the mind of the user, almost unobtrusive.
4. Natural language processing
Understand what level of technology you want to use. This can mean lots of things, from simple keyword recognition to full speech recognition (as in Amazon.lex). Be very careful here, as this is rarely as good a vendors claim it to be. When a vendor says they are using deep learning or machine learning, that can mean many things, from very basic NLP techniques to more dynamic, sophisticated tasks. Get used to the language of 'intents' – this is related to the domain specific issue above. Chatbots needs to have defined tasks, namely 'intents' (the user's intention) as identified and named actions and objects, such as 'show weather'. These are qualified by 'entities'. It is worth getting to grips with the vocabulary of NLP when buying or building chatbots.
5. Building
Many chatbot services offer a no-coding tool to build your flow, others require more complex skills. Flowcharting tools are common, and these often result in simply asking users to choose from a set of options and branching from them. To be fair, that keeps you (and the bot) on track, which may be the way to go in structured learning. Others will accept open input but steer you towards certain types of responses. One thing is for sure, you need new skill sets. Traditional interactive design skills will help, but not much. This is about dialogue not monologue, about understanding complex technology, not just pages of HTML.
6. Your data
How do you get your data into their system. This is not trivial. How do you get your content, which maybe exist as messages, pdfs, PowerPoints and other assets into the format that is needed. This is far from automatic. Then, if it's using complex AI techniaues, there's the training process. Youbreally do need to understand the data issues – what, where and how it is to be managed – and, of course – GDPR.
7. Hand off to humans
What happens when a chatbot fails? Believe me this is common. A number of failsafe tactics can be employed. You can do the common… ask the person to repeat themselves "Sorry, I didn't catch that?" "Could you elaborate on that?" The chatbot may even try to use a keyword to save the flow, distract, change the subject and come back to the flow a little later. So think about failsafes. If all else fails, and many customer chatbots do – they default out to a real human. That's fine in customer service, and many services, like Liveperson and Boutique.ai, off this functionality. This is not so fine if you're designing an autonomous learning system.
8. Channels
On what channels can the chatbot appear? There are lots of options here and you may want to look at what comms channels you use in your organistion, like website chat, in-app chat, Facebook Messenger, Slack, Google Assistant , Skype, Microsoft Teams, SMS, Twitter or email. The chatbot needs a home and you may want to think about whether it is a performance support chatbot, on your comms system, or a more specific chatbot within a course.
9. Integration
Does the chatbot have an open API and integrate into other platforms? Don't imagine that this will work easily from your LMS, it won't. Integration into other systems may also be necessary.
10. Administration
Your chatbot has to be delivered from somewhere, so what are the hosting options and is there monitoring, routing, and management. Reporting and user statisticsmatters with chatbots, as you really do want to see if they deliver what they say, with user stats, times, fallout stats.How are these handled and visualised? Does your chatbot vendor have 24/7 customer support? You may need it. Lastly, of you are using an external service, be careful about them changing without telling you (it happens), especially the large tech vendors, like IBM and Microsoft.
Conclusion
We are only at the start of the use of chatbots in learning. The trick is to play around with all of the demos online, before you start. Checkout the large vendors such as:
Remember that these are primarily chatbots for customer service. For learning purposes, I'd start with a learning company first. If you want any further advice on this contact me
here.
