AI 고객 서비스 봇을 위한 채널 선택 가이드

에이전트의 행동은 모델보다는 채널에 의해 더 많이 결정됩니다. 고객들이 이미 있는 곳, 각 채널이 기계적으로 취약한 부분, 그리고 왜 네 개가 아닌 하나를 출시해야 하는지에 대한 내용입니다.

두 개의 지점(location)을 가진 요가 스튜디오가 단 일주일 만에 세 가지 채널(Instagram DM, 웹 채팅, SMS)에 AI 에이전트를 배포했습니다. Instagram에서는 첫 주 동안 약 300개의 메시지에 응답했지만, 작동하는 예약 링크를 신뢰성 있게 보내지는 못했습니다. 웹 채팅에서는 대부분의 대화가 첫 번째 답변 이후 조용해졌고 아무것도 예약되지 않았습니다. SMS에서는 매우 훌륭하게 작동했는데, 이는 일주일에 약 40개의 메시지였기 때문입니다. 왜냐하면 거의 아무도 스튜디오에 문자를 보내지 않기 때문입니다.

동일한 에이전트, 동일한 사실 파일(facts file), 동일한 모델이었습니다. 하지만 세 가지 다른 결과가 나왔습니다. 이것은 우연이 아니며, 제가 모든 고객에게 플랫폼보다 채널을 먼저 선택하라고 말하는 이유입니다. 채널은 메시지 길이, 지연 시간 기대치(latency expectations), 보낼 수 있는 미디어 유형, 대화에 정체성(identity)이 붙어 있는지 여부, 그리고 고객에게 '정상적인' 것이 무엇인지 등을 결정합니다. 모델은 이 중 어느 것도 결정하지 못합니다.

채널이 대화의 규칙을 설정한다

모델은 어디서든 동일하게 행동하지만, 고객들은 그렇지 않습니다. 각 채널은 자체적인 불문율(unwritten contract)을 가지고 있습니다:

• DM: 사람에게 문자 메시지를 보내는 느낌입니다. 답변은 몇 초 안에 기대되며, 두 문장만으로도 충분한 단락이 됩니다.
• 이메일: 편지글과 같습니다. 아무도 2분 안에 답장을 받을 것이라고 기대하지 않기 때문에, 몇 초 만에 응답하는 에이전트는 아무 가치가 없습니다.
• 웹 채팅:

SMS. 메시지는 160자 단위로 분할되므로, 긴 답변은 순서가 뒤섞인 조각들의 스택 형태로 도착합니다. 많은 기기에서 신뢰할 수 있는 버튼이나 풍부한 미디어(rich media)를 사용할 수 없으며, 링크는 예측 불가능하게 렌더링됩니다. 또한 모든 메시지는 고객의 주의력—그리고 어쩌면 돈—을 소모시킵니다. 더불어 고객에게 문자 메시지를 보내기 위해서는 관할 지역별로 상이한 동의 규칙(consent rules)이 존재하므로, 구축하기 전에 현재의 현지 요구 사항을 확인해야 합니다. 짧고 구조화된 교환에 가장 적합합니다: 확인(confirmation), 알림(reminder), 한 번에 하나의 질문으로 답변하는 경우.

WhatsApp. 풍부한 미디어 사용이 원활하며 고객들이 사진 등을 자유롭게 보내기 때문에, "손상 사진을 보내주세요"와 같은 상황에 매우 유용합니다. 하지만 함정은 기계적인 부분에 있습니다: 24시간 고객 서비스 창구(customer-service window) 외부에서는 비즈니스가 자유 형식의 답변이 아닌 승인된 템플릿 메시지만을 보낼 수 있다는 것입니다. 개방형 아웃리치(open-ended outreach)를 가정하고 구축된 에이전트나 플로우는 대화가 하루 동안 조용해지는 순간 무너집니다. 이 창구 제한은 단순히 마케팅 설계뿐만 아니라 전체적인 에스컬레이션 디자인을 결정합니다.

웹 채팅(Web chat). 방문자가 이미 사이트에 의도를 가지고 있는 채널이며, 동시에 침묵 속의 포기(silent abandonment)가 가장 심각한 채널입니다. 고객이 첫 답변을 받고 탭을 닫으면 세션은 종료됩니다. 보통 신원 정보가 연결되어 있지 않기 때문에, 예약까지 단 5초 남았던 대화라 할지라도 후속 조치를 취할 수 없습니다. "에이전트가 답변했다"는 것을 성공으로 간주하는 것이 전형적인 웹 채팅의 오류이며, 대화 도중에 고객이 이탈하는 것(mid-conversation leaving)은 포함률 대시보드(containment dashboard)에 나타나지 않는 실패입니다.

Instagram 및 Facebook DM. 이곳은 발견(discovery)이 일어나는 곳이지만, 스레딩 구조는 혼란스럽습니다: 댓글과 DM, 여러 개의 병렬 대화, 오타와 음성 메모로 작성된 단편적인 메시지가 뒤섞여 있습니다. 받은 편지함에는 영업 문의, 스팸, 지원 요청이 모두 섞여 있으며, 에이전트는 이 모든 것을 동일한 목소리로 답변해야 합니다. 세션에 명확한 시작이나 끝이 없기 때문에, 어떤 것을 측정하더라도 정직하게 측정하기가 매우 어렵습니다.

이메일. 구조적이고 영구적이며, 상세한 문의 및 기록 보관에 적합합니다. 하지만 상호 합의 하에 느린 채널입니다. 고객이 답장을 내일 받을 것으로 기대하는 곳에 실시간 상담원 서비스 비용을 붙이는 것은 아무도 원하지 않았던 속도에 프리미엄을 지불하는 것과 같습니다. 이메일이 빛을 발하는 곳은 더 빠른 채널에서 온 요약 및 확인서의 목적지로서입니다.

비교표

[!NOTE]
WhatsApp의 24시간 창은 실제 운영 환경에서 팀들이 발견하는 가장 세부적인 사항입니다. 고객이 하루 동안 답장을 멈추면, 상담원은 사전 승인된 템플릿 메시지로만 대화를 재개할 수 있습니다. 보내고 싶은 것이 아니라, 어떤 템플릿을 승인받을 수 있는지에 맞춰 후속 조치를 설계하십시오.

네 개가 아닌 하나부터 시작하세요

멀티 채널은 상담원들이 유지보수 불가능한 상태가 되는 곳입니다. 추가되는 각 채널은 실패 모드를 곱합니다: 다른 세션 처리, 다른 길이 규칙, 다른 어조 기대치, 별도의 기록(transcript), 별도의 테스트. 제대로 된 하나의 채널이 대충 만든 네 개의 채널보다 항상 낫습니다.

어떤 것을 고를까요:

1. 오늘 문의가 어디서 들어오는지 계산하세요. 지난달의 문의를 가져와 각 건이 어떤 채널을 통해 왔는지 태그를 지정합니다. 이것은 한 시간이 걸리며 논쟁을 끝냅니다. 만약 80%가 Instagram DM으로 온다면, 팀이 어느 채널에 흥미를 느끼든 상관없이 Instagram이 당신의 채널입니다.
2. 해당 볼륨이 반복적인 질문인지 확인하세요. 500개의 고유한 일회성 질문이 있는 채널보다 같은 열두 가지 질문 중 150개가 반복되는 채널이 더 좋습니다. 이 반복되는 내용들이 사실 파일(facts file)이 처리할 수 있는 것입니다.
3. 약점을 당신의 허용 범위와 맞추세요. 만약 예약 문의가 침묵하는 웹 채팅 포기(silent web-chat abandonment)로 인해 발생하고 후속 조치 경로가 없다면, 그 채널은 출시 단계에서 더 많은 인간의 감독이 필요합니다. 파편화된 SMS 답변에 견딜 수 있다면, SMS는 거의 유지보수가 필요 없습니다.
4. 채널의 제약 사항을 프롬프트에 작성하세요. 최대 답변 길이, 링크를 언제 보내야 하는지, 언제 에스컬레이션(escalate)해야 하는지 등을 명시합니다. 동일한 사실 파일이 모든 채널에 동력을 제공하지만, 이 줄들만 바뀝니다.
5. 매주 한 달 동안 스크립트를 읽고, 그 후에 두 번째 채널을 추가하세요. 그 전에는 안 됩니다. 첫 번째 채널에서 고객들이 실제로 무엇을 묻는지 배우는 것이 중요하며, 그 지식을 두 번째 채널로 가져가는 것이 가장 많은 작업입니다.

제가 가장 많이 보는 네 가지 실수

1. 모든 곳에 한 번에 출시하는 것. 첫 주에 세 개의 채널을 운영한다는 것은 세 가지 세트의 버그, 기준선(baseline) 부재, 그리고 어떤 채널이 저조한지 또는 그 이유가 무엇인지 알 수 없다는 것을 의미합니다. 서두에서 언급된 요가 스튜디오는 세 채널 모두 한꺼번에 변경되었기 때문에 어느 채널이 작동하는지조차 말할 수 없었습니다.
2. 팀이 선호하는 채널을 선택하는 것. 사장님은 이메일을 좋아하지만, 고객들은 DM에 살고 있습니다. 문의 기록(enquiry log)이 이것을 결정합니다. 의견은 그렇지 않습니다.
3. 하나의 스크립트를 변경 없이 모든 채널에 적용하는 것. SMS 길이의 답변은 이메일에서 간결하게 보이지만; 이메일 길이의 답변은 SMS에서는 산산조각 납니다. 같은 사실이라도 포장 방식이 다릅니다—포장은 프롬프트 안에 있습니다.
4. 모든 채널을 하나의 수치로 측정하는 것. 단일 포함률(containment figure)은 웹 채팅 포기 문제를 완전히 평균화하여 사라지게 만듭니다. 채널별로 보고하고, 어떤 것을 믿기 전에 스크립트를 읽으세요.

오늘 할 일

• 지난달 문의 내용을 추출하여 채널별로 건수를 파악하고, 이 숫자를 팀에 공유합니다.
• 반복되는 질문의 양이 가장 많은 단일 채널을 선택합니다.
• 해당 채널의 제약 사항(길이, 미디어 유형, 링크 동작 방식 등)을 시스템 프롬프트에 작성합니다.
• 상상 속 내용이 아닌, 해당 채널의 실제 대화 기록(transcript)을 기반으로 사실 파일(facts file)을 구축합니다.
• 채널 2 선택은 한 달간 대화 기록을 읽어본 후에, 30일 뒤로 예약합니다.

채널은 전달 방식에 대한 세부 사항이 아닙니다. 그것은 에이전트 행동의 절반이며, 플랫폼 공급업체가 프로덕션 환경에서 기꺼이 발견하도록 내버려 둘 부분입니다. 먼저 채널을 선택하고 하나를 출시한 다음, 열정보다는 대화 기록 로그가 언제 다음 채널을 추가해야 할지 알려주도록 하십시오.

본 가이드는 AgentFast에서 확인할 수 있으며, 이곳에서는 사용자의 에이전트 지침을 이러한 실패 모드와 비교하는 무료 감사 도구(free audit tool)도 찾을 수 있습니다. 여기 게시된 내용은 원본을 가리키는 정규 URL과 함께 제공됩니다.