CS가 탁월하면 프로덕트가 무능해진다

스타트업은 항상 무언가 모든 것의 부족이 기본값이다 보니 그들이 만드는 제품은 대부분 불완전하고 불편합니다. 그러다 보면, 특히 대고객 서비스를 제공하는 경우에는 항상 CS와의 전쟁을 치를 수밖에 없게 됩니다. 그래서 어느 기업이 어떤 종류의 CS 문제에 직면했다는 내용을 기사나 주변 분들의 SNS 등을 통해서 보는 일도 잦습니다. 어느 정도 감안하고 볼만한 여지가 있다고 생각하곤 합니다.

물론 이런 글을 쓰고 있는 저 자신이 누구보다도 프로불편러이다 보니, 제품에 이런 부분이 비어 있거나, 잘못 설계되어 있(다고 생각하)거나, 무언가 예상한 대로 흘러가지 않을 때면 불편함을 거친 말로 적어내서 주변 분들을 당황하게 하는 일도 왕왕 있어 왔습니다. (그분들에게도 이 자리를 빌어 다시 한번 죄송하다는 말씀드립니다.)

변명을 덧붙이자면 저는 보통 제품 내에서 사용자의 메인 시나리오(main scenario)를 잘못 설계했다고 생각할 때, 또는 유저 스토리(User Story)에 문제가 있다고 생각할 때 글을 쏟아내는 편입니다. 그렇게 쓰는 기저에는 분명히 시나리오나 유저 스토리가 없었다는 확신을 가지기 때문이기도 합니다.

본론으로 돌아와서, 저도 제품을 개발할 때에 메인 시나리오를 설계하고 여기에서 벗어나는 일부 상황들에 대해 “CS로 처리하자”라고 쉽게 말하기도 합니다. 담당하는 CS 부서에서야 쉽지 않은 일이겠지만, 전체의 1~2% 수준일 것 같은 케이스를 모두 제품 안에 처음부터 구현해 내는 것은 상대적으로 과도한 비용을 지불해야 하기 때문입니다. 또 무엇보다 이 제품이 어디로 흘러갈지 알 수 없는 상황에서 서브 시나리오(sub scenario)도 아닌 모든 경우의 수를 감안할 수는 없기 때문이기도 합니다.

하지만 이렇게 한번 잡아놓고 나면, ‘나중에 개선할 거야’라는 다짐 따위는 무색하게 계속 또 다른 무언가를 쫓기듯 해야 합니다. 곧 이런 마이너 케이스(minor case)에 대응하는 일들은 계속 CS의 부담으로 남아버리고는 합니다. CS가 버티지 못하고 박살이 난다면 모를까, 그분들의 능력과 헌신으로 문제를 꾸역꾸역 잘 막아내기 시작하면 이 상황은 영원히 지속될지도 모릅니다. 그래서 오늘의 글감을 정했습니다.

“CS가 탁월하면 프로덕트(product)가 무능해진다.”

‘게을러진다’라는 표현이 좋을지 잠깐 고민을 했었습니다만, 총체적인 상태로는 무능이 더 어울릴 것 같습니다.

유능한 프로덕트는 무엇일까요?

반대의 개념이나 입장에서 유능한 프로덕트(Product)란 무엇일까요? 제품의 에픽 유저 스토리(Epic-User Story)를 설계하는 과정에서 ‘여기서부터 여기까지는 메인 시나리오로, 저기까지는 서브 시나리오로 처리’하고, 이 바깥의 어느 범위는 CS로 처리하자 라고 결정했을 때, 그 CS가 메인/서브를 침범해 들어오지 않는다면 유능한 프로덕트라고 할 수 있을 것입니다. “고객의 신박함, 새로움과 다양함은 안 겪어본 사람이 이해할 수 없다”라고도 말을 합니다만, 그럼에도 불구 CS팀이 높은 확률로 한정된 케이스만 대응할 수 있도록 해준다면 분명 유능한 제품이라고 할 수 있겠습니다.

반대로 무능한 제품이라고 한다면, 메인 시나리오에서 CS가 발생하는 것을 들 수 있겠습니다. 이렇게 되면 1~2%에 대한 CS가 아니라 70~80%를 대상으로 CS가 발생할 위험에 노출됩니다. 이제부터 CS팀은 사실상 운영의 역할에 참여해 들어오게 됩니다. 이 상황이 반복되면 CS팀을 위한 전문적인 툴을 만들어야 할 필요가 생겨 버립니다. 그리고 CS팀 구성원들이 헌신적으로 이 문제들을 처리하고 대응해 내기 시작하면 이제 그것이 뉴 노멀이 됩니다. 제품 팀은 CS팀의 CS 처리를 위한 운영 툴을 만들고 유지보수하는 요구사항(Requirement)을 수립하고 대응하고 있게 될 것입니다.

월 구독제가 아니라 30일 구독제라고요?

크리티컬한 사항은 아니었다지만, 제가 최근에 경험했던 한 가지 사례를 가지고 이 사안을 설명해 보려고 합니다. 부득불 등장하는 두 기업에는 죄송하다는 말씀 미리 전합니다. 저는 두 기업의 서비스를 여전히 잘 사용하고 있습니다.

제가 사는 동네는 꽤 산간오지에 해당합니다. 그래서 배달의민족으로 배달을 시키면 항상 판매자가 취소를 때리곤 하는 곳입니다. 요새는 좀 세상이 좋아져서 주문 품목에 저희 동네 배송료 상품이 붙어 있는 경우가 있긴 합니다만, 그런 곳이다 보니 세탁 서비스들로부터는 오랫동안 외면받아 왔습니다.

한때 리화이트를 통해서 동네 세탁소를 이용하기도 했었지만 불편함이 없었던 것은 아니다 보니, 세탁특공대가 처음으로 오픈했을 때 아주 감사한 마음으로 이용을 했습니다. 그런 세특에서 월간결제 패키지를 출시했기에 저는 침구류 패키지를 구독했습니다. 할인 폭이 커 사실 한두 번쯤 이용을 건너뛰어도 별다른 손해는 아니긴 했지만, 그래도 사람 마음이 그렇지 않죠. 그래서 매월 특정 시점이 되었을때에는 꼭 침구류 세탁을 보내곤 했습니다.

(세탁 서비스 관련 CS는 압도적으로 세탁 품질에 관한 얘기가 많습니다만, 이 부분은 워낙 발생할 케이스가 다채롭고 또 개연성도 다양하다 보니 제게 문제가 되는 부분은 아니었습니다.)

제게 닥친 문제는 이러했습니다. 분명 패키지 결제라고 보냈는데, 일반 결제가 발생하였습니다. CS와 대화를 하면서 알게 된 사실은 ‘현재 나의 패키지 상태가 어떤지 확인할 수 있는 메뉴가 없다는 것’과 (카카오톡으로 문의하면 남은 회수를 알려준다고 합니다) ‘이 패키지 요금은 월 구독제가 아니라 30일 구독제’라는 사실이었습니다. 또, ‘카운트의 기준은 수거신청일이나 수거일이 아니라 수거 후 확정일’이라는 것이죠.

그러니까 매월 15일이 결제일이라고 생각하고 침구류를 보냈지만, 어느 달은 하루가 빨라져 있고 몇 개월 지나면 여러 날이 당겨져 있었습니다. 심지어 2월을 지나면 뒤로 밀려 있기도 합니다. 그러니까 보낼 때마다 어느 정도 갭을 감안하고 보내야만 하는 것이죠.

이 문제는 사용자의 습관을 제품 개발 시에 고려하지 않았기 때문에 발생했다고 생각했습니다. 게다가 패키지를 팔았는데 READ조차도 구성되어 있지 않아서 이 문제를 CS에 떠넘기고 있다는 것, 이 점은 제품의 문제 수준이 아니라 그냥 ‘결격사유’라고 생각했습니다.

얼마의 시간이 흐르고 나서, 아마도 구성원들이 열심히 노력하신 결과, CS가 몸빵을 때우는 사이에 월간구독패키지를 대체하는 세특패스라는 좀 더 일반적(?)인 월간요금제가 발행되었습니다. 곧 30일 구독제의 문제는 사라지게 되었습니다.

그동안 참으로 유능한 CS팀 구성원들은 이런저런 불만을 쏟아내는 저를 어르고, 사과하고, 때로는 보상을 쥐여줘 가면서 문제를 해결해 나가고 있었습니다. (이번은 ‘특별히 이렇게 처리해 드리겠습니다!’ 하고 몇 개월 뒤 다시 반복되는 기시감도 있었지만요.)

참고로 저는 세특패스를 일정 기간 구독하다가 또 무엇인가 잘 기억나지 않는 사유로 이탈한 상태입니다. 사람이 이렇습니다. 막상 그때는 그것 때문에 해지했으면서도 얼마 지나면 기억도 없네요.

헌 옷 수거는 돈이 되는 일인가요, CS만 늘어나는 일인가요?

제가 사는 산간오지가 드디어 런세권에 편입이 되었을 때입니다. 런드리고의 문앞설치박스는 제 취향은 아니었지만, 세특과 비교해 꼭 써보고 싶었던 서비스이기에 기쁜 마음으로 테스트를 해보았습니다. 개인적으로는 여러 측면에서 더 깔끔하고 정돈된 서비스를 제공한다는 느낌을 받았고, 딱 그만큼 좀 더 비싸다는 생각을 했습니다.

그러다가 헌 옷 수거 “킬로그램당 300포인트”를 앱에서 보고, 어차피 버릴 헌 옷들을 문 앞에 차곡차곡 모아두기 시작했습니다. (참고로 헌 옷 수거는 세특도 제공하는 서비스이고 한 두 번 이용한 경험이 있었습니다.)

헌 옷 수거를 신청해 보면, 이미지와 같은 경고 문구(부인방지 문구)를 확인할 수 있습니다. 이런 문구가 등장한 배경은, 당연히 이런 문제가 반복적으로 발생했기 때문이겠지요. 이 글을 쓰게 된 계기이기도 합니다.

어떤 문제가 반복적으로 발생하면 여기에서 사용자의 귀책 여부를 명확히 하지 않을 수 없었을 것입니다. 그러니 CS 부서/운영 부서 혹은 법률 부서에서는 이런 경고 문구/부인방지 문구를 넣어야 한다는 요구사항이 도출되었을 수도 있습니다.

만약 PM이 여기에서 ‘이 문구 하나 넣고, consent box 하나 추가하고 이 Requirement를 종료’했다면 프로덕트 매니저로서 결격이라고 생각합니다. 어떤 요구사항이 발생했을 때, 그 표면의 요청 사항만을 기계적으로 받아들인다면 아래 그림의 나무 그네와 다를 것이 뭐가 있을까요. 아래 나무 그네 그림은 심지어 1989년 출판된 도서에 포함되어 있었다는 사실을 잊지 맙시다. 35년 전이에요.

저는 이 체크박스에 동의를 하고 미리 꺼내 놓은 2개의 헌 옷 봉투에 파란 매직으로 “헌 옷” 이라고 써두었습니다. 그리고 몇 시간 뒤 세탁물을 꺼내놓으려고 밖에 나갔다, 문제가 생겼다는 사실을 깨달았습니다. “헌 옷” 2봉투가 사라진 것이었죠. 심지어 하나는 헌 옷으로, 하나는 세탁물로 수거해 갔다는 사실을 잠시 뒤에 알게 되었습니다. (수거 예정 시간인 22시보다 2시간 빠른 20시에 벌어진 일이었지만, 이 문제는 수거 시간의 문제는 아니라고 생각합니다. 그러나 안타깝게도 "반드시 22시 이후 수거"라는 가이드가 수거팀에게 추가된 것 같습니다.)

그때부터 앱의 어떤 메뉴를 이용해도 이것이 잘못되었고, be about to 헌 옷 중 한 봉투는 세탁이 될 것이며, 나에게 세탁 비용이 청구되고, 또 CS와 지리멸렬하고 비생산적인 대화를 나눌 제 모습이 떠오르기 시작했습니다. 그 스트레스로 불편한 글을 써 질러버리는 바람에 다른 여러분을 불편하게 해드렸던 부끄러운 일도 생겨버렸습니다.

사용자 시나리오에서 헌 옷 수거는 어떻게 다뤄져야 하는 것일까요? 헌 옷 수거는 과연 CS 비용을 상쇄할 만큼은 이익이 되는 것일까 MRD를 보고 싶기도 했습니다만, 문제의 진짜 이유는 헌 옷을 규정하는 컨펌 프로세스(confirmation process)가 유저 스토리에 존재하지 않았으며, “오수거” 케이스가 유저 시나리오를 정의하는 과정에서 고려되지 않았기 때문이라고 생각했습니다.

높은 확률로 유저 시나리오를 따로 정의하지 않았을 것이고, 그래서 유저 스토리가 세부적으로 형성되지 않았을 것이며, 아마도 헌 옷을 수거하는 스크린샷부터 시작해 화면정의서가 바로 작성되어, 피그마에서 제품 개발 과정이 시작되었을지도 모르겠다, 그런 생각이 들었습니다.

헌 옷이 세탁물과 혼입되는 문제를 처음에는 누구라도 막기 힘들었을 수 있습니다. 내놓은 사용자도 혼선이 있을 수 있는 데다가, 무언가 표기를 한다는 것은 생각보다 많은 준비성과 노력을 요구하니까요. 그래서 문제는 당연히 발생하게 되겠죠. 다만 그 문제를 해결하는 대응 제품이 그저 부인방지 문구를 넣고 책임을 전가하는 수준, 그리고 고객의 불만은 CS팀이 막아내는 수준에서 제공되는 것은 안타깝습니다.

마치며

기본적으로 고객과 서비스 간에 발생하는 문제는 제품의 영역입니다. 그것이 제품의 디자인이든, 기획이든, 개발의 한계이든 원칙적으로 제품이 감당하고 해결해야 할 문제입니다.

현실에서는 여러 가지 이유로 그 해결이 고객을 대면하는 CS 부서로 넘어갈 수밖에 없을 것입니다. 그리고 그런 상황은 상당히, 꽤, 자주, 발생합니다. “이 상황을 대하는 PM의 자세는 어떠해야 할까에 대해서 생각해보자”는 말로 오늘의 글을 마무리합니다.

PS. 1) 세특의 헌옷수거를 찾아보니, 나름의 컨펌 프로세스를 도입해 두었네요. (다만 예전에도 이 사진 찍기는 존재했던 것 같습니다.)

P.S. 2) 간혹 회사에서, 특히 경영진 레벨로부터 어떤 종류의 불만이 제품 팀에 들어오기도 합니다. 보통은 지인 레벨에서 ‘무엇이 불편하더라’ 같은 얘기를 전해 듣고 “우리 회사의 얼굴인 서비스가 이렇게 불편해서는 안 된다, 그러므로 사용성 개선을 해야 한다!”라는 식으로 과제가 할당됩니다.

사용성 개선 TF는 아마도 10년 차 PM이라면 서너 번 정도는 경험해 봤을 겁니다. 항상 우선순위 최고 레벨로 할당되고 거창하게 TF를 시작하지만, 그 끝은 보통 몇 개 페이지에서 몇 개 오브제를 손대는 수준에 머무르고는 하죠. 물론 그렇게 퍼널 전환율(?)이 몇 퍼센트 상승했다는 리포트를 받아보는 경우도 있고요.

다시 한번 나무 그네 그림을 상기해 봅시다. 요구사항을 파악하지 못해서, 시나리오와 유저 스토리가 부족해서 발생하는 문제를 “가독성이 부족하다”거나, “버튼의 위치나 컬러가 나쁘다”거나, “필드 값이 과다하다” 수준의 사용성 개선으로 퉁 치고 있는 것은 아닐까요?

<원문>

CS가 탁월하면 Product가 무능해진다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.