VOC는 왜 모으기만 하고 개선으로 이어지지 않나요?
고객의 소리를 개선으로 연결하는 출발점은 수집량이 아니라 분류 체계입니다. VOC는 Voice of Customer의 약자로 고객 피드백을 모아 제품과 서비스를 바꾸는 활동을 가리킵니다. 국내 연구에서 쓰인 기본 범주는 요구사항, 불편사항, 격려, 건의사항 네 가지인데요 실무에서는 이 상위 범주 아래 계층적 소분류를 붙여 유사한 문의를 묶어 봅니다. 분류 코드를 조직도에 맞춰 만드는 순간 데이터는 원인별 대신 담당 부서별로 쌓입니다. 그러면 같은 원인에서 나온 문의가 서로 다른 코드로 흩어져 재발 건수가 집계되지 않습니다. 개선으로 이어지는 VOC 체계는 분류를 원인 단위로 짜고 완료 확인까지 루프를 닫습니다.
목차
- 분류 코드 112개를 다시 짜 본 기록
- 수집 채널은 어떻게 설계하나요
- 분류 체계는 조직도가 아니라 원인으로 짭니다
- 재발 방지 루프는 어디서 끊기나요
- VOC 체계 설계 4단계
- FAQ
- 같이 읽으면 좋은 것들
분류 코드 112개를 다시 짜 본 기록
한국서비스연구소(Korea Service Research Institute)에서는 고객센터를 운영하는 중견 서비스 기업을 자문하면서 VOC 분류 체계를 함께 손봤습니다. 기존 체계에는 소분류 코드가 112개 있었고 상담원이 통화를 마치고 그중 하나를 선택하는 구조였습니다.
먼저 1년치 데이터에서 코드별 건수를 셌습니다. 112개 가운데 상위 8개가 전체의 71%를 차지했습니다. 반대쪽에서는 1년 동안 한 번도 쓰이지 않은 코드가 23개였습니다. 코드가 많다는 사실 자체가 분류의 정확도를 뜻하지 않았습니다. 상담원 인터뷰에서 이유가 나왔습니다. 애매할 때 선택하는 기본 코드가 있었고 그 코드 하나에 전체의 19%가 몰려 있었습니다. 통화 후 처리 시간을 줄이려면 고민하지 않고 고를 수 있는 칸이 필요했습니다.
두 번째로는 같은 원인이 여러 코드로 흩어진 경우를 봤습니다. 결제 시스템의 특정 오류 하나가 결제 문의, 앱 오류, 환불 요청, 회원 정보 세 네 개 코드에 나뉘어 들어가 있었습니다. 각 코드에서는 월 20~30건 수준이어서 우선순위 목록에 올라오지 않았습니다. 합치면 월 100건을 넘는 1순위 과제였습니다. 분류 체계가 문제를 숨기고 있었던 셈입니다.
코드를 다시 짤 때 기준을 하나로 정했습니다. 이 문의를 없애려면 누가 무엇을 바꿔야 하는가였습니다. 그 질문에 같은 답이 나오는 문의는 같은 코드로 묶었습니다. 결과적으로 소분류는 112개에서 38개로 줄었습니다. 상담원 선택 시간이 짧아졌고 기본 코드 비중은 19%에서 6%로 내려갔습니다. 무엇보다 월별 상위 과제 목록이 처음으로 실제 개선 과제처럼 읽혔습니다.
작업에서 예상 못 한 부수 효과도 있었습니다. 코드가 줄어들자 상담원들이 메모 칸을 더 길게 쓰기 시작했습니다. 선택지가 애매할 때는 코드로 때우고 메모를 비웠는데 코드가 명확해지니 그 코드에 담기지 않는 맥락을 적을 여유가 생겼습니다. 원문 메모의 평균 길이가 두 배 가까이 늘었고 분석할 재료가 함께 늘었습니다. 분류 체계를 손보니 데이터 질 전체가 올라갔습니다.
수집 채널은 어떻게 설계하나요
VOC는 한 곳에서만 들어오지 않습니다. 채널마다 들어오는 내용의 성질이 다르므로 채널 구성 자체가 데이터의 편향을 만듭니다.
| 채널 | 주로 들어오는 내용 | 특징 |
|---|---|---|
| 콜센터 전화 | 즉시 해결이 필요한 불편 | 감정 강도 높음, 기록이 상담원 손에 달림 |
| 챗봇·채팅 | 단순 문의, 절차 질문 | 원문 텍스트 확보 용이 |
| 앱스토어 리뷰 | 사용성 불만, 업데이트 반응 | 응답이 공개됨, 평점과 연동 |
| 홈페이지 게시판 | 길고 구체적인 건의 | 작성 부담이 커 건수 적음 |
| 현장 접점 | 대기와 응대 경험 | 기록이 거의 남지 않음 |
| 만족도 설문 | 정량 점수와 짧은 코멘트 | 응답자 편향 존재 |
현장 접점은 기록이 남지 않아 가장 흔한 공백입니다. 매장이나 창구에서 나온 불만은 그 자리에서 해소되거나 사라집니다. 데이터에 없으면 개선 과제로 올라가지 않습니다. 현장 직원이 30초 안에 입력할 수 있는 간단한 양식을 두는 것만으로 이 공백이 줄어 듭니다. 항목을 많이 만들면 아무도 쓰지 않으므로 위치, 상황 분류, 한 줄 메모 정도로 제한하는 편이 좋습니다.
채널별 비중도 함께 봐야 합니다. 전화 비중이 높은 조직은 데이터가 즉시성 높은 불편 쪽으로 기울고 리뷰 비중이 높으면 사용성 쪽으로 기웁니다. 어느 쪽도 전체 고객을 대표하지 않습니다. 침묵하는 다수는 어느 채널에도 나타나지 않으므로 설문이나 이탈 고객 조사로 보완하는 설계가 필요합니다. 해지한 고객에게 한 문항만 묻는 방식도 쓸 만합니다. 해지 사유를 선택지로 받으면 접수된 VOC에 없던 원인이 드러나는 경우가 많습니다.
분류 체계는 조직도가 아니라 원인으로 짭니다
분류 체계를 만들 때는 부서 이름을 그대로 가져오는 실수가 가장 흔합니다. 배송팀, 결제팀, 회원팀 같은 코드가 생기면 데이터는 담당 배분용으로만 쓰입니다. 개선에 필요한 정보는 어느 부서로 보낼지보다 무엇을 바꿔야 하는지입니다.
세 층으로 나누는 방법
- 대분류: 고객이 겪은 상황 유형. 주문, 배송, 결제, 이용, 해지 같은 여정 단계로 둡니다
- 중분류: 구체적인 문제 양상. 지연, 오류, 안내 부족, 조건 불일치처럼 적습니다
- 소분류: 원인 단위. 이 문의를 없애려면 무엇을 바꿔야 하는지로 정의합니다
여정 단계로 대분류를 두면 어느 구간에서 고객이 막히는지가 보입니다. 해지 단계에 문의가 몰린다면 해지 경로 설계 자체를 봐야 합니다. 중분류에 안내 부족이 많으면 상담 교육이 아니라 안내문과 화면 문구를 손볼 문제입니다. 상담 품질을 올려도 안내문이 그대로면 같은 문의가 계속 들어옵니다. 교육으로 해결할 문제와 설계로 해결할 문제를 가르는 기준이 중분류에서 나옵니다.
코드 개수의 적정선
코드가 많을수록 정확해진다는 전제는 현장에서 깨집니다. 상담원이 선택해야 하는 선택지가 많으면 기본 코드로 도피합니다. 그래서 연구소 자문 사례에서는 112개를 38개로 줄였을 때 오히려 분류 정확도가 올라갔습니다. 적정선은 상담원이 목록을 스크롤하지 않고 고를 수 있는 수준입니다. 코드를 줄이면 세부 정보가 사라진다는 걱정이 나오는데 그 역할은 원문 메모가 맡습니다. 코드는 집계를 위한 장치이고 맥락은 텍스트에 남깁니다. 두 가지를 한 칸에 담으려 하면 양쪽 다 부실해집니다.
텍스트 분석을 붙이는 경우에도 코드 체계가 먼저입니다. 원문을 토픽 단위로 묶는 자동 분석은 사람이 정의한 범주와 대조할 기준이 있을 때 쓸모가 생깁니다. 기준 없이 돌리면 결과를 해석할 방법이 없습니다. 상담 녹취를 분석에 쓰려면 수집과 이용에 관한 안내와 동의 절차를 먼저 갖춰야 합니다. 음성을 텍스트로 바꾸는 과정에서 개인정보가 함께 저장되므로 보관 기간과 접근 권한을 정해 두는 일이 분석 설계의 일부입니다.
재발 방지 루프는 어디서 끊기나요
VOC가 개선으로 이어지는 과정은 다섯 단계입니다. 수집, 분류, 원인 분석, 개선 실행, 완료 확인입니다. 실무에서 가장 자주 끊기는 지점은 마지막 두 곳입니다.
| 단계 | 끊기는 이유 | 막는 방법 |
|---|---|---|
| 수집 | 현장 기록 누락 | 30초 입력 양식 |
| 분류 | 기본 코드 도피 | 코드 수 축소, 원인 단위 정의 |
| 원인 분석 | 담당 부서 배정으로 종료 | 상위 과제에 근본 원인 질문 적용 |
| 개선 실행 | 주관 부서 미지정 | 과제별 담당자와 기한 명시 |
| 완료 확인 | 재발 건수 추적 없음 | 개선 전후 동일 코드 건수 비교 |
완료 확인이 빠지면 같은 과제가 매년 목록에 올라옵니다. 개선했다고 보고된 항목의 코드 건수를 3개월 뒤에 다시 세는 절차를 넣으면 실제로 줄었는지가 숫자로 드러납니다. 줄지 않았다면 원인 진단이 틀렸거나 실행이 안 된 것입니다. 둘 다 알아야 할 정보입니다.
재발이 줄지 않는 과제를 그대로 두는 조직과 다시 분석하는 조직은 1년 뒤에 갈립니다. 한쪽은 같은 목록을 반복해 보고하고 다른 쪽은 목록이 교체됩니다. VOC 보고서의 상위 항목이 해마다 똑같다면 루프가 닫히지 않고 있다는 신호로 읽을수 있습니다.
연계 지표도 함께 봅니다. 첫 통화 해결률이 낮은 코드는 상담 단계에서 끝나지 않는 문제이므로 뒤쪽 프로세스에 원인이 있습니다. 고객 노력 점수가 높게 나오는 구간은 절차 자체가 번거로운 지점입니다. VOC 건수와 이 지표들을 같이 놓으면 어느 문의가 단순히 많은 것인지, 구조적으로 해결이 안 되는 것인지가 구분됩니다.
VOC 체계 설계 4단계
1단계 1년치 데이터로 코드 실태를 봅니다
코드별 건수를 내림차순으로 정렬합니다. 상위 몇 개가 전체의 몇 퍼센트를 차지하는지, 한 번도 쓰이지 않은 코드가 몇 개인지, 기본 코드 비중이 얼마인지를 셉니다. 이 세 숫자가 현재 체계의 상태를 그대로 보여 줍니다.
2단계 원인 단위로 코드를 다시 정의합니다
각 코드에 질문을 붙입니다. 이 문의를 없애려면 누가 무엇을 바꿔야 하는가입니다. 같은 답이 나오는 코드끼리 합칩니다. 다른 답이 나오는데 한 코드에 묶여 있으면 쪼갭니다. 부서 이름은 코드에서 뺍니다.
3단계 현장 기록 경로를 만듭니다
매장과 창구에서 30초 안에 입력할 수 있는 양식을 둡니다. 위치, 상황 분류, 한 줄 메모면 충분합니다. 입력 건수가 적다고 양식을 늘리면 더 줄어듭니다. 대신 입력된 내용이 개선으로 이어진 사례를 현장에 공유하면 기록이 늘어 납니다. 현장 입력을 평가 지표로 쓰면 건수를 채우기 위한 형식적 기록이 쌓이므로 권하지 않습니다. 기록의 가치는 건수가 아니라 개선으로 연결된 비율에서 나옵니다. 월 한 건이라도 과제로 올라갔다면 그 경로는 작동합니다. 반대로 월 수백 건이 쌓이는데 과제로 올라간 항목이 없다면 그 경로는 저장소일 뿐입니다. 수집과 분석 사이가 아니라 분석과 실행 사이에서 끊긴 상태입니다.
4단계 완료 확인을 일정에 넣습니다
개선 과제마다 담당자와 기한, 그리고 3개월 뒤 재측정 일정을 함께 적습니다. 재측정은 같은 코드의 월 건수를 다시 세는 것으로 충분합니다. 이 절차가 들어가면 VOC 보고서가 현황 공유 문서에서 관리 도구로 바뀝니다. 연구소 자문 사례에서 담당자들은 체계를 바꾼 뒤 가장 달라진 점으로 이 부분을 꼽았습니다.
FAQ
VOC 분류 코드는 몇 개가 적정한가요?
정해진 숫자는 없지만 상담원이 목록을 스크롤하지 않고 고를 수 있는 수준이 기준입니다. 코드가 많으면 애매할 때 선택하는 기본 코드로 몰려 정확도가 떨어집니다. 연구소 자문 사례에서는 112개를 38개로 줄인 뒤 기본 코드 비중이 19%에서 6%로 내려갔습니다.
같은 원인인데 여러 코드로 흩어진 것은 어떻게 찾나요?
상위 과제 목록에 올라오지 않는 중간 건수 코드들을 모아 원문 메모를 읽어 보는 방법이 가장 확실합니다. 결제 오류 하나가 네 개 코드에 나뉘어 각각 월 20~30건이던 사례가 합치면 월 100건을 넘는 1순위 과제였습니다. 코드별 건수만 보면 보이지 않습니다.
현장에서 들어온 불만은 어떻게 기록하나요?
입력 항목을 최소화하는 것이 핵심입니다. 위치, 상황 분류, 한 줄 메모 정도로 제한하고 30초 안에 끝나게 만듭니다. 항목이 많으면 아무도 쓰지 않습니다. 기록이 개선으로 이어진 사례를 현장에 공유하면 입력 동기가 생깁니다.
VOC 건수가 늘어나면 서비스가 나빠진 건가요?
단정할 수 없습니다. 접수 경로를 늘리거나 안내를 강화하면 건수가 늘어납니다. 건수 자체보다 원인별 재발 추이와 첫 통화 해결률 같은 지표를 함께 봐야 합니다. 건수 감소를 목표로 걸면 접수를 어렵게 만드는 쪽으로 움직일 위험이 있습니다.
텍스트 자동 분석을 도입하면 분류가 해결되나요?
분류 체계를 먼저 정리한 뒤에 효과가 납니다. 사람이 정의한 원인 단위 범주와 대조할 기준이 있을 때 자동 분석 결과를 해석할 수 있습니다. 기준 없이 돌린 토픽 묶음은 보고서에 넣을 수는 있어도 개선 과제로 옮기기 어렵습니다.
같이 읽으면 좋은 것들
- 첫 통화 해결률은 어떻게 재고 무엇을 바꿔야 하나요? 재문의 판정 창과 이관 구조로 보는 콜센터 측정 설계 4단계
- NPS(순추천지수)는 어떻게 계산하고, 무엇을 알려 주나요?
- 공공기관 고객만족도 조사는 어떻게 진행되나요?
출처
- 정보서비스 개선을 위한 고객의 소리(VOC) 활용방안에 대한 연구 https://www.kci.go.kr/kciportal/landing/article.kci?arti_id=ART001977210
- VOC 고객의 소리, 제대로 분류하고 계신가요? (Deskroom) https://blog.deskroom.so/cx/voc-customer-voice-analysis
- 고객의 소리(VoC)에 관하여, A-Z까지 (VOC STUDIO) https://blog.voc-studio.com/voc-a-to-z-everything-about-voice-of-customer
- 고객중심경영 VOC(Voice of Customer) 시스템 구축 우수지식사례 https://www.elandcsr.or.kr/filedownload?p=Upload%2FAttachFile%2F1&f=7.pdf&v=7.pdf
- 매출 상승을 이끄는 VoC 수집 및 분석 방법, 실제 적용 사례 https://blog.tryvox.co/voc-collection-analysis/