Design a Chatbot on MS Teams. Part 1
Designers must know subject matter, technical capabilities, and limitations at the start of any project. Searching for manuals and reviewing open-source materials takes a significant amount of time, especially when it comes to specific systems.
To address these challenges, I will share my experiences in building a chatbot on the Microsoft Teams platform.
Introduction
Before starting to build a chatbot, I aggregated information from different sources to form a general picture of best practices and how technically “heeled” my chatbot could be in the long run.
I learned from several failed attempts which why I’m sharing this to provide you with a smoother and relatively quick “entry” into the world of chatbots for Microsoft Teams.
What is a chatbot?
First, let’s clearly define that a chatbot is software that mimics human-like conversation with a user to meet a particular user’s need(s). According to WebsiteBuilder statistics, 40% of millennials use chatbots daily. Many believe that chatbots are the newest trend in modern technology, but chatbots actually have origins from the past century.
The first chatbot was introduced in the 1960s by Joseph Weizenbaum and was named Eliza. It was a virtual companion that emulated a conversation with a psychotherapist while demonstrating active listening.
In 1972, humankind would meet PARRY, a chatbot that emulated a human suffering from paranoid schizophrenia. Inspired by ELIZA, the Artificial Linguistic Internet Computer Entity chabot known as ALICE arrived in 1995 for natural language processing (NLP).
I believe that chatbots are a promising and powerful technology that helps substitute manual tasks in a digital environment. Chatbots accelerate daily routines through, help solve urgent problems more quickly, and in many cases, find database information with a single click.
That history doesn’t help you build a chatbot, but it does give you something to share at your next mixer or meet up! But now that we’ve defined chatbots, let’s take the first steps in building yours.
Defining Chatbot Purpose
As I stated at the start, framing the distinctive goal of your chatbot helps define primary use cases, as well as where and how the bot comes into play. You’ll reverse engineer once you have the end in mind.
For example, do you wish to:
- Create an online meeting for your colleagues to join?
- Quickly display information about team and manager?
- Learn about your company’s vacation policy in one click?
…and so on.
If the chatbot serves for improving employees’ lives in terms of time-saving and work efficiency, then you’re on the right track.
Artificial Intelligence (AI) capability
Microsoft chatbots are smart and their intelligence level can be set depending on the complexity of performance.
NLP (Natural Language Processing)
Making chatbot innovatively smart and AI-based is a good practice in case interaction with the user will include open-ended questions. Such bots learn from previous conversations and have memory (like people do), can interpret the user’s inquiry contextually and parse text inquiry with the help of NLP. Thus, LUIS API (Language Understanding Intelligent System) comes into use.
Rule-based
Not all cases are good for using NLP. In case the chatbot’s complexity is extremely basic and it needs to answer specific and not open questions (e.g. “yes/no” questions and questions with options to choose from), this technology may be not needed and the liner conversation flow will be enough. Despite seeming basic and primitive and not flexible enough to users’ inquiries, rule-based chatbots are cheaper and faster and determined to solve the primary user’s problem with some predictable answers.
Deep linking functionality
This is a good means to automate some tasks or navigate to some tabs (when chatbot needs to show some content/functionality outside the chat area).
Deep linking is highly valuable if the digital product consists of a so-called workspace (tab) and the chatbot itself and there is a need to let the user switch from the chat to the tab occasionally. More about deep linking is here.
Stand-alone vs part of the app
It’s worth stating that chatbots in MS Teams can functionalize in two ways: as a standalone entity or as a part of the app in MS Teams.
Stand-alone entity
The chatbot can solve the user’s problem directly in the chat area with the help of adaptive cards.
A part of the app
Chatbot functions as a conversation starter, which helps the user install the app in the tab and can demonstrate the product’s functionality for quick acquaintance. With the help of deep linking, it leads the user to the tab or extension with richer functionality, where they can perform some actions manually.
Scopes
Bots in Microsoft Teams can be involved in a conversation with one user, a group of people, or a channel in Teams. Microsoft calls these kinds of conversation as “scopes” and provides such definitions:
Teams scope
Also called channel conversations, visible to all members of the channel.
Personal scope
Conversations between bots and a single user.
Group chat scope
Chat between a bot and two or more users. It also enables your bot in meeting chats.
The chatbot operates differently depending on the number of people. Defining the scope at the starting point helps see how many use cases the chatbot will cover.
This is the first part of the article, so stay tuned for the second part, where I am going to focus on design-related peculiarities, such as conversational flow and communication manner.
