VOC에 대해서는 다들 들어봤을 것이다.
Voice Of Customer
고객의 소리이다.
내가 속한 조직은 IT 기업의 B2B SaaS이지만, 사실 VOC는 모든 업종에서 들어오는 것이다. 이번 글은 좀 더 범용적으로 활용될 수 있을 것 같다.
VOC에 대한 내용은 네 가지 꼭지로 정리해볼 수 있겠다.
1. VOC의 종류
2. VOC 정리하는 법
3. VOC를 분석하는 법
4. 추가적으로 VOC를 모으는 법
이번 글에서는 1번과 2번에 대해 말해보겠다.
일단 VOC의 종류를 나눠봐야 한다. 어디선가 읽었던 아티클에서 이렇게 크게 3개로 나눠 놓은 걸 봤고, 내가 봤을 때에도 이렇게 3개로 나누는 것이 맞을 것 같다.
(1) 되는 기능인데 고객이 몰라서 물어보는 거
(2) 되는 기능인데 오류로 인해서 안 되는 거
(3) 원래 안 되는 기능인데 고객이 원하는 거
각각은 해결 방법이 다르다.
(1)의 경우는 가이드 문서나 영상을 정비한다든지, 온보딩 때 강조할 수도 있다. 아니면 근본적으로 UX/UI를 개선하는 것도 한 방법이다.
(2)는 버그이다. 오류로 인해서 안 된다면 개발자에게 고쳐달라고 해야 한다. 고객의 문의의 대다수가 이렇다면 제품을 다시 한 번 점검해봐야 한다. 제품의 안정성은 신뢰와 연관이 된다. 버그를 근본적으로 없앨 수는 없겠지만, 적어도 고객사에서 발견해서 문의하는 경우는 최대한 없어야 되지 않을까 싶다. 개발 & QA팀 화이팅!
(3)은 신규 기능 제안이다. 고객이 원하는 신규 기능은 잘 정리해서 기획에 전달하면 된다. 전달하는 양식은 기획에서 정하는 경우가 많다. 내용을 정리해서 전달할 때, 최대한 구체적으로 작성할 수록 좋다. 왜 이걸 필요로 하는지, 세부적으로 어떻게 작동되어야 하는지가 나와야지 나중에 기능 개발이 될 때 반영될 수 있다. 디테일하게 작성하지 않으면 기능이 개발된 뒤에 고객이 원하는 게 아니어서 실제 사용이 안 될 수도 있기 때문이다.
물론 고객은 이 세 가지를 구분하지 못하고, 그냥 원하는 게 안 되었다고만 생각할 수 있다. 1이나 3에 대한 문의가 많았으면서 나중에 이탈을 하면서 ‘아니 뭐 맨날 안 되고 그래서 사용성이 너무 별로여서 안 쓰려구요’라고 말할 수도 있다. 고객의 입장에서는 결국 불편한 건 매한가지니까. 하지만 실무자의 입장에서는 이 세 가지를 구분해야 그에 따른 해결책을 제대로 제공할 수 있게 된다.
일단 VOC는 가만히 있어도 들어온다. 왜냐하면 고객들은 질문이 많기 때문이다. 소통 채널에 따라서 다음과 같이 나눌 수도 있다. 조직마다 소통 창구를 어떻게 가져가는지는 다르다.
메일
채팅 상담
전화
미팅 (온라인 / 오프라인)
각종 소통 창구로 VOC가 물 밀듯이 들어올 것이다. 유실하지 말고 잘 정리해보도록 하자. 만약 하나의 메일에 질문이 3가지 다른 종류가 들어왔다면 이를 3가지로 나눠서 정리하도록 하자.
(1) 포함되어야 하는 항목
날짜
담당 CSM (드롭다운으로 선택하게 하자)
누가 문의했는지 (사람 & 회사 둘 다 넣으면 좋음, 드롭다운으로 선택하게 하자)
제목
내용
카테고리 (대분류 & 소분류 둘 다 있으면 좋음, 대분류는 위에서 말한 3가지 종류로 나누면 좋다, 드롭다운으로 선택하게 하자)
채널 (어떤 소통 창구로 들어왔는지이다)
소요 시간 (고급 버전, 옵션)
더불어 VOC를 모으는 툴은 여러 가지를 사용할 수 있다. 허브스팟이나 세일즈포스 같은 유료 툴을 사용해도 되고, 아니면 그냥 구글 스프레드 시트로 해도 된다. 당장 비싼 돈 들여서 유료 툴을 도입하지 말고, 구글 스프레드 시트로 시작해보시길 권한다.
(예시)
예를 들어서, 아래와 같이 문의 메일이 들어왔을 때 어떻게 정리하는지 살펴보자.
2023.12.10
안녕하세요, 매니저님
솔루션 사용 중에 문의 사항이 있어서 메일드립니다.
1. 데이터 정합성
지난 달로 넣고 조회했을 때, 데이터가 안 맞더라구요.
[링크] 확인 부탁드립니다.
2. 제외 필터 가능 여부
필터 적용하려고 하는데, 제가 방법을 모르는 건지…
ㅇㅇㅇ에 대한 내용을 제외하고 싶어서요. 어떻게 해야 되나요?
3. 사용자 초대 불가
사용자 초대를 하려고 하면 이렇게 오류가 나더라구요.
확인 부탁드립니다.
실제로 확인해 봤을 때,
1번은 버그가 아니라 고객사의 실수로 데이터가 제대로 조회되지 않았던 것이고,
2번은 현재 제공하지 않는 신기능,
3번은 버그였다.
그렇다면 이렇게 정리해볼 수 있다.
(1) 되는 기능인데 고객이 몰라서 물어보는 거 => 대분류에서 “일반 문의”로 분류
(2) 되는 기능인데 오류로 인해서 안 되는 거 => 대분류에서 “버그”로 분류
(3) 원래 안 되는 기능인데 고객이 원하는 거 => 대분류에서 “기능 추가”로 분류
소분류는 일반 문의일 때 나오는 항목들과 버그일 때 나오는 항목들이 달라서 구분해 놓았다. 각각의 세부 항목은 필요한 대로 만들면 된다.
첫 술에 배부를 순 없다. 하나씩 잡아 나가면 엄청난 VOC 모음을 만들 수 있다!
정리하는 게 또 다른 일이라고 안 하다보면 결국 VOC는 휘발되어 버린다.
다음 글은 이번 글에 이어서 VOC를 분석해보자 (2탄)을 써보겠다.