2.2 효율적인 VOC분석을 위한 코드 설계

Mar 10. 2025

VOC(Voice of Customer)에 대한 관심은 어느 기업에서나 크다. 고객경영의 핵심이 VOC에 있다고 해도 과언이 아니기 때문에 많은 경영진이 VOC 데이터에 귀를 기울인다. 그러나 실무자 입장에서 보면 VOC 분석이 어렵거나, 제대로 활용되지 않는 경우가 많다. 현장 접점에서 일하는 상담사나 기사들과 면담을 하다 보면 "이런 민원이 많아요"라고 말하지만, 실제 상담 코드를 분석해 보면 관련 데이터가 부족한 경우가 있다. 또는, 간담회를 통해 다양한 문제점을 듣고 VOC 경영의 중요성을 인식한 경영진이 정작 필요한 데이터를 확보하지 못해 혼란을 겪는 경우도 있다.

현장 체험을 통해 잔뜩 고무된 임원이 관련 데이터는 얼마나 되는지 확인해 보는데, 정작 그 많다던 문제점을 찾아내지 못할 때의 당황스러움은 겪어보지 않은 사람은 모른다. 이런 경우 현장 직원의 목소리가 잘못된 것으로 치부해 버리는 경우가 생기기도 하는데, 이 얼마나 비효율적인가 말이다.

이러한 일이 발생하는 이유는 무엇일까?

이는 VOC 코드 체계가 제대로 설계되지 않은 탓이다. 대부분의 기업에서는 처음부터 VOC를 체계적으로 수집하기 위해 상담 코드를 설계하지 않았다. 가입자 관리 시스템이 먼저 도입되고, 이후 상담 관리 시스템이 추가되면서 ERP 자료와 연동하는 과정에서 상담 코드가 VOC 코드와 일치하게 된 경우가 많다. 하지만 VOC 코드는 CS 경영을 위한 핵심 자원으로, 중복되지 않고 누락이 없도록 체계적으로 관리해야 한다.

상담코드는 고객 응대 과정에서 기록하기 위한 목적으로 개발한 코드이며, VOC코드는 이를 기반으로 고객의 목소리를 분석하기 위해 설계되는 코드 체계이다. 두 개념이 다소 다르지만, 혼재되어 사용되기도 하고 일부 회사에서는 같은 코드를 활용하기도 한다. 그렇기 때문에 어떻게 활용할 것인지부터 정의해야 한다.

VOC코드의 체계를 마련하기 위해서는 몇 가지 원칙을 가지고 가야 하는데,

첫째, MECE(Mutually Exclusive and Collectively Exhaustive, '겹치지 않으면서 빠짐없이')하게 항목들이 상호 배타적이면서도 모였을 때는 완전한 전체를 이룰 수 있어야 한다.

제품코드와 상담속성 및 인입원인 코드로 구분 가능한 텍스트를 포함하는 코드는 생성하지 않도록 특히 유의해야 한다.

두 번째, 사용빈도가 낮은 코드는 병합하거나 삭제하는 것이 좋다. 상담코드가 지나치게 세분화되어 있으면, 실제 사용하지 않는 코드가 많아지고 분석이 어려워진다. 불필요한 코드를 정리하여 VOC분석의 효율성을 높여야 한다.

세 번째, 대분류, 중분류, 소분류 내에 '기타'코드는 절대 생성해서는 안된다. 기타 코드가 생기는 순간 가장 큰 비중을 차지하는 VOC는 기타가 된다. 모든 VOC를 특정한 유형으로 분류할 수 있도록 체계를 갖추어야 한다. 그래서 VOC 코드 체계를 정비할 때는 현장에서의 대표 인력이 함께 포함되어야 한다.

네 번째 VOC코드를 통해 요구 및 개선 위치를 정확히 파악할 수 있도록 설계해야 한다. VOC는 단순히 불만 접수 통계만 내는 것이 아니라, 고객 경험 개선과 서비스 향상을 위한 분석 자료로 활용될 수 있어야 한다.

다섯 번째 VOC코드를 정비할 때는 기존 코드의 마이그레이션 없이 신규 코드로 진행해야 나중에 혼란이 생기지 않는다. 사유 코드의 잘못된 마이그레이션으로 그동안의 VOC데이터 추세선이 갑자기 폭증 또는 폭락으로 보일 수 있기 때문이다. 예를 들어, 기존에 '요금 불만' 코드가 있었는데, 새롭게 '요금 청구 오류'와 '요금 정책 불만'으로 분리되면, 과거 데이터와 비교가 어려워질 수 있다. 하나의 코드라 둘로 나뉘는 효과만 있는 것이 아니라, 다른 코드에 있던 내용이 세분화된 곳으로 섞여 들어올 수도 있기 때문이다. 필자의 경우도 마이그레이션으로 실수한 뼈아픈 경험이 있다.

VOC코드의 체계를 이해하려면 기본적인 코드 구성 요소를 명확히 이해해야 한다. 제품코드, 상담속성, 인입원인 코드가 무슨 말인지 궁금하신 분들을 위해서 한번 더 기술해 보도록 하겠다.

제품코드는 고객이 사용 중인 제품의 유형을 정의하는 코드이나, 우리가 쉽게 이해할 수 있는 가전사의 경우를 보면 냉장고, 세탁기, TV등과 같은 제품 대분류 정도로 이해하면 될 것이다. 제품은 상담 인입 시 고객의 소유 제품에 있기 때문에 굳이 제품명을 만들지 말라는 의미이다.

상담속성이라고 함은 상담의 성격을 정의하는 코드로 예를 들면, 오류, 불만, 제안, 칭찬 등으로 구분할 수 있겠다. 인입 원인을 고객이 문의를 하게 된 원인을 정이하는 코드로 AS접수, 사용 방법 문의, 요금 불만 등이 여기에 해당된다. 처리 코드는 상담 후 최종 처리 결과를 정의하는 코드이다.

구체적으로 예를 들어서 한번 설명을 더 해보겠다. 예를 들어 고객이 집에서 사용하는 TV의 소리가 잘 나오지 않아서 AS를 신청하는 경우를 살펴보자.

상담접수 시 코드를 보면, 아래와 같은 형태로 등록하게 된다.

상담을 하고 난 후 유선상으로 해결이 되지 않을 경우, AS 접수를 하게 된다.

. AS접수(작업 코드) --> 상세설명(소리가 잘 안 나옴)--> 작업편성(희망일자 및 시간 설정)

위와 같이 상담이 되면, AS를 접수하면서 우선 제품의 코드를 물고 갈 것이고 접수를 하게 되면 서비스가 이관돼서 넘어가기 때문에 일반 상담문의와는 또 다른 상태로 접어든다. 이관되는 경우는 어느 부서에서 해당 업무를 처리하게 될지 결정해야 하고 이관받은 부서에서는 일정시간 안에 해당 상담문의를 해결하고 처리코드를 넣어야 한다.

최종적으로 기사가 댁내에 방문해서 AS처리를 하고 처리 코드를 등록할 때는 문의 시 등록했던 접수코드와 처다를 수 있다. 접수는 TV불량으로 접수했더라도 처리 코드는 커넥트 불량이나 오디오 사운드 불량일 수 있기 때문이다.

VOC코드를 만들려고 하면 위와 같은 변수가 많기 때문에 상담코드 및 업무 프로세스를 명확히 꿰고 있는 사람을 멤버에 꼭 포함시켜야 한다. 상담 과정에서 어떤 정보가 필요하며, 이 정보가 어떻게 분석될 것인지 함께 고려해야 한다. 그리고 IT부서의 담당자도 배정받아야 한다. 왜냐하면 IT담당자 없이 CS담당자가 코드를 다 만들어버리면 전산에 코드를 입히면서 업무를 다시 정의해야 하는 경우가 생기기 때문이다.

VOC 코드가 단순한 데이터 분류 체계가 아니라, 시스템에서 자동으로 수집·분석될 수 있도록 설계되어야 의미가 있다. 따라서 IT 부서와 CS 부서가 협력하여, 실무에서 활용 가능한 형태로 VOC 코드를 설계해야 한다. IT 부서와의 협업 없이 코드가 만들어지면, 전산 적용 과정에서 추가적인 비용과 시간이 소요될 가능성이 높다. IT 부서가 초기에 코드 설계 과정에 참여하는 것이 가장 이상적인 접근 방식이다.