AI 챗봇이 고객 서비스에서 실패하는 이유와 실제로 작동하는 방식

대부분의 고객 서비스 챗봇은 단순한 이유로 실패합니다. 바로 서비스 도구가 아닌, 고객을 떼어내기 위한 기계(deflection machines)처럼 설계되었기 때문입니다.

목표는 보통 "티켓(tickets) 감소"에서 시작됩니다. 스프레드시트상으로는 합리적으로 들릴지 모르지만, 이는 잘못된 제품을 만들어냅니다. 상담원으로부터 사람들을 멀어지게 하도록 구축된 봇은 격리(containment), 정해진 스크립트 루프(scripted loops), 그리고 모호한 답변을 최적화하게 됩니다. 고객들은 이를 알아차립니다. 고객들은 소프트웨어와 대화를 나누려는 것이 아닙니다. 결제 문제를 해결하거나, 주문을 변경하거나, 액세스 권한을 복구하거나, 무언가를 취소하거나, 다음에 어떤 일이 일어날지 이해하려고 하는 것입니다.

봇이 실제 업무를 수행할 수 없을 때, 그 경험은 봇이 아예 없는 것보다 더 나빠집니다.

흔한 실패 패턴은 다음과 같습니다. 고객이 "왜 두 번 결제되었나요?"라고 묻습니다. 봇은 결제 처리(payment processing)에 관한 정책 요약본으로 응답합니다. 고객이 다시 묻습니다. 봇은 결제 FAQ 링크를 제공합니다. 고객이 "상담원(agent)"이라고 입력합니다. 봇은 말을 바꿔서 다시 해달라고 요청합니다. 사람이 개입할 때쯤이면 고객은 화가 나 있고, 지원 팀은 마땅히 알고 있어야 할 맥락(context)을 충분히 확보하지 못한 상태가 됩니다.

문제는 모델(model)의 언어 능력이 부족한 것이 아니었습니다. 문제는 워크플로(workflow)가 취약했다는 점입니다.

훌륭한 고객 서비스 AI는 세 가지 업무를 분리하는 것에서 시작합니다.

첫째, AI는 의도(intent)와 긴급성(urgency)을 이해해야 합니다. 비밀번호 재설정, 환불 요청, 배송 지연, 그리고 사기 우려(fraud concern)는 모두 동일한 일반적인 대기열(queue)에 들어가서는 안 됩니다. 시스템은 요청을 분류하고, 고객이 차단된 상태인지 감지하며, 조치를 취하기 전에 스스로 어느 정도의 확신(confidence)을 가지고 있는지 결정해야 합니다.

둘째, AI는 정확한 계정 및 정책 맥락(context)을 검색(retrieve)해야 합니다. 오래된 도움말 센터(help center)를 바탕으로 답변하는 봇은 그럴듯하게 추측만 하고 있는 것입니다. 주문, 구독, 예약, 보증 또는 송장에 대해 이야기해야 한다면, 관련 소스 데이터(source data)와 무엇을 말할 수 있고 무엇을 말할 수 없는지에 대한 명확한 규칙이 필요합니다.

셋째, AI는 좁은 범위의 작업(narrow task)을 완수하거나 깔끔한 인수인계(handoff)를 준비해야 합니다. 이 둘은 서로 다른 결과물입니다. 작업을 완수한다는 것은 시스템이 주문 이행(fulfillment) 전 배송 주소를 업데이트하거나, 재설정 링크를 보내거나, 반품 라벨을 생성하거나, 알림 설정을 변경하는 것과 같이 특정 작업을 안전하게 수행할 수 있음을 의미합니다. 인수인계는 고객이 처음부터 다시 설명하지 않도록 적절한 세부 정보를 수집하고, 문제를 요약하며, 올바른 상담원에게 전달하는 것을 의미합니다.

이 마지막 부분이 대부분의 팀이 생각하는 것보다 훨씬 중요합니다. 유용한 봇은 모든 문제를 해결할 필요가 없습니다. 마찰(friction)을 줄이는 것이 핵심입니다. 만약 고객이 "이미 재설정 링크를 시도했는데 만료되었습니다"라고 말한다면, 상담원은 케이스 요약(case summary)에서 이를 즉시 확인할 수 있어야 합니다. 고객이 스크린샷을 업로드했다면, 상담원이 이를 다시 요청할 필요가 없어야 합니다. 요청 내용이 금전, 신원, 법적 용어 또는 계정 해지와 관련되어 있다면, AI는 언제 멈추고 에스컬레이션(escalate)해야 하는지를 알아야 합니다.

가장 훌륭한 구현 사례들은 대개 '올바른 의미에서' 지루합니다. 명확한 경계가 있고, 실행 가능한 동작(actions)의 집합이 작으며, 발생한 일을 기록합니다. 신뢰 수준(confidence levels)을 공개하고, 사람이 잘못된 요약을 수정할 수 있게 하며, 왜 케이스가 특정 방식으로 라우팅(routed)되었는지 쉽게 파악할 수 있도록 만듭니다.

성공 여부를 측정할 수 있는 하나의 지원 흐름(support flow)부터 시작하세요. 예를 들어, "내 주문은 어디에 있나요?" 또는 "이메일 주소를 업데이트해야 합니다"와 같은 것을 선택하십시오. 고객의 메시지부터 해결에 이르기까지의 현재 경로를 매핑하십시오. 상담원들이 동일한 후속 질문을 얼마나 자주 하는지 계산하십시오. 그런 다음 전체 고객 지원 사이트에 일반적인 챗봇을 투입하는 대신, 그 경로를 중심으로 AI를 구축하십시오.

실용적인 첫 번째 버전은 단 다섯 가지만 수행할 수도 있습니다: 고객 식별, 요청 분류, 관련 기록 추출, 누락된 질문 하나 던지기, 그리고 완료된 작업 또는 인수인계 요약 생성하기입니다. 이는 겸손하게 들릴지 모르지만, 모든 것에 대해 이야기할 수 있지만 아무것도 해결하지 못하는 봇보다 훨씬 더 유용합니다.

지표 또한 바뀌어야 합니다. 단순히 방어율 (deflection rate)만 추적하지 마세요. 최초 접점 해결 (first-contact resolution), 반복 문의 (repeat contacts), 정확한 라우팅까지 걸리는 시간 (time to correct routing), 고객 노력 (customer effort), 에스컬레이션 품질 (escalation quality), 그리고 AI 요약에 대한 상담사의 수정 사항 (agent edits to AI summaries)을 추적해야 합니다. 만약 상담사들이 봇의 노트를 끊임없이 다시 작성하고 있다면, 그 시스템은 시간을 절약하고 있지 않은 것입니다. 만약 고객이 AI의 응답 이후에 케이스를 다시 오픈한다면, 그 봇은 숨겨진 업무 (hidden work)를 만들어내고 있는 것입니다.

고객 서비스 AI는 '서비스'라는 측면을 존중할 때 작동합니다. 목표는 사람들이 기계와 대화하게 만드는 것이 아닙니다. 목표는 고객이 막다른 길에 덜 부딪히면서 문제에서 해결로 나아가게 하는 것입니다.

이를 위해서는 보여주기식 연출 (theater)보다는 더 많은 배관 작업 (plumbing), 즉 깨끗한 데이터 접근 (clean data access), 명확한 권한 (clear permissions), 좁은 범위의 액션 (narrow actions), 가시적인 인수인계 (visible handoffs), 그리고 리스크가 큰 상황에서의 인간의 검토 (human review)가 필요합니다.

Othex Corp에서 우리는 그러한 실질적인 경계 (practical boundary)를 염두에 두고 AI 워크플로우 (AI workflows)를 구축합니다. 만약 귀하의 팀이 실제 운영 환경 내에서 AI를 유용하게 만들고자 노력하고 있다면, https://othexcorp.com에서 저희를 찾을 수 있습니다.