CLOVA AiCall 시나리오 작성 가이드

Classic/VPC 환경에서 이용 가능합니다.

시나리오 구축 전 고려 사항

시나리오를 구축하기 전에 어떤 서비스를 제공할 것인지, 어떤 정책을 취할 것인지, API를 통해 어떤 정보를 주고 받을 것인지 등 세부적인 서비스를 설계한 후 시나리오를 구축해 주십시오. 시나리오는 아래와 같이 크게 3가지로 나누어 볼 수 있습니다.

• Main 시나리오
• Global 시나리오
• Repair 시나리오

각 시나리오의 용도에 따라 서비스를 설계한 후 음성 봇 시나리오 예제를 참고하여 Aicall 시나리오를 구축해 주십시오.

Main 시나리오

Main 시나리오에서는 중점적으로 처리할 서비스가 무엇인지 정의한 후 해당 서비스를 제공하기 위한 프로세스를 설계합니다.

1. 중점적으로 처리할 서비스가 무엇인지 정의해 주십시오.

   • 예약 서비스를 처리해 주는 음성 봇일 수도 있고, 단순 FAQ를 응답하는 서비스일 수도 있습니다. 또는 단순히 특정 내용을 고지하기 위한 음성 봇을 설계할 수도 있습니다.

2. 서비스를 처리하기 위해서 어떠한 단계가 필요한지 서비스 프로세스를 정의해 주십시오.

   • 예를 들어 예약 서비스를 처리하기 위해서는 예약 정보를 입력 받고, 부족한 정보를 계속해서 확인한 후 수집된 정보가 맞는지 최종으로 확인한 후에 예약을 처리하게 됩니다.

   • 그리고 단계별로 어떤 정보를 수집하고 어떤 답변을 하며, 어떤 정보들을 API를 통해 예약 시스템으로 전달할 것인지 상세히 정의합니다.

3. 각 프로세스별 상세 정책을 정의해 주십시오.

   • 예를 들어 단체 예약을 몇 명까지 음성 봇을 통해 받을 것인지 부터, 한 호에 몇 개의 예약까지 허용할 것인지 등 상세한 정책을 정의합니다.

Global 시나리오

Global 시나리오는 Main 시나리오처럼 중점적으로 처리하는 서비스는 아니지만 자주 들어올 수 있는 문의 및 요청을 정의합니다. Main 시나리오를 진행하는 중에 Global 시나리오로 진입하거나 다시 원래의 시나리오로 복귀하는 상황이 빈번하게 발생합니다.
예를 들어 운영 시간, 주차장과 같은 FAQ부터 상담원 연결 요청, 통화 종료 요청 등이 있습니다.

Repair 시나리오

Repair 시나리오는 Main 시나리오에서 벗어났을 때 다시 Main 시나리오의 흐름으로 돌려보내어 서비스의 주요 목적을 달성할 수 있도록 보수해 주는 시나리오를 말합니다. 예를 들어 사용자가 응답하지 않거나, 사용자의 의도가 불명확한 응답을 한 경우 또는 시스템에게 재발화를 요청하는 경우 등이 해당합니다.
서비스 방향에 맞는 Repair 시나리오의 정책을 수립해 주십시오.

AiCall 음성 봇 시나리오 예제

CLOVA AiCall 음성 봇 시나리오를 설정하는 일반적인 절차는 다음과 같습니다. 해당 절차에 따라 음성 봇 시나리오를 설정하는 방법을 예시를 통해 설명합니다.

1. 서비스 목적 및 정책 정의
2. 시나리오 설계
   1. Main 시나리오 설계
   2. Global 시나리오 설계
   3. Repair 시나리오 설계
3. AiCall 빌더에 시나리오 입력

1. 서비스 목적 및 정책 정의

음성 봇 시나리오를 통해 제공할 서비스의 목적과 정책을 아래와 같이 정의합니다.

• 서비스 목적 : 식당 예약 서비스
• 예약 정책
  • Main 시나리오
    • 신규 예약만 처리. 예약 확인/변경/취소는 상담원 통해 진행
    • 하나의 전화번호당 한 개의 예약만 허용
    • 단체 예약은 10명 이내로만 가능하며, 그 이상의 인원수는 점포로 연결하여 상담원 통해 진행
    • 예약 원하는 시간이 이미 풀 부킹인 경우 다른 시간대의 예약 요청
    • 예약은 당일로부터 2주 뒤의 날까지만 가능
    • 영업 시간이 아닌 경우 상담원에게로 연결하지 않고 통화 종료 처리
  • Global 시나리오
    • 통화 종료, 상담원 연결 요청, 주차장 문의, 영업 시간 문의 등에 대응
    • FAQ 문의 시 답변 응답 후 마커가 설정된 이전 시스템의 답변을 응답하며 해당 위치로 복귀 처리
  • Repair 시나리오
    • 무응답 5초 발생하는 경우 무응답 메시지 응답
    • 무응답 이벤트/의도불분명 발화가 연속 3회 발생하는 경우 Repair 하지 않고 통화 종료

2. 시나리오 설계

서비스 정책에 따라 각 시나리오를 설계합니다.

Main 시나리오 설계

예약 정보의 저장과 사용자 변수의 단계 설정

• 예약 정보는 해당 세션(해당 콜)에 저장해두고, 시나리오를 진행할 때마다 반복해서 사용합니다.

• 따라서 사용자 변수라는 개념을 활용하여 예약 정보를 저장해둡니다.

• 예약을 일련의 단계별로 처리하기 위해 사용자 변수 사이에서의 단계를 아래와 같이 설정합니다.

  

  • current 단계: 사용자가 발화한 날것 그대로 상태의 정보 저장
    예약날짜_current, 예약시간_current, 예약인원_current, 전화번호_current
  • checked 단계 : 유효성 체크가 완료된 상태의 정보 저장
    예약날짜_checked, 예약시간_checked, 예약인원_checked
  • completed 단계 : 실제로 예약 처리된 상태의 정보 저장
    예약날짜_completed, 예약시간_completed, 예약인원_completed, 전화번호_completed
  • 이 외에도 대응하고자 하는 시나리오의 세부 내용에 따라 단계 추가 또는 간소화 가능

예약 프로세스 설계

• 예약 의도 파악 → 예약 정보 입력 → 예약 정보 유효성 체크 → 부족한 예약 정보 재확인 → 예약 최종 확인 → 전화번호 확인→ 예약 처리 순서로 예약을 진행할 수 있도록 컨텍스트를 연결합니다.
• Main 시나리오의 답변 중 사용자의 발화를 유도하는 답변 말풍선에는 재발화 마커를 활성화시켜 Main 시나리오를 이탈했을 때 다시 마커가 설정된 원래 위치로 돌아올 수 있습니다.
  • 예를 들어 아래와 같이 주요 발화에만 마커를 활성화시키면, Main 시나리오 이탈 시 Repair 시나리오에서 ${`previousChatbotAnswer} 호출 시 마커를 활성화시켰던 메시지(다른 날을 말씀해 주시겠어요?)만 다시 재발화 됩니다.
    

예약 의도 파악

• 예약 의도가 파악되는 경우 해당 번호로 예약된 내역이 있는지 확인합니다.
  • 커스텀 조건 V2.0을 활용합니다.
    • 커스텀 조건의 API URL을 호출하여 빌트인 사용자 변수 *{cicRequest.session.callInfo.caller}에 저장된 전화번호를 토대로 해당 번호로 예약된 내역이 있는지 확인
    • 예약 내역이 없는 경우 valid로 noReservation를, 예약 내역이 있는 경우 reserved를 응답해 주도록 API를 설계
• 전화건 번호로 예약 내역이 있는 경우의 답변은 아래와 같이 설정합니다.
  
• 전화건 번호로 예약 내역이 없는 경우의 답변은 아래와 같이 설정합니다.
  

예약 정보 입력

• 날짜, 시간, 인원, 전화번호 엔티티를 생성하여 예약 정보를 받을 수 있도록 설계해 주십시오.

• 태스크를 통해 해당 정보를 수집하고, 수집된 날것 그대로의 예약 정보를 사용자 변수 current 단계에 저장합니다.

• 예약 정보 유효성 체크

  • current 단계의 변수 중 예약 정보의 유효성이 체크된 항목은 checked 단계로 정보를 옮겨줍니다.

  • 유효성을 체크할 항목은 다음과 같습니다.

    • 유효하지 않은 날짜, 시간 형식: 2020년 99월 32일, 0시 99분과 같이 존재하지 않는 날짜, 시간 형식 확인
    • 예약 가능일: 이전 날짜/시간이거나, 영업일/영업시간 여부 확인
    • 풀 부킹 여부: 해당 시간에 이미 예약이 차 있는지 확인
    • 예약 가능 인원 수: 10명을 초과하는 인원인지 확인
    • 이 외에도 예약 정책에 따라 유효성 체크 항목 추가 가능

  • 커스텀 조건 V2.0을 활용하여 유효성을 확인합니다.

    • 사용자 변수 예약날짜_current, 예약시간_current, 예약인원_current에 저장된 정보를 토대로 위에서 정의한 항목 확인

    • 유효성이 적합한 경우 valid로 pass를 응답하도록 API 설계

      

    • 또한 유효성이 적합한 경우 예약날짜_current, 예약시간_current, 예약인원_current에서 예약날짜_checked, 예약시간_checked, 예약인원_checked로 정보 상속

    • 유효성이 적합하지 않은 경우 valid로 unavailableDate(유효하지 않은 날짜 형식), unavailableTime(유효하지 않은 시간 형식), fullBooking(해당 날짜/시간에 풀 부킹), groupReservaion(단체 예약)등을 응답하도록 API 설계

      

      

부족한 예약 정보 재확인

• 예약 날짜, 예약 시간, 예약 인원 중 받지 못한 정보가 있다면 다시 한번 정보 입력을 유도합니다.
  • 예약 날짜 정보가 필요한 경우
    
  • 예약 시간 정보가 필요한 경우
    
  • 예약 인원 정보가 필요한 경우
    
  • 예약날짜_checked, 예약시간_checked, 예약인원_checked에 정보가 저장되었는지 확인하여, 저장된 정보가 없을 경우 해당 정보를 유도하는 발화를 응답하며 다시 예약 정보 입력 대화로 컨텍스트 연결
    
• 모든 정보의 유효성 체크가 완료되었다면 예약 최종 확인 대화로 이동합니다.
  

예약 최종 확인

• 모든 정보가 수집되면 수집된 정보로 예약 처리를 해도 되는지 사용자에게 확인을 받아야 합니다.
  

• 만약 사용자가 예약 정보를 수정하고자 할 경우 다시 예약 정보 입력 대화로 연결해줍니다.
  

  

• 사용자의 최종 확인이 완료되면 예약날짜_checked, 예약시간_checked, 예약인원_checked 에서 예약날짜_completed, 예약시간_completed, 예약인원_completed로 정보를 상속한 후 예약할 전화번호를 확인합니다.

  

전화번호 확인

• 현재 고객이 사용하고 있는 전화번호로 예약 처리할지, 다른 번호로 예약 처리할 것인지를 사용자에게 확인을 받습니다.

  

• 현재 번호로 예약하는 경우 빌트인 사용자 변수 *{cicRequest.session.callInfo.caller}에 저장된 사용자의 전화번호 정보를 전화번호_completed로 상속합니다.
  

• 다른 번호로 예약하고자하는 경우 새로운 전화번호를 받습니다.
  

  • 키패드 입력 모드로 전환

  • 11~12자리의 전화번호를 모두 받기 위해서 12자리를 입력받을 수 있도록 설정

    • 12자리 미만의 전화번호인 경우, 사용자가 전화번호 입력 후 # 버튼을 입력하면 키패드 입력 모드 종료
    • 12자리의 전화번호인 경우, 사용자가 전화번호 12자리 입력 시점에 키패드 입력하면 모드 자동 종료

  • 키패드 입력 모드로 전환했을 때의 무응답 메시지와 실패메시지는 공통의 Repair 시나리오와는 별개로 설정.
    위와 마찬가지로 키패드 입력 모드로 후속 동작 설정 필요
    

  • 새로 받은 전화번호 정보는 @{전화번호}값을 전화번호_current에 저장하여 사용자에게 최종 확인
    

  • 전화번호 최종확인까지 완료되면 전화번호_checked에 저장된 값을 전화번호_completed에 상속
    

예약 최종 처리

• 전화번호 확인이 완료되면 커스텀 조건 V2.0을 활용하여 예약을 최종 처리해 주십시오.
  • 예약 처리 진행 시 사용자 변수 예약날짜_completed, 예약시간_completed, 예약인원_completed, 전화번호_completed에 저장된 정보를 토대로 활용
  • 정상적으로 예약 처리가 완료되었다면 valid로 reservationCompleted을 응답하도록 API를 설계
    
  • 정상적으로 예약 처리가 완료되지 않았다면 valid로 reservationFailed을 응답하도록 API를 설계
    
  • 예약이 완료된 후 예약날짜_current, 예약시간_current, 예약인원_current, 전화번호_current, 예약날짜_checked, 예약시간_checked, 예약인원_checked에 저장된 값 모두 초기화
    

Global 시나리오

Global 시나리오의 input 컨텍스트로 global을 입력합니다. Main 시나리오와 Repair 시나리오의 Ouput 컨텍스트에도 global을 입력하여 Main 시나리오가 진행되는 중에도 언제든 Global 시나리오로 연결될 수 있도록 합니다.

FAQ

• 영업 시간, 주차장 사용 가능 여부, 메뉴 및 상품 설명, 아기 의자 구비 여부 등 개별 문의에 대한 대화를 생성합니다.
• 답변을 작성한 후 빌트인 액션메소드 ${`previousChatbotAnswerContext} 를 입력하여 이전 Main 시나리오의 컨텍스트로 업데이트하는 동시에 이전 답변을 재발화 하도록 설계합니다.
  

상담원 연결 요청

• 운영 시간 내에 요청이 들어온 경우 상담원의 번호로 연결합니다.
  

• 운영 시간 외에 요청이 들어온 경우 상담원을 연결할 수 없다고 안내하고 통화를 종료 처리합니다.
  

통화 종료

• 통화 종료 안내 메시지를 응답하며 통화를 종료합니다.
  

Repair 시나리오 설계

Repair 시나리오의 input 컨텍스트로silence1와 undefined1을 입력합니다. Main 시나리오의 Ouput 컨텍스트에 silence1와 undefined1을 입력하여 Main 시나리오가 진행되는 중에도 언제든 Repair 시나리오로 연결될 수 있도록 합니다.

사용자의 무응답

• 연속 2회까지는 직전 Main 시나리오의 챗봇 답변을 재발화하도록 설계합니다.
• 연속 3회로 무응답하는 경우에는 통화 종료 처리하도록 설계합니다.
• 무응답 메시지를 3개 생성합니다.

  • 무응답 메시지1
    

    

    • Input 컨텍스트로 silence1 입력
    • Output 컨텍스트로 silence1 삭제, silence2 추가, 모든컨텍스트 유지로 설정
    • 모든 Main 시나리오의 Ouput 컨텍스트에는 silence1 을 입력하여 언제든 무응답 메시지 1로 연결
    • 사용자의 발화를 유도하는 답변과 빌트인 액션메소드 ${`previousChatbotAnswer}을 입력하여 이전 Main 시나리오의 직전 발화를 응답하도록 설계
    • 단, 무응답 메시지1은 마커를 비활성화하여, repair하기 위한 발화를 시스템이 다시 재발화하지 못하도록

  • 무응답 메시지2
    

    

    • Input 컨텍스트로 silence2 입력
    • Output 컨텍스트로 silence2 삭제, silence3 추가, 모든컨텍스트 유지로 설정
    • 사용자의 발화를 유도하는 답변과 빌트인 액션메소드 ${`previousChatbotAnswer}을 입력하여 이전 Main 시나리오의 직전 발화를 응답하도록 설계
    • 단, 무응답 메시지2는 마커를 비활성화하여, repair하기 위한 발화를 시스템이 다시 재발화하지 못하도록 방지

  • 무응답 메시지3
    

    

    • Input 컨텍스트로 silence3 입력
    • 안내할 수 없다는 답변을 응답하며 통화 종료 처리

의도 불분명한 사용자의 발화

• 연속 2회까지는 직전 Main 시나리오의 챗봇 답변을 재발화하도록 설계합니다.
• 연속 3회로 의도가 불분명한 발화를 하는 경우에는 운영 시간 내에만 상담원에게 연결하고, 운영 시간 외에는 통화를 종료 처리합니다.
• 실패 메시지를 3개 생성합니다.

  • 실패 메시지1
    

    

    • Input 컨텍스트로 undefined1 입력
    • Output 컨텍스트로 undefined1 삭제, undefined2 추가, 모든컨텍스트 유지로 설정
    • 모든 Main 시나리오의 Ouput 컨텍스트에는 undefined1을 입력하여 언제든 실패 메시지 1로 연결
    • 답변으로는 사용자의 발화를 유도하는 답변과 빌트인 액션메소드 ${`previousChatbotAnswer}을 입력하여 이전 Main 시나리오의 직전 발화를 응답하도록 설계
    • 단, 실패 메시지1은 마커를 비활성화하여, repair하기 위한 발화를 시스템이 다시 재발화하지 못하도록 방지

  • 실패 메시지2
    

    

    • Input 컨텍스트로 undefined2 입력
    • Output 컨텍스트로 undefined2 삭제, undefined3 추가, 모든컨텍스트 유지로 설정
    • 답변으로는 사용자의 발화를 유도하는 답변과 빌트인 액션메소드 ${`previousChatbotAnswer}을 입력하여 이전 Main 시나리오의 직전 발화를 응답하도록 설계
    • 단, 실패 메시지2는 마커를 비활성화하여, repair하기 위한 발화를 시스템이 다시 재발화하지 못하도록 방지

  • 실패 메시지3
    

    

    • Input 컨텍스트로 undefined3 입력
    • 안내할 수 없다는 답변을 응답하며 통화 종료 처리

2. AiCall 빌더에 시나리오 입력

아래의 순서대로 설계한 내용을 빌더에 입력하면 더욱 신속하게 음성 봇을 제작할 수 있습니다.

도메인 설정

• 음성 봇은 AiCall 도메인에서 생성할 수 있습니다. 서비스 타입을 확인해 주십시오.
• 음성 봇은 대화의 흐름이 중요합니다. 따라서 컨텍스트의 강도 설정을 hard로 변경하여 대화의 연결 강도를 hard하게 제한하는 것을 권장드립니다.
• 챗봇의 발화를 실시간으로 로깅하여 직전에 응답한 대화의 정보를 활용하기 위해서는 대화 로그 임시 저장 설정을 활성화합니다. 활성화 후에는 빌트인 액션 메소드 ${`previousChatbotAnswer} 를 사용할 수 있습니다.

엔티티 생성

• 예약 음성 봇에서 활용할 예약 날짜, 예약 시간, 예약 인원 엔티티를 생성해 주십시오.

사용자 변수 생성

• 예약 음성 봇에서 활용할 예약날짜, 예약시간, 예약인원 정보를 저장할 사용자 변수를 생성해 주십시오.
• 각각 단계별로 생성하며, 기본값으로는 null을 입력해 주십시오.

액션 메소드 생성

• 만약 액션메소드를 사용해야하는 시나리오일 경우 대화를 생성하기 전에 생성해 주십시오.

대화 유형 생성

• 많은 대화를 용이하게 관리하기 위한 기능입니다.
• Main 시나리오, Global 시나리오 등 관리하기 편한 태그를 생성해 주십시오.

공통 메시지 생성

• 설계한 대로 웰컴 메시지, 실패 메시지, 무응답 메시지를 입력해 주십시오.

대화 생성

• 대화 이름을 입력하여 대화를 생성하고 대화 유형을 먼저 태깅해 주십시오.
• 대화를 생성하고 질문 답변을 모두 한번에 입력하는 것보다, 설계대로 대화만 생성한 후 차례대로 대화의 요소들을 채워나가는 방식으로 구축하는 것이 더 쉽고 빠릅니다.

대화의 답변 입력

• 챗봇의 답변을 입력해 주십시오.

대화 흐름 연결

• 컨텍스트를 통해서 대화들과 공통 메시지간의 흐름을 연결해 주십시오.
• 컨텍스트 설정 시 공통 메시지의 컨텍스트를 먼저 설정한 후에 대화의 컨텍스트를 설정하는 순서로 작업하는 것이 더 쉽고 빠릅니다.

대화의 질문 입력

• 사용자 예상 발화를 수집한 후 엑셀로 일괄 업로드하는 방식을 추천합니다.