먼저, AI가 중단해야 하는 조건을 정의합니다.
사용자는 다음과 같은 경우를 처리할 수 있는 조건으로 명확하게 요청합니다. 즉, 실제 사람과의 대화, 지속적인 오해, 필수 정보 확인 불가, 자금 흐름 또는 권리 관련 문제, 고위험 관련 키워드, 기업 API에서 처리 불가능 상태 반환, 모델 또는 전화 서비스 오류 등이 발생한 경우입니다. 이러한 조건은 단순히 모델에 따라 자유롭게 판단하는 것이 아니라, 기록 가능한 원인 코드로 명확하게 정의되어야 합니다. 이를 통해 고객센터는 왜 전화가 연결되었는지, 운영팀은 프로세스 설계 또는 모델 품질 문제인지 파악할 수 있습니다.
수동 트리거 및 예상 처리| 발생 원인 | AI가 해야 할 일 | 인간이 인지한 주요 사항 |
|---|
| 사용자가 직접 참여하도록 요청 | 즉시 확인하고 적절한 대기열에 입장 | 목적 확인 완료 및 대기 상태 |
| 반복적인 오해 또는 낮은 자신감 | 추측을 멈추고, 전환에 대한 설명을 제공해주세요. | 원래 문제, 실패 항목, 재 질문 횟수 |
| 민감하거나 위험한 사항 | 역행 불가능한 작업 수행 금지 | 위험 분류 및 관련 사건 자료 |
| 기업 시스템 오류 | 성공을 선언하지 않고, 처리해야 할 상태로 남겨둠. | API 상태, 요청 식별 및 재시도 가능 여부 |
| 인공적으로 마련된 좌석은 사용할 수 없습니다. | 대기, 전화, 또는 작업 목록 생성 기능 제공 | 연락 방법, 시간 및 추적 정보 |
계획된 전환 및 비정상적인 급격한 증가는 별도로 측정해야 합니다.
계획된 전환은 원래 사람이 수행하도록 설계된 프로세스입니다. 예를 들어, AI가 먼저 데이터를 수집한 후 특정 담당자에게 전달하는 방식입니다. 비정상적인 전환은 AI가 이해하지 못하거나, 시스템 오류 또는 사용자의 불만으로 인해 발생합니다. 이 두 가지를 혼합하면 팀이 모든 전환이 자동화 실패라고 오해하게 될 수 있으며, 실제 오해의 원인을 가릴 수도 있습니다. Google Cloud의 가상 고객 지원 지표 또한 planned transfer, escalation, resolved, abandoned 등의 항목으로 구분합니다.
PBX, SIP, 그리고 고객 지원 대기열이 실제 전화 라우팅을 담당합니다.
AI 애플리케이션은 전환 목표와 이유를 제시할 수 있지만, 대표 번호, 분기 번호, 기술 그룹, 영업 시간, 대기, 오버플로우 및 녹음 연장은 일반적으로 PBX, SIP 플랫폼 또는 콜센터에서 처리합니다. 도입 전에 맹전환, 상담 전환, 기존 번호 유지, 시스템 간 통화 식별 및 전환 실패 등의 사항을 확인해야 합니다. "SIP 지원"만으로는 기존 전화 환경이 모든 경로를 처리할 수 있다는 것을 증명하기에 충분하지 않습니다.
상황에 따라 필요한 정보만 전달
인공 지능 시스템은 최소한 다음과 같은 정보를 알아야 합니다: 통화 목적, 확인된 항목, 해결되지 않은 문제, 기업 시스템 조회 결과, 수행된 작업 및 실패 원인. 원본 녹음, 완전한 텍스트, 또는 민감한 정보가 표시되는 경우, 역할과 목적에 따라 결정해야 합니다. 필요한 정보만 제공하고 불필요한 정보는 숨겨야 합니다. 또한, 시스템 화면에는 사용자가 확인해야 하는 값과 모델 예측 값 등을 명확하게 표시해야 합니다.
제안하는 최소 정보 전달 내용| 자료 | 용도 | 제어 방식 |
|---|
| 연결 이유 코드 | 우선순위 결정 및 다음 단계 | 고정된 분류 체계를 사용하여 모델이 임의의 권한 명령을 출력하지 않도록 합니다. |
| 확인된 항목 | 사용자가 동일한 답변을 반복하도록 방지 | 인용 확인 시간 및 출처 |
| 해결되지 않은 문제 | 인공지능이 직접 대화를 이어가도록 합니다. | 모델 요약과 별도로 제시 |
| 시스템 상태 | 중복 쿼리 또는 주문 생성 방지 | 단일 요청 식별 및 최종 상태 |
| 안전 요약 | 핵심 내용을 빠르게 파악 | 개인 정보 보호를 위해 특정 정보에 대한 접근을 제한하고, 원본 데이터의 접근을 제한합니다. |
인공적인 완결, 연결 실패, 또는 단선 발생 시에는 반드시 다음 단계를 수행해야 합니다.
좌석이 매진된 경우, 사용자는 대기, 특정 시간대에 다시 전화하거나 작업 요청을 생성할 수 있습니다. 또한, API 연결 실패 시에는 원래 통화를 유지하고 백업 큐로 다시 시도하거나, 후속 조치를 명확하게 설명해야 합니다. 통화 연결이 끊어진 후에는 통화 목적, 번호 사용, 기업 정책 등을 확인한 후 다시 연결을 시도해야 합니다. 각 경로에서 오류 발생 시, 해당 작업에 대한 식별 번호와 사용자에게 보이는 상태를 명확하게 표시해야 하며, 오류 로그에 기록하여 사용자가 직접 다시 입력하도록 하는 것은 피해야 합니다.
인간의 개입이 성공적인 결과를 가져오는 이유는 원인과 결과 모두를 함께 고려해야 합니다.
전환율은 얼마나 많은 사용자가 시스템으로 연결되는지 보여줄 뿐이며, 단독으로 시스템의 품질을 판단할 수 없습니다. 전환율은 계획된 전환, 비정상적인 상승, 잘못된 분류, 대기 중단, 최초 해결, 총 처리 시간 및 사용자가 반복적으로 설명하는 비율과 함께 고려해야 합니다. 만약 특정 의도가 많은 계획된 전환을 나타낸다면, 이는 프로세스 설계가 정확함을 의미합니다. 반대로 특정 필드가 반복적으로 비정상적인 상승을 일으킨다면, 이는 대화, 데이터 또는 모델을 수정해야 함을 의미합니다.
GoGoCha는 공식적으로 완전한 콜센터 연결 기능을 제공한다는 증거를 제시하지 않고 있습니다.
GoGoCha에서 공개하는 정보는 전화 연결, 공동 주문 후 관리 시스템, 실시간 알림, 웹사이트, LINE, 앱 및 운영 인터페이스 통합 등을 증명합니다. 하지만 PBX 모델, 고객 지원 큐, 통화 연결 전략 또는 연결 SLA에 대한 정보는 공개하지 않습니다. Falcon은 이러한 정보는 기업 환경에 맞게 커스터마이징하고 POC(Proof of Concept)를 통해 검증할 수 있는 범위 내에서만 제공하며, GoGoCha에서 검증된 완전한 고객 지원 솔루션으로 제공할 수 없습니다.
