IVR(대화형 음성 응답) 브랜치를 대화형 AI로 전환하기: 라우팅, 액션 및 폴백

원래 AntEngage에서 작성한 Fonix.AI 실용 가이드입니다. 이 재게시는 동일한 가이드 콘텐츠를 사용합니다.

Concept illustration of a lavender route through an ivory maze to an open exit, with a keypad providing an alternative call path.

대화가 필요한 통화 선택하기

대화형 AI IVR은 발신자가 자연어로 요청을 설명할 수 있게 하며, 이 요청을 사용하여 경로를 선택하거나 허용된 작업을 완료합니다. 전통적인 IVR은 일반적으로 정의된 프롬프트, 키패드 선택 또는 제한된 음성 옵션을 사용합니다. 실질적인 선택은 어떤 접근 방식이 특정 통화 경로에 도움이 되는지, 그리고 실패했을 때 발신자가 어떻게 계속할 수 있는지입니다.

짧고 익숙한 메뉴는 소수의 안정적인 목적지에 효과적일 수 있습니다. 대화가 유용해지는 경우는 발신자가 카테고리를 선택하는 데 어려움을 겪거나, 언어 전환이 필요하거나, 비즈니스 시스템을 통해 작업을 완료하길 원할 때입니다. 어느 접근 방식도 검증, 최신 정보 및 작동하는 사람의 경로가 필요하다는 필요성을 제거하지는 않습니다.

Fonix.AI는 비즈니스 워크플로우를 위한 음성 대화를 제공합니다. 문제가 되는 IVR 브랜치 하나를 평가 범위로 사용하십시오. 모든 전화 통신 기능이 모든 배포에서 사용할 수 있다고 가정하기보다는, 제안된 설정에 대한 라우팅, 전송(transfer), 키패드 지원 및 모든 비즈니스 도구 연결을 확인하십시오.

통화 트리 대체 전에 브랜치 감사하기

진입부터 결과까지 현재 경로를 그리십시오. 각 프롬프트, 언어 선택, 목적지, 전송 및 실패 경로를 기록합니다. 사용 가능한 통화 기록을 사용하여 반복되는 메뉴 선택, 포기(abandonment), 오경로 지정(misroutes) 및 팀 간의 전송을 식별하십시오.

주문 상태와 같이 명확한 목적지를 가진 브랜치를 선택하십시오. 누가 여기에 도달해야 하는지, 어떤 정보가 필요한지, 그리고 성공적인 완료가 무엇을 의미하는지 정의하십시오. 관련 없는 청구 및 계정 변경 요청은 승인된 경로를 통해 라우팅되도록 유지하십시오.

분기별 기준선(baseline)을 작성해야 합니다: 적격 통화 건수, 완료된 작업 건수, 이관 건수, 미해결 통화 건수 및 정의된 기간 내 반복 접촉 횟수를 측정합니다. 고객이 다시 전화해야 하는 경우, 통화 시간이 짧다고 해서 자동으로 더 좋다고 할 수 없습니다.

직원들에게 발신자가 이슈에 대해 어떤 단어를 사용하는지 물어보십시오. “처리(fulfilment)”라고 라벨링된 메뉴가 “제 소포가 도착하지 않았습니다”라는 설명의 전화를 받을 수 있습니다. 이러한 어휘 격차는 대화가 더 현대적으로 들린다는 이유로 단순히 메뉴를 교체하는 것보다 의도 기반 라우팅(intent-based routing)을 평가해야 할 구체적인 이유가 됩니다.

레이블보다는 작업 행동 비교

대화형 입력(conversational input)을 무제한 행동 권한(unrestricted action permissions)과 혼동해서는 안 됩니다. “주문 취소”라는 것을 이해한다고 해서 발신자의 권한, 주문 적격성 또는 취소가 성공했는지 여부가 확립되는 것은 아닙니다. 두 아키텍처 모두 이러한 확인 절차가 필요합니다.

Side-by-side call routing comparison shows keypad menu selection and natural-language intent clarification both leading to a verified task or staffed route, with a known fallback available on failure.

그림 01. 확인(Verification) → 조회(lookup) → 허가된 행동(permitted action) → 확정된 결과(confirmed result).

의도-행동 계약 설계 (Design an intent-to-action contract)

지원되는 요청과 그에 따른 허용 가능한 결과를 정의합니다. 발신자가 파일럿 범위 밖의 무언가를 요청할 수 있습니다. 시스템은 이러한 경계를 인식하고, 지원되는 작업을 억지로 끼워 맞추기보다는 적절한 경로를 사용해야 합니다.

주문 상태(order-status) 분기의 경우, 계약은 다음과 같을 수 있습니다: 요청 식별 → 승인된 프로세스를 통한 접근 권한 확립 → 현재 상태 읽기 → 지원되는 다음 단계 설명 및 필요 시 에스컬레이션 제공. 취소는 별도의 직원 검토 경로로 남겨둘 수 있습니다.

원본 요청 및 핸드오프 기록의 모든 명확화 내용을 보존해야 합니다. 유용한 라우팅 결과에는 의도(intent), 허용되는 경우 인증된 계정 또는 케이스 참조 번호, 조회 결과(lookup result), 액션 결과(action result) 및 수신 목적지(receiving destination)가 포함됩니다. 이는 주장하는 Fonix API 스키마가 아닌 제안된 설계 필드입니다.

발신자의 정정을 사용하여 대화 상태를 업데이트합니다. 만약 “배송 상태를 알고 싶어요”라는 요청이 “사실은 소포가 파손되어 도착했어요”로 바뀐다면, 시스템은 이전의 조회 흐름을 계속하는 대신 경로를 재평가해야 합니다. 계정 세부 정보를 노출하거나 액션을 취하기 전에 현재 요청 사항을 명확히 하십시오.

작동하는 브랜치: 요청에서 경로까지

이 예시 호출은 가상의 매장을 사용합니다. 계정 인증 과정이 승인된 절차이며 배송 조회는 제안되는 배포의 일부라고 가정합니다.

어시스턴트: Willow Store 자동화 어시스턴트에 오신 것을 환영합니다. 어떤 도움이 필요하신지 말씀해 주세요. 담당자를 요청하실 수도 있습니다.

발신자: 주문 상태가 궁금해요. 실제로는 배송 완료로 나오는데, 소포를 못 받았어요.

어시스턴트: 주문은 배송 완료로 표시되지만, 고객님께서 받지 못한 상황이군요. 단순히 상태를 읽는 것보다는 저희의 인증 절차를 거쳐 배송 문제로 경로를 지정하겠습니다.

중요한 구분점은 요청된 작업입니다. 이 발신자에게 “배송 완료”라고 다시 읽어주는 것은 문제를 해결하지 못합니다. 워크플로우에는 관련 배송 지원 경로와 분쟁 중인 상태(disputed-status)에 대한 문맥이 필요합니다.

모든 인증 및 조회 후, 확인된 티켓 또는 수락된 전송(transfer)이 최종 메시지를 결정해야 합니다. 만약 전송이 실패한다면, 발신자는 무기한 대기 상태보다는 구성된 대체 경로를 받아야 합니다.

실패 시에도 알려진 경로 유지하기

명확화 한계점과 발신자가 폴백(fallback)을 받는 지점을 정의하십시오. 폴백은 사용 중인 전화 시스템 설정과 비즈니스가 운영할 수 있는 범위에 따라 메뉴, 인력 대기열 또는 콜백 프로세스일 수 있습니다.

키패드 입력과 기존 IVR 공존에 대해 구체적으로 질문하세요. 이들을 가정하기보다는 시연할 설정 요구사항으로 다루세요. 음성 에이전트를 추가한다고 해서 현재의 모든 메뉴 기능이 자동으로 유지된다고 가정해서는 안 됩니다.

롤백 경로가 있는 하나의 브랜치 마이그레이션 (Migrate one branch with a rollback path)

파일럿 기간 동안 기존 브랜치로 돌아갈 문서화된 경로를 유지하세요. 어떤 통화가 적격 호출(eligible calls)로 선택되는지, 어떤 언어가 포함되는지, 그리고 파일럿이 언제 실행될지에 대해 합의하세요. 두 가지 경로를 비교한다면, 유사한 통화 그룹을 사용하고 결과에 영향을 줄 수 있는 라우팅 변경 사항을 기록하세요.

실제 트래픽 전에 스크립트화된 성공 및 실패 테스트를 실행하세요. 그런 다음 지원 직원과 함께 적절하게 처리된 실제 결과 샘플을 검토하세요. 잘못 분류된 요청, 반복적인 인증(verification), 부정확한 조회(lookups), 누락된 티켓, 그리고 맥락 없이 전송된 경우를 찾아보세요.

첫 번째 브랜치가 합의된 작업 및 운영 기준을 충족한 후에만 확장하세요. 모든 의도(intent)를 한 번에 추가하는 것은 실패가 언어 이해, 경로 정의, 권한 또는 소스 시스템 통합 중 어디에서 발생하는지 식별하기 어렵게 만듭니다.

IVR migration pilot review starts with one eligible branch, compares correct routes, completed tasks, accepted handoffs and repeat contacts, then decides whether to improve, roll back or expand.

그림 02. 먼저 수용 기준을 설정하세요. 속도만으로는 해결책이 아닙니다.

발신자가 유용한 마무리에 도달했는지 측정 (Measure whether callers reached a useful finish)

적격 호출 대비 완료된 작업, 올바른 경로, 승인된 핸드오프(handoff), 포기 및 동일 문제에 대한 반복 연락을 비교하세요. 속도를 유일한 결과로 취급하기보다는 이러한 측정치와 함께 처리 시간을 검토하세요.

이슈별, 언어별, 시간대별로 세분화하여 분석해야 합니다. 전체적인 개선 수치만으로는 심야 시간대의 경로 문제나 지원되지 않는 언어를 간과할 수 있습니다. '해결됨(resolved)'이라는 것이 실제로 검증된 답변이나 완료된 액션을 의미하는지 확인하기 위해 기본 기록 샘플을 검토하십시오.

고객 지원 음성 봇 가이드에서는 신뢰할 수 있는 조회(lookups)와 에스컬레이션에 대해 더 깊이 다룹니다. 통화 소프트웨어 가이드는 광범위한 통합 및 구매 결정 사항을 다룹니다.

IVR 브랜치 검토 요청하기. 현재의 통화 트리, 기준 결과(baseline outcomes), 언어 혼합 비율, 그리고 폴백 요구 사항을 제공하여 데모가 구체적인 마이그레이션 질문에 답할 수 있도록 하십시오.