This feature is currently available to Early Access Program users. If you wish to sign up to get access, please reach out via email.
This article will showcase a few customer interaction use cases that can be easily automated using our Natural Language Processing (NLP) Flow Builder steps.
We will do this by introducing a chatbot functionality for an imaginary company that can automatically handle most cases of users reaching out with questions or requests.
Imagine that we own a bowling gym. Let’s call that “Bowling Alley”. Our business model is quite simple — we make money when people come to our gym to play a bowling game or purchase from our trendy merchandise.
We already have a website where people can go to reserve a game, find and buy our merchandise — and register their purchased products for a chance to win our big prize, a trip to Curacao.
We want our customers to be able to do all that, using their favorite messaging channel. This way we can make it more convenient for them to:
- Make a reservation
- Cancel a reservation
- Find information about available products
- Track their order
- Request a refund for their order
- Register for our lottery
- Ask general questions about the bowling gym
For showcasing this functionality, we’ve created a Telegram bot to handle communication with customers. This functionality is not limited to Telegram. Setting this up to work with multiple communication channels can be done from our channels page. You can try our bot out yourself here.
Finding out what the customer problem is
The first step of our assistant would be to find out what the client needs help with. After greeting them, we then give them a short message that describes what we can help with and ask for their input. Since they can respond to each option with many different phrases that mean the same thing, we need to use a smart approach to determine their intention.
This is where our Recognize Intent step can come in handy. To use it, we would need to set up a dataset with some example phrases that the user could say or type for each use case that we want to address. How to configure that is described step-by-step in our Intent recognition article.
Make a reservation
In order to reserve a game slot for our customers, we need to collect some information first:
- Date and Time
- Total number of people that will be joining
Since we know the type and format of the “information” we are expecting, this is a good candidate for our Recognise Entities Flow Builder step. You can learn more about what Entity recognition is and how to set it up in our article here.
For our case, we only need the Person (to capture name), Time (to capture desired reservation date and time) and Numeral (to capture the number of people) entities that come pre-defined. After we request those entities from the user, we need to check if any are missing and ask for them again as shown below. After gathering all the needed information, we can then even add the event to both our and the client’s calendar to make it even more convenient.
Cancel a reservation
Cancelling a reservation is possible, but it is dependent on the scheduling system you are using. The way to approach this would be similar to making a reservation. You would use Recognize Entities to get the necessary information from the user and then forward this to the backend service that takes care of this. For example, by sending an HTTP Request or simply notify the person responsible for cancelling reservations.
Find information about available products
If the user wants to know more about the products we have currently available, we could either respond with some pre-populated information or forward them to our webpage where they can find our products.
Delivering products usually involves a third-party delivery company. Most delivery services allow for order tracking when given an order ID. In order to make this easy for our clients, we could simply ask the user for their order ID and forward them to the website where they can see the status of their order. As the order ID has a specific format, usually a number with a limited number of digits, we can use a Custom Entity here.
Order refunds do differ in terms of policies. In our case, we would only need the user to provide their order ID. If we can find that ID in our database using our backend, we can therefore send instructions on how our client can return their items and get a refund.
Register for lottery
For our users to participate in our lottery, they need to first purchase an item from our website. Once they’ve done that, they would need to register the product using the barcode that they can find on the label. This could be either by entering the code manually or by taking a photo of the barcode and sending that to us. In the case they send a photo, we can automatically extract the barcode number or any information that it stores using our Analyze Image step. See a detailed description of what our Analyze Image step is capable of doing here.
Ask general questions
We also want to handle any other questions that users may have regarding products and services. To do so, we have defined a dataset that holds examples of frequently asked questions by our users. We can then forward their question to our Answer FAQ Flow Builder step, finding the most appropriate answer based on the incoming question. In the case we do not have a close enough match, we would forward that question to one of our support agents. To find out more about setting up and making use of our FAQ functionality, check out this article.