This document explains things to consider before creating a chatbot service.
A chatbot service should be tailored to the main objective of the service. Before starting to create a chatbot, set specific service objectives.
For example, you can set the chatbot's objectives as follows.
- To add a channel to respond to customer enquiries to the existing inquiry response channels (such as customer center calls, email consultation, and online chat, etc.)
- To reduce resources responding to the inquiries coming in through existing channels and replace them with chatbot consultations
- To maintain existing channel resources but convert them to sales/marketing resources
- To replace existing channels with chatbot consultation and receive human consultation for only the cases the chatbot can't handle
You should select a chatbot type and consider its answer coverage according to the service objectives. Chatbots are categorized into two types: one that only gives closed answers and one that can also provide open answers. It is possible to combine both types.
Chatbot type that only provides closed answers to users' questions
- Only provide answers for the customer service inquiries such as FAQs
- Provide answers for the overall services, besides the customer service inquiries
Chatbot type that also provides open answers to users' questions
- Provide answers to a shipment tracking request (It should be confirmed and decided which type of answer needs to be provided and how many services you want to support.)
- Provide answers to a request to have a service technician visit (It should be decided which types of answers require processing of tasks such as sign up and changes, and how many services you want to support.)
It's a scenario to handle the service's main objectives. For instance, you can set up a flow of scenario where the chatbot understands the user's intention to make a reservation, validates the reservation information by filling the information in the slots, and checks and confirms the reservation for a reservation scenario.
Repair scenarios refer to scenarios that send the user back to the flow of the Main scenarios and help to achieve the main objectives of the service when the user has wandered off from the Main scenario.
It's a scenario that can be entered or come back from, although it's not a Main scenario.
Consider the number of consecutive Repair scenario matches
- Consider whether to go back to the Main scenario immediately
- In cases a Repair scenario is matched consecutively, consider whether to make the user go back to the Main scenario up to Nth time, and to end the scenario or connect the user to a human consultant after the Nth match
Consider whether to re-utter the utterance of the previous chatbot
- Consider whether to reiterate the chatbot utterance in the Main scenario immediately before
Design other expected scenarios
- Are the checking, changing, and canceling orders also going to be handled?
- Are the orders going to be accepted only for the same day?
- The maximum group order capacity?
- If something is out of stock, is the recommended time going to be suggested?
- How many days in advance can an order be placed?
- In a case an order was to be processed as completed but then another order came in between, how is it going to be handled?
You need to choose a channel to link your chatbot service. You may not be able to use certain CLOVA Chatbot features depending on the channel linked, so it's vital to check the features that can be implemented in the channel to be linked in advance.
You can choose the channel to link with the following standards.
- Text type
- External messenger services such as LINE, TalkTalk, and Facebook
- Internal messenger services including custom webpages and apps
- Voice type: External devices such as AI speakers
The following are unavailable features for use by channel.
- Push messages
- Fixed menu
|NAVER WORKS||- Feedback
- Push messages
|CLOVA Extension||- Feedback
- Push messages
- Fixed menu
|Welcome message||All messenger services|
|Consecutive answer||All messenger services|
|Sticker answer||LINE messenger|
|Flex answer||LINE messenger|
|Push messages||- LINE messenger
- NAVER TalkTalk
|Fixed menu||- LINE messenger
- NAVER WORKS
- NAVER TalkTalk
To build conversation datasets after selecting a chatbot engine, you need data that is appropriate for the chatbot's answer coverage. It's best to refine and use the existing data. There may be some data that can't be used for certain service objectives, so choosing the datasets carefully at the beginning can save time in building the learning data.
Refining data must be done before building conversation datasets. This is the most time-consuming task, and it requires highest level of caution. Using unrefined data lowers credibility for the answers provided by the chatbot, which may affect the company's image negatively.
Existing data that can be used to build chatbot datasets is as follows.
- "FAQ," "1:1 inquiries," etc., of a website
- Chat inquiries
- Question types, inquiry codes, etc., from incoming calls to customer center
- STT data from customer center recordings
Conversation dataset must be built by an expert in the service domain. It's essential for this person to know in detail what users ask frequently, what tasks the users have trouble with, etc., and to be able to provide accurate answers for these questions. For the best efficiency, have someone who is actually in charge of such work (customer service agents, someone who drafted training material for a new product, etc.) to build the conversation datasets.
A chatbot service is not finished once built. It requires constant relearning. In particular, if there are changes to the customer's business such as a new product's release, then the latest information must be reflected immediately. Therefore, a policy for constant conversation dataset maintenance and service deployment management needs to be established.
Write a detailed scenario where you plan the flow of chatbot conversations. Consider how the messages will be provided, from a welcome message which is the first greeting to the user who executed the chatbot, a failure message to be sent when there's a message input the chatbot can't understand, to a feedback message to evaluate how satisfactory the conversation with the chatbot was, etc. In addition, you should prepare the expected user questions and their answers, and decide how to provide those answers. They can be provided as simple text answers or external links. More complex conversations can also be built using forms, tasks, and action methods.