스타트업은 무엇이든 부족한 상태가 기본값이다보니, 그들이 만드는 제품은 대부분 불완전하고 불편합니다. 그러다보니 대고객 서비스를 제공하는 경우에 CS(고객 지원 서비스)와 전쟁을 치를수 밖에 없게 됩니다. 그래서 어느 기업이 어떤 종류의 CS에 직면했다는 내용을 기사나 주변 분들의 소셜 매체 등을 통해서 보는 일도 잦고, 어느정도 감안하고 볼만한 여지가 있다고 생각하곤 합니다.
물론 이런 글을 쓰고 있는 저 자신이 프로불편러이다보니, 제품에 이런 부분이 비어있거나, 잘못 설계되어 있(다고 생각하)거나, 무언가 예상한대로 흘러가지 않을 때에 불편함을 거친 말로 적어내서 주변 분들을 당황시키는 일도 있어왔습니다. 그분들께 이 자리를 빌어 다시한번 죄송하다는 말씀드립니다.
본론으로 돌아와서, 저도 제품을 개발할 때에 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와 대화를 하면서 알게 된 사실은, 현재 제 패키지 상태가 어떤지 확인할 수 있는 메뉴가 없다는 것과 이 패키지 요금은 월 구독제가 아니라 30일 구독제라는 사실이었습니다. 그리고 카운트의 기준은 수거신청일이나 수거일이 아니라 수거 후 확정일이라는 것이죠. 그러니까 매월 15일이 결제일이라고 생각하고 보냈지만, 어느 달은 하루가 빨라져있고 몇 개월 지나면 여러 날이 당겨져 있습니다. 2월을 지나면 뒤로 밀려있기도 합니다. 그러니까 보낼 때마다 어느 정도의 gap을 감안하고 보내야만 하는 것이죠.
이 문제는 사용자의 습관을 제품 개발에 고려하지 않았기 때문에 발생했다고 생각했습니다. 게다가 패키지를 팔았는데 (READ) 조차도 구성되어 있지 않아서 이 문제를 CS에 떠넘기고 있다는 것에 대해 저는 제품으로써 문제 수준이 아니라 결격 사유라고 생각했습니다.
시간이 흐르고 나서, 아마도 구성원들이 열심히 노력하신 결과 CS가 몸빵을 때우는 사이에 월간 구독 패키지를 대체하는 세특패스라는 좀 더 일반적(?)인 월간 요금제가 발행되어 30일 구독제의 문제는 사라지게 되었습니다. 그동안 참으로 유능한 CS팀 구성원들은 이런 저런 불만을 쏟아내는 저에 대해서 때로는 얼르고 사과하고 보상을 쥐어줘가면서 이 문제를 운영해나가고 있었습니다.
헌옷수거는 돈이 되는 일인가요, CS만 늘어나는 일일까요?
제가 사는 산간오지가 드디어 런세권에 편입이 되었습니다. 런드리고의 문앞설치박스는 제 취향이 아니었지만, 세특과 비교해서 꼭 써보고 싶었던 서비스이기에 기쁜 마음으로 테스트를 해보았습니다. 개인적으로는 여러 측면에서 더 깔끔하고 정돈된 서비스를 제공한다는 느낌을 받았고, 딱 그만큼 좀 더 비싸다고 생각했습니다. 그러다가 헌옷수거 “킬로그램당 300포인트” 를 보고 어차피 버릴 헌옷이라고 생각하고 문앞에 차곡차곡 모아두기 시작했습니다.
런드리고 사례
헌옷수거를 신청해보면 아래와 같은 주의경고문구(부인방지문구)를 확인하실 수 있습니다. 이런 문구가 등장하는 배경은 당연히 이런 문제가 반복해서 발생했기 때문이겠지요. 이 글을 쓰게 된 계기이기도 합니다. 어떤 문제가 반복적으로 발생하고 여기에서 사용자의 귀책여부를 명확하게 하지 않을 수 없었을 것입니다. 그러니 CS부서/운영부서 혹은 법률부서에서는 이런 경고문구/부인방지 문구를 넣어야 한다는 요구사항이 도출되었을 수도 있습니다.
PM이 여기에서 이 문구 하나 넣고, Consent box 하나 추가하고 이 Requirement를 종료했다면 Product Manager로서 결격이라고 생각합니다. 어떤 요구사항이 발생했을때 그 표면의 요청사항만을 기계적으로 받아들인다면 아래 그림의 나무그네와 다를것이 뭐가 있을까요. 심지어 아래 나무그네 그림은 1989년에 출판된 도서에 포함되어 있었다는 사실을 잊지 맙시다. 35년 전이에요.
저는 이 Checkbox에 동의를 하고 미리 꺼내놓은 2개의 헌옷봉투에 파란 매직으로 “헌옷”이라고 써두었습니다. 그리고 몇시간 뒤 세탁물을 꺼내 놓으려고 밖을 나가보고 문제가 생겼다는 사실을 깨달았습니다. “헌옷” 2봉투가 사라졌어요. 그리고 하나는 헌옷으로 하나는 세탁물로 수거해갔다는 사실을 잠시 뒤에 알게 되었습니다.
그때부터 앱의 어떤 메뉴를 이용해도 이것이 잘못되었고, be about to 헌옷 중 한 봉투는 세탁이 될 것이며, 나에게 세탁비용을 청구하고, 또 CS와 지리멸렬하고 비생산적인 대화를 나눠야 할 제 모습이 떠오르기 시작했습니다. 그 스트레스로 불편한 글을 써질러버리는 바람에 다른 여러 분을 불편하게 해드렸던 부끄러운 일도 생겨버렸습니다.
사용자 시나리오에서 헌옷수거는 어떻게 다뤄져야 하는 것일까요? 헌옷수거는 과연 CS비용을 상쇄할만큼은 이익이 되는 것일까 MRD를 보고 싶기도 했습니다만, 제가 생각한 문제는 헌옷을 규정하는 confirmation process가 유저스토리에 존재하지 않고, "오수거" 케이스가 유저시나리오를 정의하는 과정에서 고려되지 않았기 때문이라고 생각했습니다. 높은 확률로 유저시나리오를 따로 정의하지 않았을 것이고, 그래서 유저스토리가 세부적으로 형성되지 않았을 것이며, 아마도 헌옷을 수거하는 스크린샷부터 시작해서 화면정의서가 바로 작성되고 피그마에서부터 제품과정이 시작되었을지도 모르겠습니다.
헌옷이 세탁물과 혼입되는 문제는 처음에는 누구라도 막기 힘들었을 수 있습니다. 내놓은 사용자도 혼선이 있을 수 있는데다가, 무언가 표기를 한다는 것은 생각보다 많은 준비와 노력을 요구하니까요. 그래서 문제는 당연히 발생하게 될텐데, 그 문제를 제품단에서 해결하는 대응이 그저 부인방지 문구를 넣고 책임을 전가하는 수준, 그리고 고객의 불만은 CS팀이 막아내는 수준에서 제공되는 것은 안타깝습니다.
마치며
기본적으로 고객과 서비스 간에 발생하는 문제는 제품의 영역입니다. 그것이 제품의 디자인이든, 기획이든, 개발한계이든간에 원칙적으로 제품이 감당하고 해결해야할 문제입니다. 여러가지 이유로 그 해결이 고객을 대면하는 CS부서로 넘어갈 수 밖에 없을 것입니다. 그리고 그런 상황은 상당히 꽤 자주 발생합니다. 이 상황을 대하는 PM의 자세는 어떠해야 할까, 에 대해서 생각해보자는 말로 오늘의 글을 마무리합니다.
콴 코치
대표파트너, PMF파트너스.
게임회사의 신사업기획에서부터 창업, 이후 삼성페이 Product Manager로 제품을 산출하면서 PM으로서 성장해왔습니다. 이후에도 뱅크샐러드, 야놀자에서 Product Owner / Project Management Office로 제품개발과정을 정립하기 위해 노력해 왔습니다. Product Market Fit을 중심으로 보는 초기투자(PMF인베스트먼트 개인투자조합)를 운영하고 있습니다.
목록으로