brunch

You can make anything
by writing

C.S.Lewis

by KitaiKeith Dec 04. 2019

세미나) 나는 오퍼레이터다 by 천세희님

스타트업에 존재하는 많은 잡부들을 위해서

회사에 CS 담당자분이 오셨다. 채널톡의 브런치를 보다가 천세희님의 오퍼레이터 워크북을 보고 공유해드렸더니, 나에게 세미나를 공유해주셨다. 감사하다. 지금 회사에서는 한화향 서비스를 담당하면서 하면서 CS 및 운영을 맡았다. 스위처에서는 말할 것도 없고.. 


천세희님은 CS, System, 정책 등등 회사가 원활하게 돌아갈 수 있게 다양한 업무를 하셨고, 지금도 하고 계신다고 한다. 그리고 스스로를 '잡부'라고 표현하셨다. (아마 초기 단계의 스타트업에서 CS, 마케팅 등을 담당하시는 분들은 다 공감하실 거라고 생각한다. 나 역시도 그렇고) 근데 그런 자신을 더 잘 표현하기 위해서 '오퍼레이터'란 단어를 사용하셨다고 하신다. 


자신의 경험담은 현재 채널톡의 브런치에 연재를 하고 계신다. 이 날 세미나에서 얘기해주신 내용 대부분은 브런치에 다 있다고 여러 번 말씀하셨다. 다녀와서 정리한 내용을 보고 관심이 있다면 워크북을 읽어보면 더 좋을 것 같다.

천세희의 오퍼레이터 워크북


시작-


먼저, 어떤 일을 했었는지

네이버, 배민, 맥도날드 등 다양한 곳에서 근무를 하셨다. 처음에는 대우증권에서 CS를 하시다가, 맥도날드, 네이버를 거치셨다고 한다. (실제 고객과의 대화를 주로 한 건 20년 전 대우증권이 마지막이었다.) 네이버에서는 CS를 구축하고, CS 운영은 아웃소싱에 맡기고 그곳을 관리하는 정도였다고 한다. CS에 대한 정책이나 admin page 개발, 이슈 관리를 주로 하셨다고 한다. 그러면서 PR도 조금 하게 되었었고, 마케팅, Sales도 좀 하셨는데.. 이렇게 많은 일을 했지만 그냥 CS로만 대표(정의)되는 게 억울하고, 그런 자신을 정의하기 위해서 오퍼레이터란 단어를 쓰기 시작하셨다고 한다.

�개인적으로, 천세희님이 말씀하시는 오퍼레이터는 CS와 떼려야 뗄 수 없는 관계인 것 같다. 회사 내부적인 문제를 제외하고 대부분 개선해야 하는 부분에 대한 근거는 고객에게서부터 오기 때문이다. 그렇기 때문에 천세희님도 A-bly 워크샵을 진행했을 때, 고객 문의를 다 까 보신 게 아닐까? (이 부분도 브런치 글에 있다고 하니까 읽어보면 좋을 것 같다.) 이는 흔히, lean startup에서 얘기하는 고객 중심적인 사고와 같은 맥락인 것 같다. 제품의 개선 사항은 우리가 생각하는 '좋은 것'이 아니라, 고객의 목소리에서부터 시작된다.


미션은 무엇인가?

Class 101는 현재 일 150건 정도의 문의가 들어온다고 한다. (초기 일 300건이었는데, 입사 이후 문의 건이 줄었다고 하셨다. 현재는 일 200건 아래) CS 담당자는 고객의 화를 몸으로 받아내는 사람. 근본적으로 이 CS를 0으로 만드는 걸 목표로 하신다고 한다. 생각을 해보자면, 어떤 서비스든 지 사용을 하다가 고객센터에 연락한다는 건 고객이 화가 나있는 상황. 이런 상황을 없애는 게 바로 미션. 고로, "우리의 존재 자체를 사용자가 모르게 하려고 한다!"


CS와 CX를 나눠서 생각해야 함!

CS는 고객이 우리에게 말을 걸 때 1차적으로 대응해주는 것이고, CX는 이 고객의 문제점을 근본적으로 해결할 수 있는 방법은 무엇일까? 추가되어야 하는 기능은 무엇일까? 를 고민하는 것이다.

한�화향 때를 생각해보면, "중학생 이상은 사용이 어렵다. 더 큰 칫솔모는 없는가"라는 문의가 들어왔을 때 "네 현재는 준비되지 않았습니다."는 CS. 중학생 이상의 사용자의 사용성을 높이기 위해선 어떻게 hooking 할 수 있는가, 지금 가지고 있는 기능(미연동 데이터)을 이용해서 사용자가 받을 수 있는 혜택은 무엇인가?를 고민하는 건 CX.라고 생각한다.

이러한 사고의 시작은 데이터에서 시작한다.(위에서 얘기한 고객 문의를 깐다. 와 결이 맞는) 그리고 데이터를 볼 땐 절대적인 수치만 보는 게 아니라, 회사의 규모를 함께 봐야 함. 예를 들어, 150건의 문의가 class101에 들어오는 것과 배달의 민족에 들어온다는 건 다르다. 사용자(트래픽) 자체가 다른데, 어떻게 같다고 정의할 수 있겠는가? 그래서 데이터를 볼 때 MAU, DAU(=주문건, 트래픽)과 함께 봐야 한다.

�지금 자사향 데이터를 보기 전에, 어떤 데이터와 조합을 해야 하는가? 고민을 많이 하고 있다. 일반적으로 사용하는 DAU를 따라갈 것 인가? 아니면 앱 내 '양치하기 버튼을 누른 전체 횟수'를 봐야 하는가? 아니면 '하루 1회 양치하기를 누른 사람들의 수'를 봐야 할 것인가? 우리에게 딱 맞는 데이터를 봐야 할 것이다. CS를 예로 든다면, '앱 다운로드 수' 대비가 아니라 '칫솔 출고량' 대비로 계산을 해야 하듯.

또한, 주요 문의 유형과 취소, 중복 문의 역시 정리하고 함께 볼 필요가 있다. 이를 통해서, 비교할 수 있는 대상을 정할 수 있고 정량적으로 판단할 수 있는 기준을 만들 수 있기 때문. 그리고 이런 데이터는 어느 정도의 모수가 쌓인 상태에서 볼 수 있다.


취소율과 관련된 배민에서의 사례.

당시 주문 취소가 빈번히 업주(가게)에서 생겨났다고 한다. 당시만 해도 아직 음식배달업 자체가 활발하지 않았고 배민도 국민앱까지는 아니다 보니 업주는 배달 주문과 홀(식당) 두 가지 모두 신경을 써야 하는 상황이었다. 그러다 보니, 홀(식당)에 고객이 많으면 업주는 자연스레 배달 주문을 취소할 수밖에 없었다고 한다. 그러다 홀(식당)에 사람이 없으면 전화주문을 잘 응대해주고.. 배달 주문 고객 입장에서는 당연히 불쾌할 수밖에 없는 상황이 발생하다 보니 자연스레 이탈률이 높아지게 된다.

이 문제를 해결하기 위해서, 개발자에게 데이터를 요청해서 몇 가지 데이터를 보고 조치를 하나씩 시작하였다고 합니다.   

    1. 주문 취소한 업체를 list-up

    2. 주문 취소 사유를 정리하여서 카테고리화

    3. 카테고리 및 상황별 조치에 들어감 ex) 취소 사유가 '재료 소진' 일 경우 해당 업체는 그 날 배민앱 list에서         숨김. ex) 1시간 내 취소가 2건인 경우 역시 배민앱 list에서 삭제 (홀이 바쁘단 소리니까)

    4. 업주에게는 전화를 해서 각 상황에 대한 설명을 해줌. (이러이러한 이류로 리스트에서 제외했다.)

    5. 주문 배달 관리를 잘하는(취소를 하지 않는) 업주에겐 앱에 우수 업소 배지를 달아줌. → 우수 업소 배지를         단 업체는 자연스럽게 장사가 잘 되고, 또 이게 업주들 사이에서 자연스럽게 바이럴 됨.

    7. 사람들이 자연스레 관리를 하기 시작함.

    8. 그래서 아카데미를 열어서 사장님들한테 교육을 시켜드림.

    9. 그러다가, 시상식 같은 걸 해서 상도 드림. (얼싸안고 울음.)

이러한 과정을 통해서 초기 14% 였던 취소율을 4%까지 낮췄다고 합니다. 4년 동안 위 단계들을 하나씩 lean 하게 진행했습니다. 거창하게 큰 기획안을 내놓는 게 아니라, 분석→가설→실험→검증을 꾸준히 반복한 거죠.

�개인적으로 lean 한 업무 방식을 좋아합니다. 지난 회사에서 경험했던 문화에 영향을 많이 받은 것도 있지만, 어찌 되었든 water-fall과 agile 한 방식을 비교했을 때 '위험성이 적다.' '유연하다.' '빠르게 결과를 예측할 수 있다.' 등 이런 점이 저는 매력적이라고 생각했습니다.

문제정의부터 과제화까지

대부분의 사람들이 공감할 수 있는 내용인데, 단순히 문제를 문제로 끝내는 게 아니라 수면 위로 올려서 해결할 수 있게 해야 한다. 그런 과정을 천세희님은 문제정의 → 수치화 → 과제화라고 표현하셨다.  위 사례를 되돌아보면,   

    - 문제정의 : 취소

    - 수치화 : 취소율

    - 과제화 : reasonable 한 목표를 설정

가 되는 것이다. '취소'라는 문제가 어느 정도로 서비스에 영향을 끼치는지, 또 그걸 어느 정도 수준으로 해결해야 하는지, 마지막으로 실제 행동까지 해야 한다는 거다. 달성 가능한 목표를 수치화할 때, 그 가능성은 70% 정도라고 얘기해주셨다.

�OKR에서도 보면 목표를 잡고 실제 그 목표를 달성하는 수치는 60-70%라고 얘기했는데, 천세희님도 그 정도 수치가 적당하다고 생각하셨으니까 언급한 게 아닐까?

그리고 이걸 KPI로

세미나에서는 챕터를 나눈(?) 느낌이었는데, 결이 같다고 생각해서 난 그냥 정리한다.

아무튼, "이거 안돼요!", "이거 컴플레인이 많아요." 이렇게 얘기하고 끝내는 게 아니라 과제화(실제 업무로) 해줘야 한다는 거다. 천세 희님 왈 "일을 계속하는데, 책상에 쓰레기가 쌓이면 지치는 것처럼 오퍼레이터가 책상에 있는 쓰레기를 치워주고 카테고리를 나눠 줘야 합니다"라고 하셨다. 이게 오퍼레이터가 잘해야 하는 일 중 하나라고 공감한다.

a�dmin page에 들어가야 할 기능은 어떤 게 있을까? 누구를 위해서 admin page는 존재할까? CS 중 데이터와 관련된 부분은 자연스레 개발자에게 업무가 간다. 이게 바로 책상에 쌓이는 먼지가 아닐까 싶다. 그렇다고 매일 먼지를 쓸기 위한 일만 해서도 안될 거 같다. 그게 일을 위한 일을 하는 것과 같다고 생각한다.




마무리와 QnA

위 내용들은 천세희님이 정의한 오퍼레이터의 많은 업무 중 몇 가지만 예시로 본 것이다. 본인이 하는 일을 의미 없는 일이라고 생각하지 말 것. 그리고 회사에서 의미 있는 일만 주는 것도 아니다. 꼭 해야만 하는 일이 있을 것이다. 그 일을 의미 있게 만들어 가는 건 나고 항상 수치화, 과제화를 통해 팀원들과 협업하면서 좋은 비즈니스로 이끌어 가면 되지 않을까?라고 마무리 멘트를 남기셨다.

�가장 인상적이었던 부분이다. 결국 "어떤 마인드로 업무를 해야 하는가?"인 것 같다. 일을 하다 보면 해야 할 일과 하고 싶은 일이 상반되는 경우가 많다. 두 가지가 같은 결이라면 다행이지만 그런 경우는 거의 없다. 그게 잘 된다고 해도 함께 일하는 사람들에게 설명하고, 이해시키고, 설득하는 과정도 만만치 않다. 이럴 때마다 '현타'가 오곤 하는데 이때마다 포기하지 않고 좋은 비즈니스를 위해 좋은 선택을 내리는 태도가 가장 중요한 것 같다. 그리고, 내가 발의한 업무에 대해 방관하는 게 아니라 끝까지 책임지고 눈이 보이는 task로 만들고 마무리 짓는 태도 역시 잊지 말아야겠지..

다양한 QnA가 오고 갔는데, 그냥 제 기준으로 필요한 것만 기록을 하였습니다.


Q1. 고객 관리를 하면서 특이사항은 어떻게 관리 하나요?   

A. 고객 문의는 사실 본인의 케파(CAPACITY)만큼 보입니다. 그래서 일단 저는 무조건 고객 문의를 다 깝니다. 그래서 다 보면서 어떤 상황인지 파악을 합니다. 그리고 사실 고객 문의에 카테고리(filter)를 최대한 많이 만들게끔 합니다. 왜냐면 이게 되지 않으면 분석을 할 때 너무 시간이 오래 걸려요. 반대로 실무자(CS 담당자)는 힘들겠죠. (왜냐면 기록할 때마다 그 많은 카테고리(filter)를 다 기록해야 하니까.) 고로, 보는 사람이 편하게끔 최대한 정리를 세부적으로 하는 게 좋은 것 같습니다.


Q2. 온라인이 아닌 오프라인(공간 관련 회사)은 고객 관리를 어떻게 하면 좋을까요?   

A. 별 차이가 없는 것 같습니다. 저번에 코워킹 스페이스 서비스를 고문해줬는데 고민하는 부분도 비슷했다. 공간이 콘텐츠이고, (온라인) 커뮤니티여서 결국 같은 결인 것 같습니다. 고객의 문제를 해결해주면 됩니다.


Q3. 이슈 매니지먼트의 노하우는?   

A. 예측 가능한 이슈를 나열하고, 그런 이슈들을 편하게 얘기할 수 있는 분위기를 만들어야 합니다. 흔하게 하는 고민 중 하나가 "말할까? 말까?"인데, 이때 무조건 말하게끔 해야 합니다. 또한, 말을 어디에/누구에게/해결방법에 대해서 명확하게 정리를 해줘야 합니다. (calss 101에는 slack에 삐융 삐융이 있어서 앞서 얘기한 것과 관련된 부분이 있으면 자동으로 bot이 대답을 해준다고 함. 어떤 건 누가 담당이고, 저건 누가 담당인지)


Q4. SNS에 불만이 올라오면?   

올라온다는 거 자체가 사실문제다. 가령 서비스가 이커머스다. 그러면 애초에 거기서 문의가 끝났어야 하는데, 그러지 못한 것. 24시간 내에 문제 접수부터 응대, 해결까지 모든 걸 끝내야 한다.


Q4. 오퍼레이터가 겪는 문제는 무엇일까? 어떤 역량을 키워야 할까?   

A. 예전엔 나 스스로도 되게 쓸모 있는 사람임을 증명하고 싶었던 생각이 컸다. 그래서 일을 되게 열심히 했고, 힙한 거 핫한 걸 하려고 한다. 근데 지금은 회사를 위해서 어떤 일을 해야 하는가?를 고민하고 있다고 한다. 그리고 오퍼레이터가 하려고 하는 일은 팀원이 싫어하는 일이다. 개발자든 디자이너든 원래 하려고 하는 일이 아니라 치고 들어오는 일이 대부분이다. 그러다 보니, 이 일을 진행하고 성공시키기 위해선 커뮤니케이션 능력! 모든 직 문의 사람들이 좋아하게끔 해야 하는 역할이다. 아무도 먼저 하기 싫어하는 프로젝트를 시작하는 사람. 그리고 그 일을 같이 하게끔, 나 자신이 매력적인, "이 사람이랑 같이 일하고 싶다."는 생각이 들게끔 하는 사람이 되어야 한다.


Q5. 오퍼레이터를 하면서 가장 중요한 것은?   

A. Due date 맞추는걸 꼭 하자! 안되는 건데 굳이 거짓말할 필요도 없다. 일정에 대해서는 솔직하게 얘기해야 한다. 그리고 항상 정보를 공유해야 한다. 메일이던 미팅이던 항상 공유할 수 있어야 한다.

A. 위랑 다른 얘기이긴 한데, 회사 생활하면서 자신이 생각하는 업무가 부러지거나 거절되는 건 당연한 일이다. 그래도 포기하지 않고 계속 시도해야 한다. 다만, 그때마다 상대의 성향을 파악해서 A방법이 거절당했으면 B방법으로 해보고, 까이면 또 C로 해보고 계속 이렇게 해야 한다.


작가의 이전글 휴리스틱 평가를 완벽히 수행하기 위한 10가지
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari