CS가 탁월하면 Product가 무능해진다.
스타트업은 항상 무언가 모든것의 부족이 기본값이다보니, 그들이 만드는 제품은 대부분 불완전하고 불편합니다. 그러다보니 특히 대고객서비스를 제공하는 경우에는 항상 CS와의 전쟁을 치를수 밖에 없게됩니다. 그래서 어느 기업이 어떤 종류의 CS에 직면했다는 내용을 기사나 주변분들의 SNS 등을 통해서 보는 일도 잦고, 어느정도 감안하고 볼만한 여지가 있다고 생각하곤 합니다.
물론 이런글을 쓰고 있는 저 자신이 누구보다도 프로불편러이다보니, 제품에 이런 부분이 비어있거나, 잘못설계되어 있(다고 생각하)거나, 무언가 예상한대로 흘러가지 않을때에 불편함을 거친말로 적어내서 주변분들을 당황시키는 일도 왕왕 있어왔습니다. 그분들께 이자리를 빌어 다시한번 죄송하다는 말씀드립니다. 변명을 덧붙이자면 저는 보통 제품 내에서 사용자의 main scenario를 잘못설계했다고 생각할때, 또는 User Story에 문제가 있다고 생각할때 글을 쏟아내는 편인데, 그렇게 쓰는 기저에는 분명히 Scenario나 UserStory가 없었다는 확신을 가지기 때문이기도 합니다.
본론으로 돌아와서, 저도 제품을 개발할 때에 Main Scenario를 설계하고 여기에서 벗어나는 일부 상황들에 대해서 "CS로 처리하자" 라고 쉽게 말하기도 합니다. 담당하는 CS부서에서야 쉽지 않은 일이겠지만 전체의 1-2% 수준일 것 같은 케이스를 모두 제품안에 처음부터 구현해내는 것은 상대적으로 과도한 비용을 지불해야 하기 때문이기도 하고, 무엇보다 이 제품이 어디로 흘러갈지 알수 없는 상황에서 sub Scenario도 아닌 모든 경우의 수를 감안할 수는 없기 때문이기도 합니다.
하지만 이렇게 한번 잡아놓고 나면, 나중에 개선할거야 라는 다짐따위는 무색하게 나중에는 계속 또 다른 무언가를 쫓기듯 해야 하고, 이런 minor case를 대응하는 일들은 계속해서 CS의 부담으로 남아버리곤 합니다. CS가 버티지 못하고 박살이 난다면 모를까, 그분들의 능력과 헌신으로 그 문제를 꾸역꾸역 잘 막아내기 시작하면 이 상황은 영원히 지속될지도 모릅니다. 그래서 오늘의 글감을 정했습니다.
“CS가 탁월하면 Proruct가 무능해진다” 게을러진다라는 표현이 좋을지 잠깐 고민을 했었습니다만, 총체적인 상태로는 무능이 더 어울릴것 같습니다.
반대의 개념이나 입장에서 유능한 Product란 무엇일까요? 제품의 Epic-UserStory를 설계하는 과정에서 '여기서부터 여기까지는 main scenario로 저기까지는 sub scenario로 처리'하고, 이 바깥의 어느 범위는 CS로 처리하자 라고 결정했을때, 그 CS까 main/sub 를 침범해들어오지 않는다면 유능한 Product라고 할 수 있을 것입니다. 고객의 신박하고 새롭고 다양함은 안해본 사람이 이해할 수 없다고도 말을 합니다만, 그럼에도 불구 CS팀이 높은 확률로 한정된 케이스만 대응할 수 있도록 해준다면 분명 유능한 제품이라고 할 수 있겠습니다.
반대로 무능한 제품이라고 한다면 Main Scenario에서 CS가 발생하는 것을 들 수 있겠습니다. 이렇게 되면 1-2%에 대한 CS가 아니라 70-80%를 대상으로 CS가 발생할 위험에 노출됩니다. 이제부터 CS팀은 사실상 운영의 역할에 참여해 들어오게 되고 이 상황이 반복되면 CS팀을 위한 전문적인 툴을 만들어야 할 필요가 생겨버립니다. 그리고 CS팀 구성원들이 (사실상 제품개발팀보다 박봉일텐데) 헌신적으로 이 문제들을 처리하고 대응해내기 시작하면 이제 그것이 뉴 노멀이 되어서 제품팀은 CS팀의 CS처리를 위한 운영툴을 만들고 유지보수하는 Requirement를 수립하고 대응하고 있게 될 것입니다.
크리티컬한 사항은 아니었다지만 제가 최근에 경험했던 한가지 사례를 가지고 이 사안을 설명해보려고 합니다. 부득불 등장하는 두 기업에게는 죄송하다는 말씀 미리 전합니다. 저는 두 가입의 서비스를 여전히 잘 사용하고 있습니다.
제가 사는 동네는 꽤나 산간오지에 해당합니다. 그래서 배달의민족으로 배달을 시키면 항상 판매자가 취소를 때리곤 하는 곳입니다. 요새는 좀 세상이 좋아져서 주문품목에 저희동네 배송료 상품이 붙어있는 경우가 있긴합니다만, 그런 곳이다보니 세탁서비스들로부터는 오랜동안 외면받아 왔습니다. 한때 리화이트를 통해서 동네세탁소를 이용하기도 했었지만 불편함이 없었던 것은 아니다보니 세탁특공대가 처음으로 오픈을 했을때 아주 감사한 마음으로 이용을 했습니다. 그런 세특에서 월간결제를 하는 패키지를 출시했기에 저는 침구류 패키지를 구독해서 이용했습니다. 큰 할인폭이다보니 사실 한두번 쯤 이용을 건너뛰어도 별다른 손해는 아니긴 했지만 그래도 사람마음이 그렇지 않죠. 그래서 매월 특정 시점이 되었을때에는 꼭 침구류 세탁을 보내곤 했습니다. (세탁서비스 관련 CS는 압도적으로 세탁품질에 관한 얘기가 많습니다만 이부분은 워낙 발생할 케이스가 다채롭고 또 개연성도 다양하다보니 제게는 문제가 되는 부분은 아니었습니다. )
제게 닥친 문제는 나는 분명 패키지 결제라고 보냈는데, 일반결제로 발생하는 것이었습니다. CS와 대화를 하면서 알게된 사실은 현재 나의 패키지 상태가 어떤지 확인할 수 있는 메뉴가 없다는 것과, (카카오톡으로 문의를 하면 남은 회수를 알려준다고), 그리고 이 패키지 요금은 월 구독제가 아니라 30일 구독제라는 사실이었습니다. 그리고 카운트의 기준은 수거신청일이나 수거일이 아니라 수거후 확정일이라는 것이죠. 그러니까 매월 15일이 결제일이라고 생각하고 보냈지만, 어느달은 하루가 빨라져있고 몇개월 지나면 여러날이 당겨져 있습니다. 2월을 지나면 뒤로 밀려있기도 합니다. 그러니까 보낼때마다 어느정도의 gap을 감안하고 보내야만 하는 것이죠.
이 문제는 사용자의 습관을 제품개발에 고려하지 않았기 때문에 발생했다고 생각했습니다. 게다가 패키지를 팔았는데 (READ) 조차도 구성되어 있지 않아서 이 문제를 CS에 떠넘기고 있다는 것은 저는 제품으로서는 문제 수준이 아니라 그냥 결격사유라고 생각했습니다.
얼마의 시간이 흐르고 나서 아마도 구성원들이 열심히 노력하신 결과 CS가 몸빵을 때우는 사이에 월간구독패키지를 대체하는 세특패스 라는 좀 더 일반적(?)인 월간요금제가 발행되어 30일의 구독제의 문제는 사라지게 되었습니다.
그동안 참으로 유능한 CS팀 구성원들은 이런저런 불만을 쏟아내는 저에 대해서 때로는 얼르고 사과하고 보상을 쥐어줘가면서 이 문제를 운영해나가고 있었습니다. (이번은 특별히 이렇게 처리해드리겠습니다!!!! 하지만 몇개월 뒤에 다시 반복되는 기시감…..)
저는 세특패스를 일정기간 구독하다가 또 무엇인가 잘 기억나지 않는 사유로 이탈한 상태입니다. 사람이 이렇습니다. 막상 그때는 그것때문에 해지를 했으면서도 얼마 지나면 기억도 없네요.
헌옷수거는 돈이 되는 일인가요, CS만 늘어나는 일일까요?
제가 사는 산간오지가 드디어 런세권에 편입이 되었습니다. 런드리고의 문앞설치박스는 제 취향은 아니었지만 세특과 비교해서 꼭 써보고 싶었던 서비스이기에 기쁜 마음으로 테스트를 해보았습니다. 개인적으로는 여러 측면에서 더 깔끔하고 정돈된 서비스를 제공한다는 느낌을 받았고, 딱 그만큼 좀 더 비싸다는 생각을 했습니다. 그러다가 헌옷수거 “킬로그램당 300포인트” 를 보고 어차피 버릴 헌옷이라고 생각하고 문앞에 차곡차곡 모아두기 시작했습니다. (참고로 헌옷수거는 세특도 제공하는 서비스이고 한두번 이용한 경험이 있었습니다)
헌옷수거를 신청해보면 아래와 같은 주의경고문구 (부인방지문구)를 확인하실 수 있습니다. 이런 문구가 등장하는 배경은 당연히 이런 문제가 반복적으로 발생했기 때문이겠지요. 이 글을 쓰게 된 계기이기도 합니다. 어떤 문제가 반복적으로 발생하고 여기에서 사용자의 귀책여부를 명확하게 하지 않을수 없었을 것입니다. 그러니 CS부서/운영부서 혹은 법률부서에서는 이런 경고문구/부인방지 문구를 넣어야 한다는 요구사항이 도출되었을 수도 있습니다. PM이 여기에서 이 문구 하나 넣고, consent box 하나 추가하고 이 Requirement를 종료했다면 Product Manager로서 결격이라고 생각합니다. 어떤 요구사항이 발생했을때 그 표면의 요청사항만을 기계적으로 받아들인다면 아래 그림의 나무그네와 다를것이 뭐가 있을까요. 심지어 아래 나무그네 그림은 1989년에 출판된 도서에 포함되어 있었다는 사실을 잊지 맙시다. 35년 전이에요.
저는 이 checkbox에 동의를 하고 미리 꺼내놓은 2개의 헌옷봉투에 파란 매직으로 “헌옷” 이라고 써두었습니다. 그리고 몇시간 뒤 세탁물을 꺼내놓으려고 밖을 나가보고 문제가 생겼다는 사실을 깨달았습니다. “헌옷” 2봉투가 사라졌어요. 그리고 하나는 헌옷으로 하나는 세탁물로 수거해갔다는 사실을 잠시 뒤에 알게 되었습니다. (수거예정시간인 22시보다 2시간 빠른 20시에 벌어진 일이었지만, 이 문제는 수거시간의 문제는 아니라고 생각합니다. 안타깝게도 "반드시 22시 이후 수거" 라는 가이드가 추가로 제시 된 것 같습니다.)
그때부터 앱의 어떤 메뉴를 이용해도 이것이 잘못되었고, be about to 헌옷 중 한봉투는 세탁이 될 것이며, 나에게 세탁비용을 청구하고 또 CS와 지리멸렬하고 비생산적인 대화를 나눠야 할 제 모습이 떠오르기 시작했습니다. 그 스트레스로 불편한 글을 써질러버리는 바람에 다른 여러분을 불편하게 해드렸던 부끄러운 일도 생겨버렸습니다.
사용자 시나리오에서 헌옷수거는 어떻게 다뤄져야 하는 것일까요? 헌옷수거는 과연 CS비용을 상쇄할만큼은 이익이 되는 것일까 MRD를 보고 싶기도 했습니다만, 제가 생각한 문제는 헌옷을 규정하는 confirmation process가 유저스토리에 존재하지 않고, "오수거" 케이스가 유저시나리오를 정의하는 과정에서 고려되지 않았기 때문이라고 생각했습니다. 높은 확률로 유저시나리오를 따로 정의하지 않았을 것이고, 그래서 유저스토리가 세부적으로 형성되지 않았을 것이며, 아마도 헌옷을 수거하는 스크린샷부터 시작해서 화면정의서가 바로 작성되고 피그마에서부터 제품과정이 시작되었을지도 모르겠습니다.
헌옷이 세탁물과 혼입되는 문제는 처음에는 누구라도 막기 힘들었을 수 있습니다. 내놓은 사용자도 혼선이 있을수 있는데다가 무언가 표기를 한다는 것은 생각보다 많은 준비성과 노력을 요구하니까요. 그래서 문제는 당연히 발생하게 될텐데, 그 문제를 해결하는 대응제품이 그저 부인방지 문구를 넣고 책임을 전가하는 수준, 그리고 고객의 불만은 CS팀이 막아내는 수준에서 제공되는 것은 안타깝습니다.
기본적으로 고객과 서비스 간에 발생하는 문제는 제품의 영역입니다. 그것이 제품의 디자인이든, 기획이든, 개발한계이든간에 원칙적으로 제품이 감당하고 해결해야할 문제입니다. 여러가지 이유로 그 해결이 고객을 대면하는 CS부서로 넘어갈 수 밖에 없을 것입니다. 그리고 그런 상황은 상당히 꽤 자주 발생합니다. 이 상황을 대하는 PM의 자세는 어떠해야 할까에 대해서 생각해보자는 말로 오늘의 글을 마무리합니다.
Ps 1. 그리고 세특을 찾아보니, 나름의 confirmation process를 도입해두었네요. (예전에도 이 사진찍기는 존재했던 것 같습니다만)
Ps2. 간혹 회사에서, 특히 경영진 레벨로부터 어떤 종류의 불만들이 제품팀에 들어오기도 합니다. 보통은 지인 레벨에서 무엇이 불편하더라 같은 얘기를 전해듣고 우리 회사의 얼굴인 서비스가 이렇게 불편해서는 안된다, 그러므로 사용성 개선을 해야한다! 라는 식으로 과제가 할당됩니다. 사용성 개선 TF는 아마도 10년차 PM 정도라면 서너번은 경험해보셨을 겁니다. 항상 우선순위 최고에서 할당되고 거창하게 TF를 시작하지만 그 끝은 보통 몇개의 페이지에서 몇개의 오브제를 손대는 수준에 머무르곤 하죠. 물론 그렇게 해서 퍼널에서의 전환율(?)이 몇퍼센트 상승했다라는 리포트를 받아보는 경우도 있구요.
다시한번 나무그네 그림을 상기해봅시다.
Requirement를 파악하지 못해서, 시나리오와 유저스토리가 부족해서 발생하는 문제를 가독성이 부족하다거나, 버튼의 위치나 컬러가 나쁘다거나, 필드값이 과다하다는 수준의 사용성 개선으로 퉁 치고 있는 것은 아닐까요?
