Creating CLOVA AiCall scenarios

Available in Classic and VPC

CLOVA AiCall scenario creation guide

Considerations before building scenarios

Before building scenarios, design services in detail, such as what services to offer, what policies to take, and what information to exchange through API. You can classify scenarios into three types as follows.

• Main scenario
• Global scenario
• Repair scenario

Design the service according to the use of each scenario, and then build the AiCall scenarios by referring to the example of a voice bot scenario.

Main scenario

In the Main scenarios, you define what service to focus on, then design the process for providing that service.

1. Define services to mainly proceed.

   • It can be a voice bot that handles reservation services, or a service that responds to simple FAQs. You can also simply design a voice bot to notify certain content.

2. Define the service process to check what steps are needed to handle the service.

   • For example, if you want to handle the reservation service, receive the reservation information, continue to check the insufficient information, get the final confirmation whether the collected information is correct, and handle the reservation.

   • Then define what information you collect, what answers you give, and what information you will send to the reservation system via API in detail for each step.

3. Define policies for each process in detail.

   • For example, define detailed policies, such as how many group reservations you will receive through voice bots, and how many reservations you will allow at a time.

Global scenario

Global scenarios are not services that focus on handling like Main scenarios, but define inquiries and requests that can be incoming frequently. While you're proceeding with Main scenarios, you will frequently experience situations where you enter the Global scenarios or return to the original scenarios.
For example, they can be FAQs about operating hours and parking lots, requests to connect agents, and requests to finish calls.

Repair scenario

Repair scenarios refer to scenarios that are sent back to the flow of the Main scenarios and then repaired to achieve the main purpose of the service. These scenarios are typically irregular cares or weren't included in the Main scenarios. For example, they include situations where the user does not respond, the user's intention with the response is unclear, or the system is requested to speak again.
Establish policies of Repair scenarios that suit the direction of the service.

Example of an AiCall voice bot scenario

The common procedure for setting CLOVA AiCall voice bot scenarios is as follows. We will explain how to set voice bot scenarios according to the procedure using the example.

1. Define service purpose and policy
2. Design scenario
   1. Design Main scenario
   2. Design Global scenario
   3. Design Repair scenario
3. Enter scenarios in AiCall builder

1. Define service purpose and policy

Define the purposes and policies of the service to provide through voice bot scenarios as follows.

• Service purpose: Restaurant reservation service
• Reservation policy
  • Main scenario
    • Handle new reservations only. Confirmation/change/cancellation of reservation are handled by agents
    • Only one reservation per phone number is allowed
    • 10 or less people can reserve as a group, and people more than that are connected to the store and handled by agents
    • If the desired time to reserve is already full booked, then request a reservation at a different time
    • Reservations are only available from the day they are made to 2 weeks after that day
    • Calls made outside business hours are handled so that they can be finished without connection to agents
  • Global scenario
    • Respond to finishing calls, requests to connect agents, inquiries about parking lots, and inquiries about business hours
    • For FAQ inquiries, respond to the response by the previous system where the marker is set, and return to the location
  • Repair scenario
    • If there is no response for 5 seconds, respond with No response messages
    • Finish calls without repairing if there are three consecutive No response events/speaking with unclear intentions

2. Design scenario

Design each scenario according to the service policies.

ⅰ. Design Main scenario

• Save reservation information and set the user variable steps

• Save the reservation information in that session (corresponding call), and use every time the scenario proceeds.
• Use the concept of a user variable to save the reservation information.
• Set the steps among the user variables as follows to process the reservation, step by step.

• Current step: Save the user's raw speaking information
  reserved date_current, reserved time_current, reserved number of people_current, phone number_current
• Checked step: Save the information that completed the validity check
  reserved date_checked, reserved time_checked, reserved number of people_checked
• Completed step: Save the information actually reserved
  reserved date_completed, reserved time_completed, reserved number of people_completed, phone number_completed
• In addition, you can add or simplify steps, depending on the details of the scenario to be responded

• Design reservation process

• Connect the context to proceed with the reservation in the order of Identify reservation intentions → Enter reservation information → Check the validity of reservation information → Recheck insufficient reservation information → Get final confirmation on reservations → Check phone numbers → Handle reservations.
• Activate the marker to speak again in the answer speech balloons that prompt the user to speak among the answers in the Main scenario, so you can return to the original location of the marker when you leave the Main scenario.
  • For example, if you activate the marker only for the key spoken content as follows, then the message that activated the marker while calling the ${`previousChatbotAnswer} in the Repair scenario (Can you tell me a different day?) will be spoken again when you leave the Main scenario.
    

• Identify reservation intention

• If you identify the reservation intentions, then check if there is any reservation history with that number.

  • Utilize custom condition V2.0.
    • Call the API URL of the custom condition to check if there is any reservation history with that number based on the phone number saved in the built-in user variable *{cicRequest.session.callInfo.caller}
    • Design the API to respond to noReservation using valid if there is no reservation history, and to reserved if there is a reservation history

• If there is a reservation history with the phone number, set the answer as below.
  

• If there is no reservation history with the phone number, set the answer as below.
  

• Enter reservation information

• Design to create date, time, number of people, and phone number entities to receive reservation information.

• Collect the information through the task and save the collected raw reservation information in the user variable current step.

• Check validity of reservation information

  • Among the variables in the Current step, transfer the information of the item whose validity is checked to the Checked step.

  • Check the validity of following items.

    • Invalid date and time format: Check non-existent date and time format such as 99/32/2020, 00:99
    • Reservation available date: Check if it is a previous date/time, or during a business day/business hours
    • Full booked: Check if it is booked at that time
    • Reservation available number of people: Check if the number of people exceeds 10
    • You can also add items for validity checks according to reservation policies

  • Check the validity by utilizing custom condition V2.0.

    • Check items defined above, based on the information saved in the user variables reserved date_current, reserved time_current, and reserved number of people_current

    • Design the API to respond to pass with valid if the validity is checked

      

    • In addition, inherit the information from reserved date__current, reserved time_current, and reserved number of people_current to reserved date_checked, reserved time_checked, and reserved number of people_checked if the validity is checked

    • Design the API to respond to unavailableDate (invalid date format), unavailableTime (invalid time format), fullBooking (full booked at that date/time), and groupReservaion (group reservation) using valid if it's invalid

      

      

• Recheck the insufficient reservation information

• If there is any information that has not been received from among the reserved date, reserved time, and reserved number of people, then prompt the user to enter that information once again.
  • If the information of reserved date is required
    
  • If the information of reserved time is required
    
  • If the information of reserved number of people is required
    
  • Check if the information is stored in reserved date_checked, reserved time_checked, and reserved number of people_checked. Respond to the spoken content that prompts the user to provide information if there is no saved information. Then, connect the context to the reservation information input conversation
    
• Once the validity check of all information is completed, go to the conversation regarding final confirmation on reservations.
  

• Final check on reservation

• Once all the information is collected, you need to get confirmation from the user if it is okay to reserve with the collected information.
  

• If the user wants to edit the reservation information, then connect the user to the reservation information input conversation again.
  

  

• Once you get the user's final confirmation, inherit the information from reserved date_checked, reserved time_checked, and reserved number of people_checked to reserved date_completed, reserved time_completed, and reserved number of people_completed, and check the phone number to reserve.

  

• Check phone number

• Get confirmation from the user whether to reserve with the phone number the customer is currently using or to reserve with a different number.

  

• If you reserve with the current number, then inherit the user's phone number information saved in the built-in user variable *{cicRequest.session.callInfo.caller} to the phone number_completed.
  

• Get a new number if the user wants to reserve with a different number.
  

  • Switch to keypad input mode

  • Set to enter 12 digits to receive all 11 to 12 digits of the phone number

    • If the phone number is less than 12 digits in length, the keypad input mode ends when the user enters the phone number and enters the # button
    • If the phone number is 12 digits in length, the mode automatically ends when the user enters the keypad when entering 12-digit phone number

  • Set the No response messages and Failure messages when switching to the keypad input mode separately from the common Repair scenarios.
    You need to set follow-up operations with keypad input mode like above
    

  • For the newly received phone number information, save the @{phone number} value in the phone number_current and get the user's final confirmation
    

  • Once you get the final confirmation of the phone number, inherit the value stored in the phone number_checked to the phone number_completed
    

• Final handling of reservation

• Once the phone number is checked, please finalize the reservation by utilizing the custom condition V2.0.
  • Utilize the information saved in the user variables reserved date_completed, reserved time_completed, reserved number of people_completed, and phone number_completed when handling the reservation
  • Design the API to respond to the reservationCompleted with valid if the reservation is completed normally
    
  • Design the API to respond to the reservationFailed with valid if the reservation is not completed normally
    
  • Once the reservation is completed, initialize all values saved in the reserved date_current, reserved time_current, reserved number of people_current, phone number_current, reserved date_checked, reserved time_checked, and reserved number of people_checked
    

ⅱ. Global scenario

Enter global as input context of Global scenarios. Enter global in the output context of the Main scenarios and Repair scenarios so that it can be connected to the Global scenarios at any time when the Main scenarios proceed.

• FAQ

• Create conversations about separate inquiries such as business hours, parking lot availability, menu and product description, and whether there is a baby chair.
• After completing the answer, enter the built-in action method ${`previousChatbotAnswerContext} to update it as the context of the previous Main scenarios while speaking the previous answer again.
  

• Request to connect agent

• Connect to the agent's number if a request is made within operating hours.
  
• If a request is made outside of operating hours, then notify that the agent can't be connected and finish the call.
  

• Finish call

• Respond with the instruction messages to finish the call.
  

ⅲ. Design Repair scenario

Enter silence1 and undefined1 as input context of Repair scenarios. Enter silence1 and undefined1 in the output context of the Main scenarios so that it can be connected to the Global scenarios at any time when the Repair scenarios proceed.

• No response from user

• Design the chatbot so it speaks and provides the answer of the previous Main scenarios again up to two consecutive times.
• Design to finish the call if the customer does not respond three consecutive times.
• Create three messages with no response.

  • No response message 1
    

    

    • Enter silence1 as input context
    • Set to delete silence1, add silence2, and maintain all context as output context
    • Enter silence1 as output context for all Main scenarios to connect to No response message 1 at any time
    • Design to respond to the previous spoken content of previous Main scenarios by entering ${`previousChatbotAnswer}, a built-in action method, and answers that prompt users to speak
    • However, for No response message 1, design to deactivate the marker so that you prevent the system from speaking the spoken content again (a repair scenario is used instead)

  • No response message 2
    

    

    • Enter silence2 as input context
    • Set to delete silence2, add silence3, and maintain all context as output context
    • Design to respond to the previous spoken content of previous Main scenarios by entering ${`previousChatbotAnswer}, a built-in action method, and answers that prompt users to speak
    • However, for No response message 2, design to deactivate the marker so that you prevent the system from speaking the spoken content again (a repair scenario is used instead)

  • No response message 3
    

    

    • Enter silence3 as input context
    • Finish the call by responding with answers that no guidance can be provided

• User's utterance with unclear intention

• Design the chatbot so it speaks and provides the answer of the previous Main scenarios again up to two consecutive times.
• If the spoken content with unclear intentions is made three consecutive times, connect to agents only during operating hours, and finish calls outside of operating hours.
• Create three failed messages.

  • Failure message 1
    

    

    • Enter undefined1 as input context
    • Set to delete undefined1, add undefined2, and maintain all context as output context
    • Enter undefined1 as output context for all Main scenarios to connect to Failure message 1 at any time
    • Design to respond to the previous spoken content of previous Main scenarios by entering ${`previousChatbotAnswer}, a built-in action method, and answers that prompt users to speak
    • However, for Failure message 1, design to deactivate the marker so that you prevent the system from speaking the spoken content again to repair

  • Failure message 2
    

    

    • Enter undefined2 as input context
    • Set to delete undefined2, add undefined3, and maintain all context as output context
    • Design to respond to the previous spoken content of previous Main scenarios by entering ${`previousChatbotAnswer}, a built-in action method, and answers that prompt users to speak
    • However, for Failure message 2, design to deactivate the marker so that you prevent the system from speaking the spoken content again to repair

  • Failure message 3
    

    

    • Enter undefined3 as input context
    • Finish the call by responding with answers that no guidance can be provided

2. Enter scenarios in AiCall builder

You can create voice bots more quickly if you enter what you designed in the following order into the builder.

ⅰ. Set domain

• You can create voice bots in AiCall domains. Check the service type.
• The flow of conversation is important for voice bots. So it is recommended that the strength setting of the context be changed to hard to limit the connection strength of the conversation to hard.
• Activate the temporary storage setting for conversation logs to log the chatbot's spoken content in real time and utilize the information of the conversation previously responded. You can use a built-in action method, ${`previousChatbotAnswer}, after the activation.

ⅱ. Create entity

• Create the reserved date, reserved time, and reserved number of people entities to utilize in reservation voice bots.

ⅲ. Create user variable

• Create the user variables reserved date, reserved time, and reserved number of people, to utilize in reservation voice bots.
• Create for each step and enter null as a default value.

ⅳ. Create action method

• If the scenarios require action methods, create them before creating the conversation.

ⅴ. Create conversation type

• It is a feature to manage lots of conversations easily.
• Create easy-to-manage tags such as Main scenarios and Global scenarios.

ⅵ. Create common message

• Enter Welcome messages, Failure messages, and No response messages as designed.

ⅶ. Create conversation

• Create conversations by entering conversation names, and tag the conversation types first.
• It is easier and faster to build it by creating conversations as designed, then filling in the elements of the conversation one by one, rather than creating conversations and entering all questions and answers at once.

ⅷ. Enter answer for conversation

• Enter chatbot's answers.

ⅸ. Connect conversation flow

• Connect the flow between conversations and common messages through context.
• It is easier and faster to set the context of the common message first, then set the context of the conversation when setting the context.

ⅹ. Enter question for conversation

• It is recommended to collect spoken content expected from the user and batch-upload them as an Excel file.