--- title: "Designing chatbot" slug: "chatbot-chatbot-1-2" tags: ["chatbot", "CLOVA Chatbot"] updated: 2026-09-17T09:33:52Z published: 2026-09-17T09:33:52Z canonical: "guide.ncloud-docs.com/chatbot-chatbot-1-2" stale: true --- > ## Documentation Index > Fetch the complete documentation index at: https://guide.ncloud-docs.com/llms.txt > Use this file to discover all available pages before exploring further. # Designing chatbot Available in Classic and VPC This document explains things to consider before creating a chatbot service. ## Set service objectives 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 ## Set answer coverage 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.) ## Set scenarios and response range ### Scenario types **Main scenario** 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. Understanding the user's intention, filling out the order information slots, validation check of the reservation information, order confirmation, etc. **Repair 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. No response from the user, unable to understand the user's intention, etc. **Global scenario** It's a scenario that can be entered or come back from, although it's not a Main scenario. Request to utter again, finish the call, request to speak to a human consultant, FAQ lookup, etc. ### Considerations in scenario response policies **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? ## Decide channel to link 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 ### Features unavailable for use by channel The following are unavailable features for use by channel. | Channel | Unavailable features | | --- | --- | | LINE messenger | None | | NAVER TalkTalk | Feedback | | Facebook | - Feedback - Push messages - Fixed menu | | NAVER WORKS | - Feedback - Push messages | | CLOVA Extension | - Feedback - Push messages - Fixed menu | ### Supported channels by feature | Feature | Supported channels | | --- | --- | | Welcome message | All messenger services | | Consecutive answer | All messenger services | | Feedback | LINE messenger | | Sticker answer | LINE messenger | | Flex answer | LINE messenger | | Push messages | - LINE messenger - NAVER TalkTalk | | Fixed menu | - LINE messenger - NAVER WORKS - NAVER TalkTalk | ## Build conversation datasets 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. ### Refine 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 ### Need for the right person in charge to build conversation dataset 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. ## Manage maintenance and deployment 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. ## Design chatbot scenarios 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.