수천, 수만 건의 상담 대화를 읽고 고객이 어떤 상황에서 연락했는지 일일이 확인하는 건 현실적으로 어려웠습니다.
그래서 문의를 넓은 유형으로 묶어 건수를 세고, 규모가 큰 유형을 중심으로 자동화 대상을 정하곤 했습니다.
운영 현황을 관리하기에는 합리적이지만, 문의를 하게 된 이유까지 알 수 있는 건 아니었습니다.
LLM을 활용하면 기존 상담유형만 보지 않고, 대화 속에서 반복되는 상황과 고객의 요청을 따로 분석할 수 있습니다.
수많은 대화에서 문제를 구분할 수 있다면 투자 우선순위도 다르게 세울 수 있습니다. 어떤 문제는 제품이나 정책을 바꿔 문의 발생을 줄이고, 어떤 업무는 셀프서비스나 자동화로 옮기고, 어떤 판단은 상담사에게 남겨야 합니다. 분류 정확도를 높이는 데서 끝나지 않고, 어디에 돈과 사람을 써야 할지 판단할 근거가 생기는 겁니다.
그렇다고 대화만 보고 원인을 단정할 수는 없습니다. 고객이 어떤 경로를 거쳤는지, 당시 서비스 상태가 어땠는지, 적용된 정책과 상담사의 조치까지 함께 봐야 합니다.
STT로 전사한 상담 대화는 출발점이 될 수 있습니다. 고객의 상황과 요청, 상담사가 안내한 내용이 드러나니까요. 하지만 문의의 계기나 상담사의 실제 조치는 대화 밖에 있을 수 있습니다. 이전에 발송된 문자, 유입 채널, 앱에서 막힌 단계, 당시 계정 상태와 시스템 처리 이력까지 연결해야 같은 질문을 제대로 해석할 수 있습니다.
‘FDS가 뭐예요?‘라는 반복 문의가 그랬습니다. 처음에는 용어를 설명하면 될 것 같았지만, 이상거래 안내 문자를 받은 직후라는 맥락을 확인하니 문제가 달리 보였습니다. 고객은 문자를 받고 무엇을 해야 할지 몰랐던 겁니다. 그래서 챗봇에서 담당 부서로 연결하도록 바꾸고, 문자 안내도 보완해 달라고 요청했습니다.
이 데이터가 연결돼야 무엇을 바꿀지 판단할 수 있고, 개선한 뒤에 같은 문제로 다시 연락하는 고객이 줄었는지도 확인할 수 있습니다.
LLM이 문제를 찾는 데 도움을 줄 수는 있어도 제품을 고칠지, 자동화할지, 정책을 바꿀지는 결국 사람이 결정해야 합니다.
마지막 편에서는 이런 분석을 어떻게 실제 개선으로 이어갈 수 있을지 이야기해 보겠습니다.
#ConversationIntelligence #LLM #AIProductManagement