At Lekta AI, we’ve been building chatbots since early 2017. While each project is unique, we found that certain universal principles can be applied regardless of the business domain, target audience or communication channel. Over the years, we’ve developed a battle-tested process that helps us deliver consistently great conversational experiences for our clients and their customers.
In the next 4 articles, we’ll share with you our modus operandi — the exact bot design process we shaped, refined and currently rely on at Lekta. The upcoming series of articles can serve as a comprehensive resource for anyone looking to build great bot solutions, and will cover the following areas:
- Requirements discovery (covered in this article)
- Chatbot Personality
- Conversational Best Practices
- UX Design Best Practices
Let’s dive in!
Requirements Discovery
Any chatbot design process should start with requirements discovery. We’ve found this is the most powerful, yet often the most overlooked step of the process. At Lekta, we use the discovery phase to help our clients make important decisions regarding their businesses and chatbot solutions. It’s crucial to get this step right, as it defines the vision, the future and eventually, the success of the product. In this article, we’ll walk you through the process we’re using to get to the heart of what it is that our customers need.
Start with the big picture
The first step is an introductory session, during which you’ll make sure you got a grasp of the big picture of the initiative in question. Make sure to bring your lead UX designer and lead developer along. This session can take a variety of different forms, depending on your client’s preferences. While our preferred form is customer interview, we’ve had clients prepare kick-off presentations and provide a high-level overview of the project themselves. That’s completely okay, as long as you keep in mind that the level of detail will naturally differ per client. In the end, it is your responsibility, no matter the meeting format, to make sure you have the basics covered.
Now, what kind of information should you elicit during a session like this? And what do you do when your client starts off with dialog trees or a map of their existing IVR (Interactive Voice Response) system? While this information will prove useful later on, it is vital not to become overwhelmed or sidetracked by detail at this stage.
As a rule of thumb, you should take a step back, and make sure to broaden your outlook first — context is key to building great chatbot products. You need to understand where your client is coming from, why they’re investing in an AI solution now and what problems they’re trying to solve. You need to get a pretty good feel for your client’s business domain, existing customer service infrastructure, current business needs and goals.
Getting to grips of the bigger picture early will help you understand the complexity of the business or underlying motivations, and thus foresee potential pitfalls, avert major problems, and reduce the risk associated with changing business requirements or product vision.
By the end of this stage, you should have a pretty good feel for your client, the issues they’re facing and a high-level understanding of the product you’ll be building together.
Understand your stakeholders
Following the big picture, it’s time to understand what departments will be involved in the project on the client-side, and what their goals, priorities, and pressures are.
Chatbots projects are often high-risk and high-impact, and more often than not, they lead to significant changes within the organization. A bot implementation can shake up the entire customer support structure, leading to consolidation of departments, redundancy, power shifts. It’s no surprise some departments may be more excited about it than others. Their expectations and concerns will naturally vary too. Usually, a mix of these departments is involved: innovation, AI, customer care, marketing, security, IT. It’s best if they’re all involved in the project from the beginning so that their perspectives are taken into account, and everyone is aligned from the start.
Here are a few of the questions we ask to understand the stakeholders:
- What opportunities do you see in realizing this process for your department?
- If this project succeeds, what would be the next steps for your department?
- Do you have any concerns regarding this project? (e.g. technology, KPI, process, UX or other issues)
Make sense of the target users
As a next step, make sure you have a good knowledge of the end-users who will be using your product every day. Our discovery approach here is project-specific and varies from client to client. It depends on the use case, the scope of the project, pre-existing user research, and time constraints. Some clients already have pre-developed user personas, others may have a very narrow and already specified target group. If there are multiple target groups involved and no one seems to be aligned, it might be useful to invest in user research. The list of tools you can use to make sense of your audiences is ever-growing, and you should always consider what will work best for you and your client. We usually rely on personas, proto personas, jobs to be done or “Who, what, why”.
Here are some useful questions to ask to make sense of the target audience:
- Who will use the new solution?
- What are their major worries, pains, needs, and gains?
- What are some common problems they usually call with?
- Which of these problems do we want to address?
- What will be the value-added of this solution for them?
- What they might expect from a chatbot?
- What’s most important for them in the process?
Map out business processes
You now know your product vision, stakeholders and target audience. Congratulations! You’re fully equipped to move on to the next step of our process — and this time, it’s workshop time! During this session, you’ll focus on listing out all business processes that your chatbot will be supporting. One of those processes will also be mapped out in detail during the workshop, while the remaining ones will be done internally on your side, and sent over to the client for review later.
So, what is a business process, you may ask? A business process is a collection of linked tasks that find their end in the delivery of a service or product to a client. That service can be anything from a bank transfer to an account top-up or a balance check. A previously mentioned map of existing IVR infrastructure may come in handy here and speed things up, but your client should be easily able to list out the most common business processes for the organization too.
Once that list is ready, it’s time to look at one of these business processes in detail. Typically, you’d start off with the most common use case for the organization, i.e. money transfer for a bank. Commencing with a flagship business process means that everyone will be familiar with the steps needed to complete it. It will be a good warm-up before mapping out more difficult use cases.
However, there are different schools of thought here. Kicking off with the most difficult process also makes sense. You get it over with when everyone’s in the room, and leave the rest for later when you work alone, without your client’s expertise.
It’s best to discuss both approaches with your client, and re-evaluate together which option makes the most sense in this particular case. We can’t stress enough that each project is different, and you guessed it…it all depends!
No matter which option you go for, in both instances, you’ll start off with listing out all the parameters needed in order to complete a business process. That includes both the information required from the user (i.e. transfer title, recipient, amount) and data fetched from external systems (i.e. sender’s account number). At this stage, you leave out everything that can go wrong and assume everything will run the way it’s intended to. That is, the bot will understand everything, the authorization will go right, the bank transfer will be completed — the so-called “happy path” in UX speak.
Next comes the exception path. You should map out all corner/edge cases that could come up in the process and prevent the users from achieving their goal. This could be anything from lack of money on the account to too many characters in the transfer title, or wrong PIN. You should list out general issues that may arise too, i.e. technical errors, internet connection or ASR failure.
That’s it! You will need to repeat this process for all the business processes you want your chatbot to support. But for now, you can congratulate yourself on your first successful discovery requirements workshop — well done!
By now, you should have a pretty good idea of how to gather product requirements and map out business processes your chatbot will support. Comment if you have any questions, and if you’re ready for the next step, make sure to check out Part 2, Chatbot Personality.
