고객의 소리

고객이 하는 말은 한 곳으로 들어오지 않습니다. 상담 메일로도 오고, 제품 안 채팅으로도 오고, 영업 담당자가 계약 자리에서 듣고 수첩에 적어 오기도 하고, 앱 마켓 별점 하나짜리 후기나 커뮤니티 글로 남기도 합니다. 각 창구는 그 자리에서 답하고 닫는 것이 일이라, 답이 나간 뒤 그 말은 그 창구의 기록 안에 그대로 묻힙니다. 기록은 남는데 모이지는 않는 상태입니다.

그러면 제품 회의에서 근거 없는 문장이 오갑니다. "요즘 고객들이 이걸 많이 원해요" 라는 말이 나오는데, 파고들면 지난주에 만난 고객 한 곳이 한 말인 경우가 흔합니다. 반대편도 사정이 같습니다. 영업이 "이 기능 없으면 이번 계약 못 땁니다" 하고 말하면 개발은 "저번에도 그렇게 만들었는데 켜 보는 사람이 없었어요" 하고 답합니다. 둘 다 진짜로 들은 말이지만 둘 다 몇 건인지는 모릅니다. 근거가 목소리의 크기와 가까움뿐이라 결국 그 자리에서 제일 급해 보이는 쪽이 이깁니다.

같은 요청이 몇 번이고 다시 들어오는 것도 이 시절의 풍경입니다. 반년 전에 똑같은 요청을 받아 이미 만들어 놓고도 그 사실을 요청한 고객에게 알려 주지 않았으니, 고객은 없는 줄 알고 다시 묻고 상담 담당자는 다시 답합니다. 반대로 안 만들기로 결정한 요청도 아무 말 없이 사라지기 때문에, 고객 쪽에서는 말해 봐야 소용없다는 결론이 남고 그다음부터는 조용히 떠납니다. 회사가 보는 화면에서는 문의 수가 줄어든 것처럼 보이니 좋아진 줄 압니다.

고객의 소리는 흩어진 말을 한 곳에 모아 세어 볼 수 있는 형태로 바꾸는 활동입니다. 바뀌는 것은 정보의 양이 아니라 종류입니다. 한 사람이 들고 온 일화가 몇 건짜리 자료가 되면 그때부터 순서를 매길 수 있습니다. 만들기 전에 만들 값어치가 있는지 확인하는 제품 디스커버리 활동 가운데 이 방법이 가장 싸게 시작되는 이유도 여기 있습니다. 새로 나가서 묻는 대신 이미 들어와 쌓여 있는 것을 쓰기 때문입니다.

고객의 소리 아래 용어는 한 갈래입니다. 활동을 이루는 구성 요소 셋인데, 나란히 놓인 항목이 아니라 말이 들어와 처리되고 다시 나가는 한 바퀴의 서로 다른 구간입니다.

1. 피드백 채널 — 의견이 들어오는 창구입니다. 상담 문의가 한 건씩 쌓이는 지원 티켓, 제품 안에 달아 둔 피드백 버튼, 추천 의향을 0에서 10으로 묻는 순추천지수 설문의 자유 서술 칸, 영업과 고객 담당자가 미팅에서 받아 적는 메모, 앱 마켓 후기와 커뮤니티 글이 전부 채널입니다. 채널마다 말하는 사람이 다릅니다. 상담 문의에는 지금 막혀서 화가 난 사람이 오고, 설문에는 그럭저럭 쓰는 사람이 답하고, 영업 메모에는 아직 고객이 아닌 사람의 말이 섞여 들어옵니다. 그래서 한 채널만 보고 판단하면 그 채널을 쓰는 사람의 사정만 제품에 반영됩니다.
2. 기능 요청 — 들어온 말 가운데 이런 걸 만들어 달라는 형태로 온 항목입니다. 다루기 까다로운 이유는 요청이 문제가 아니라 고객이 혼자 세운 해법이기 때문입니다. 엑셀로 내보내게 해 달라는 요청 뒤에는 대개 월말 보고서를 손으로 옮겨 적고 있다는 사정이 있고, 그 사정을 적어 두지 않으면 다른 고객이 낸 비슷한 요청과 묶이지 않습니다. 요청을 받을 때 한 겹 벗겨 무엇을 하려다 막혔는지를 함께 남기는 것이 뒤의 모든 단계를 좌우합니다.
3. 피드백 루프 — 받은 말이 반영되고 그 결과가 다시 확인되는 순환입니다. 고친 뒤에 요청한 고객에게 알리고, 그 사람이 실제로 문제가 풀렸다고 말하는 데까지 가야 한 바퀴가 닫힙니다. 회신이 빠지면 앞의 두 구간이 아무리 잘 돌아도 같은 요청이 계속 들어오고, 고객 쪽에서는 이 회사에 말해도 바뀌지 않는다는 학습만 남습니다.

셋을 실제로 굴리는 절차는 여섯 칸입니다. 분기에 한 번씩 돌리는 팀이 많고, 문의가 많은 제품이라면 달마다 돌립니다.

1. 모으기 — 모든 채널의 기록을 한 표로 옮깁니다. 한 줄에 원문, 들어온 날짜, 어느 채널인지, 어느 고객인지, 그 고객의 플랜이 들어갑니다. 이때 요약하지 않고 고객이 쓴 문장을 그대로 붙여 넣습니다. 옮기는 사람이 줄이는 순간 판단이 섞여 들어가고, 나중에 왜 그렇게 읽었는지 되짚을 수 없습니다.
2. 꼬리표 붙이기 — 항목마다 제품의 어느 영역인지, 요청인지 불만인지, 어느 고객이 말했는지를 답니다. 꼬리표 목록을 먼저 합의하고 시작합니다. 붙이면서 만들면 사람마다 다른 이름을 쓰게 되어 다음 분기에 두 분기를 비교할 수 없습니다. 꼬리표는 많을수록 좋은 것도 아닙니다. 스무 개를 만들어 두면 붙이는 사람이 고르다 지쳐 손에 잡히는 것을 찍고, 세 개만 두면 절반이 기타로 들어갑니다. 제품 영역을 기준으로 다섯에서 여덟 개쯤이 한 분기를 버팁니다.
3. 한 겹 벗기기 — 요청을 문제로 바꿔 적습니다. "엑셀 내보내기를 만들어 주세요" 는 "월말 보고서를 손으로 옮기느라 두 시간이 든다" 가 됩니다. 이 줄이 생기면 엑셀 내보내기와 자동 보고서와 외부 도구 연동이 한 묶음으로 보입니다.
4. 세기 — 건수만 세지 않고 누가 말했는지를 함께 붙입니다. 같은 요청 스무 건이 전부 무료 플랜 개인 사용자에게서 왔는지, 그중 넷이 스무 석짜리 유료 팀에게서 왔는지는 전혀 다른 숫자입니다. 이미 해지를 통보한 고객의 요청이면 이탈 사유 기록과 붙여 함께 봅니다.
5. 정하고 만들기 — 정리된 표를 우선순위 회의에 입력으로 넣습니다. 이 표가 결정을 대신하지는 않습니다. 전략상 지금 하지 않기로 한 것은 요청이 서른 건이어도 미룹니다.
6. 돌려주기 — 요청한 사람에게 결과를 알립니다. 만든 것뿐 아니라 안 만들기로 한 것도 알립니다. 후자를 알리는 회사가 드물어서, 하기로 했다는 소식보다 안 한다는 소식이 오히려 신뢰를 쌓는 경우가 많습니다. 회신은 길 필요가 없습니다. 말씀하신 검색 문제는 이번 달에 고쳤고, 함께 요청하신 폴더 일괄 이동은 이번 분기에는 하지 않기로 했으며 그 까닭은 무엇이라는 세 줄이면 충분합니다. 안 하기로 한 쪽에 까닭이 붙어야 다음에도 말이 들어옵니다.

여섯 칸 중 빠지면 티가 나는 곳은 2번과 6번입니다. 꼬리표 없이 모으기만 하면 문서 하나에 문장 사백 개가 쌓인 채로 아무도 열어 보지 않게 되고, 돌려주기가 빠지면 채널이 서서히 마릅니다. 말해도 답이 없다는 것을 배운 고객은 다음부터 쓰지 않을 뿐 불평을 접지는 않습니다. 소수의 큰 고객에게서 더 정리된 의견을 받고 싶으면 고객 자문단처럼 따로 자리를 만드는 방법이 있지만, 그 자리에 나올 만큼 열성인 고객은 전체와 다른 사람들이라 여섯 칸을 대신하지는 못합니다.

"이건 한 곳만 말한 게 아니라 이번 분기에 열한 건 들어왔어요. 그중 넷이 스무 석 넘는 팀입니다."

개별 민원이 아니라 반복되는 문제이며 매출이 걸려 있다는 근거를 대는 말입니다.

"요청은 엑셀 내보내기인데 뒤에 있는 건 월말 보고서예요. 내보내기를 만들어도 그 일은 안 없어집니다."

고객이 말한 해법 대신 그 뒤의 문제를 보자는 제안입니다.

"지난 분기에 이거 요청했던 고객들한테 회신 나갔나요?"

반영한 결과를 요청자에게 돌려줬는지 확인하는 질문이고, 안 나갔으면 같은 문의가 또 들어온다는 뜻입니다.

페이지덱에서는 창구가 넷이었고 넷이 서로 다른 곳에 쌓여 있었습니다. 상담 메일은 수아가 쓰는 상담 도구에, 제품 안 피드백 버튼으로 들어온 글은 개발팀 데이터베이스에, 영업 미팅 메모는 각자의 문서에, 커뮤니티 글은 아무 데도 없었습니다. 지현이 분기에 한 번 넷을 한 표로 옮기기로 하고 꼬리표를 여섯 가지로 미리 정했습니다. 문서 편집, 검색·탐색, 권한·공유, 알림, 속도, 결제·플랜이었습니다. 제품 영역을 그대로 따른 구분이라 누가 붙여도 같은 자리에 들어갔습니다.

첫 분기에 나온 1위는 아무도 예상하지 못한 항목이었습니다. 권한 설정을 손봐 달라는 요청이 제일 많을 것이라 다들 짐작했는데, 실제로 가장 많이 나온 문장은 만든 문서를 다시 못 찾겠다는 쪽이었습니다. 표현이 제각각이라 그때까지 같은 문제로 묶인 적이 없었습니다. 검색이 안 된다, 폴더가 헷갈린다, 어제 쓴 문서가 어디 갔는지 모르겠다는 말이 전부 한 꼬리표 아래로 들어오고 나서야 서른아홉 건이 되었습니다.

수아가 같은 표에 지난 분기에 해지한 고객 일곱 곳의 기록을 붙였더니 그중 다섯 곳이 같은 꼬리표를 달고 있었습니다. 태오는 그제야 검색 쪽을 이번 분기 작업으로 올렸고, 지현은 서른아홉 건을 낸 고객 전원에게 무엇이 바뀌었는지 메일을 보냈습니다. 그다음 분기에 같은 꼬리표의 건수는 아홉 건으로 줄었습니다. 규원이 이 표를 보고 남긴 말은 간단했습니다. 그동안 우리가 못 들은 게 아니라 세지 않았을 뿐이라는 것이었습니다.

가장 흔한 오해는 이 활동을 투표함으로 읽는 것입니다. 요청마다 건수가 붙으니 많이 나온 것부터 만들면 공정하고 합리적으로 보입니다. 그런데 말을 남기는 사람은 전체 사용자 가운데 아주 얇은 층입니다. 대개는 제품을 아주 열심히 쓰는 사람이거나 지금 크게 화가 난 사람이고, 그럭저럭 쓰다가 조용히 그만둔 사람은 한 줄도 남기지 않습니다. 건수만 따라가면 이미 들어와 있는 열성 사용자의 취향 쪽으로 제품이 계속 휘고, 정작 들어오다 만 사람들이 막힌 자리는 표에 나타나지 않습니다. 그래서 이 표는 순위표가 아니라 후보 목록으로 다루고, 조용히 떠난 쪽의 사정은 해지 기록이나 중간에 이탈한 지점의 숫자로 따로 채워 넣습니다.

수집만 해 두면 굴러간다고 보는 오해도 흔합니다. 도구를 하나 붙이고 채널을 열어 두면 의견이 알아서 쌓이니 일이 끝난 것처럼 보이고, 실제로 초기 몇 주는 숫자가 잘 올라갑니다. 문제는 쌓인 것을 아무도 읽지 않는 상태가 생각보다 빨리 온다는 데 있습니다. 꼬리표가 없으면 문장 사백 개가 든 문서는 열어 볼 엄두가 나지 않고, 그 문서를 근거로 든 회의가 한 번도 없으면 상담 담당자도 옮겨 적기를 그만둡니다. 이 활동이 멈추는 자리는 거의 언제나 수집이 아니라 분류와 회신 쪽입니다. 그래서 채널을 늘리기 전에 이미 있는 채널의 기록을 한 번 끝까지 분류해 보는 편이 낫습니다. 창구가 넷인데 아무도 열어 보지 않는 상태보다 창구가 하나여도 분기마다 읽히는 상태가 제품을 더 많이 바꿉니다.