AI가 상담원에게 인계되었는데, 상담원이 고객에게 모든 것을 다시 말해달라고 요청하는 상황

지난 분기 배포 검토에서 본 장면입니다. AI 에이전트는 제 역할을 수행했습니다. 고객이 알레르기에 대해 질문했고, 에이전트는 에스컬레이션(escalation) 트리거를 인식한 후 1초도 안 되어 인계했습니다. 기술적으로는 완벽했습니다.

그런데 사람이 그것을 이어받아 다음과 같이 작성했습니다: "안녕하세요, 무엇을 도와드릴까요?"

이미 자신의 상황을 두 번이나 설명했던 고객은 창을 닫았습니다.

에스컬레이션 자체는 작동했지만, 인계(handoff)는 실패한 것입니다. 이 둘은 다른 문제이며, 그중 오직 한 가지만이 주목받습니다.

에스컬레이션은 라우팅 문제입니다. 핸드오프는 컨텍스트 문제입니다.

대부분의 팀들은 에스컬레이션을 트리거로 구축합니다: 감성 점수 하락, 키워드 일치, 신뢰도 저하 → 사람에게 라우팅(route). 그리고 그 작업은 완료된 것으로 간주됩니다.

하지만 라우팅은 단지 누가 답변할지만 결정할 뿐입니다. 사람이 대화를 시작할 때 무엇을 알고 있는지에 대해서는 아무것도 말해주지 않습니다. 페이로드(payload) 없이는, 사람은 제로(zero)부터 시작하게 되고 — 고객은 세 번째 설명으로 그 비용을 지불합니다.

실패는 측정 가능합니다. 제가 감사했던 배포 사례에서, AI 에스컬레이션 후 평균적인 사람의 답변 시간은 6분 이상이었고, 이 중 대부분은 생각하는 시간이 아니었습니다. 트랜스크립트(transcript)를 스크롤하고, 이미 무엇이 약속되었는지 파악하고, 다음에 무엇을 말할지 결정하는 재구성 과정이었습니다. 페이로드가 있었다면, 같은 답변들이 60초도 안 되어 나갔을 것입니다.

5개 필드 핸드오프 페이로드

모든 에스컬레이션은 정확히 다섯 개의 필드를 담아야 합니다. 트랜스크립트 전체를 덤프하는 것이 아니라 — 다섯 개의 필드입니다:

1. Contact     — 이름 + 연락 가능한 채널
2. Summary     — 고객 자신의 말로 한 문장 요약
3. Tried       — 에이전트가 이미 답변했거나 약속한 것
...

두 가지 예시를 채워 넣은 것입니다:

알레르기 에스컬레이션

1. Contact:  Maria, SMS +1-555-0142
2. Summary:  어린이 메뉴에 땅콩이 포함되어 있는지 문의함
3. Tried:     메뉴 항목은 온라인에서 확인 가능하다고 확언했으나, 알레르겐에 대해서는 언급하지 않음
...

환불 에스컬레이션

연락처(Contact): Dan, [email protected]
요약(Summary): 지난주 주문 건에 대해 환불을 원하며, 상품이 파손되어 도착했다고 언급함
시도 내용(Tried): 표준 정책을 설명했으며, 환불을 제공하거나 거부하지 않음
...

필드 3이 무엇을 하는지 주목하세요. '제공하거나 거부하지 않음(Did NOT offer or deny)'이라는 문구는 정책이 여전히 유효하다는 것을 사람에게 알려줍니다. 즉, 상담원이 이미 약속한 내용을 모순할 위험이 없습니다. 이 단 하나의 문구가 가장 흔한 인계 실패 사례를 방지합니다. 바로 사람이 무엇을 했는지 모르기 때문에 두 번째로 과도하게 약속하는 경우입니다.

왜 전문(transcript) 자체가 페이로드(payload)가 아닌가

본능적으로는 전체 대화 내용을 첨부하고 싶어 합니다. 맥락이 더 많으면 더 좋지 않을까요?

실제로는 원시적인 전문(raw transcript)을 사용하면 인계 과정이 느려집니다. 사람은 섞여 있는 메시지를 읽고, 고객이 원하는 것과 상담원이 추측한 것을 분리하고, 머릿속으로 답장을 작성해야 합니다. 이 다섯 가지 필드가 사람이 스레드를 열기 전에 압축 작업을 수행해 주는 것입니다. 10초 동안 읽는 것이 고대 유적을 발굴하는 두 분의 시간을 대체합니다.

전문은 필요할 때를 대비하여 링크 뒤에 보관하세요. 그리고 그 필드들을 가장 앞에 보이도록 만드세요.

페이로드를 어디에 배치해야 하는가

유용성 순으로 세 가지 옵션이 있습니다:

티켓 설명(Ticket description) — 페이로드 자체가 티켓 본문입니다. 에스컬레이션 과정에서 티켓이 생성될 때 가장 좋습니다.
첫 내부 메모(First internal note) — 도구가 설명을 메모와 분리하는 경우. 이미 티켓이 존재하는 경우 가장 좋습니다.
고정된 내부 메시지(Pinned internal message) — 최소한의 필수 요소입니다. Slack/Teams 기반 지원에 가장 적합합니다.

어떤 것을 선택하든, 하나의 규칙을 적용하세요. 상담원의 페이로드는 사람이 볼 '시작 상태(starting state)'여야 합니다. 만약 사람이

만약 상담원이 답변을 작성하기 위해 대화 기록(transcript)이 필요하다면, 필드가 누락되어 있습니다. 만약 고객에게 응답하기 전에 후속 질문이 필요한 경우라면, 3번 또는 4번 필드는 너무 모호합니다. 이러한 두 가지 실패 사례는 드릴 과정에서 즉시 나타나며 수정 비용이 저렴합니다.

좋은 인계(handoff)가 제공하는 것들

맥락을 가지고 전달되는 에스컬레이션은 세 가지 일을 동시에 수행합니다: 고객에게 반복해서 말해달라고 요청하지 않으며 (따라서 이탈하지 않고), 상담원이 한 번에 답변할 수 있게 하고 (따라서 대기열이 비워지며), 아무것도 중복 약속되지 않습니다 (따라서 승인하지 않은 환불이 발생하지 않습니다).

이 모든 것을 더 똑똑한 모델이나 새로운 공급업체가 필요로 하는 것은 아닙니다. 다섯 개의 필드와 그것들을 매번 채우는 규율만 필요합니다.

5개 필드 페이로드 템플릿, 세 가지 완성된 예시, 그리고 에스컬레이션 트리거 목록은 제가 고객 작업에 사용하는 인계 키트의 일부입니다 — 작성 가능한 버전: Escalation Payload Kit