이 글은 왓챠 공식 블로그에 실린 아래 글과 동일한 내용을 담고있습니다.
Medium
이 글은 왓챠 프론트엔드팀에 속한 저와 CS팀 dave, green이 함께 작성한 글입니다. 프론트엔드 개발자로서 CS팀과 협업했던 경험이 주된 내용이며 단락 별로 CS팀 dave와 green의 이야기가 담겨있습니다. 짧은 기간 동안의 협업을 바라보는 개발자의 시선과 CS팀의 시선을 엿볼 수 있습니다.
👉🏼 입사 1개월차
내 신경은 오로지 내 모니터 속 따라가야 할 팀원들의 소스코드, 그리고 담당한 제품이다. 간혹 코드에 버그라도 심어 배포되는 날에는 1, 2시간은 식은땀으로 훌쩍 흘려보내기 일쑤다. 조금 여유가 되는 날에는 이런 기능을 넣어보고 싶다, 이것보다 더 나은 UX여야 할 것 같은데? 라는 고민을 조금은 한다. 퇴근하려는 길에는 꽤나 많은 사람들이 자리에 남아 야근을 준비한다. 무슨 일을 하고 있을까 궁금하지만 이내 내 할 일이나 잘하자고 마음을 잡는다.
👉🏼 입사 2개월차
점심을 먹는 중에 동료 그린이 팔목 보호대를 차고 있다. 알고 보니 CS 팀이다. 작년에 고생했던 경험이 떠올라 이런 보호대, 이런 마우스가 좋더라라는 말을 건네보았다.
빨리 처리해야 하는데 마우스 쓰면 느려져서.. ㅜㅜ
일보단 몸이 우선일텐데… 내가 생각하는 CS팀은 다양한 인간군상을 접하면서 매일 반복되는 업무로 인한 정신 노동이 매우 힘든 곳이다. 근데 팔목이 아파도 일이 느려져서 마우스를 못 쓰겠다는 말에 약간의 충격 그리고 호기심이 생긴다. 무슨 일을 어떻게 하는 곳일까.
👉🏼 입사 3개월차
팀원들과의 협업도 어느 정도 적응하고 최근 급한 일정에 따른 개발 사이클도 한번 휘몰아쳐 조금은 여유가 생겼다. 그간 잠시 놓아두고 있던 제품 개선에 대한 생각을 하다 회사 슬랙에서 cs-mail 채널을 발견했다. 보니 CS로 들어오는 메일을 포워딩해서 모든 직원이 쉽게 열람할 수 있도록 만들어둔 것 같다. 대부분이 결제/환불 관련된 메일들이지만 제품에 대한 의견, 버그 리포트, 간간히 섞인 욕설들도 보인다. 아 꽤 자주 보이네.
👉🏼 입사 4개월차
결제와 관련된 변경사항에 외부 일정에 쫓겨 어쩔 수 없이 개발 완료일을 정해놓고 며칠 간 야근이 이어진다. 그간 익숙해진 얼굴 덕에 이제는 누가 남았고 무슨 일 때문에 남았는지 대부분 알 것 같다. CS팀 역시나 남았고 2개월차에 만났던 그린의 팔목에 보호대는 없지만 여전하고 꾸준하게 야근 중이다. 그 때 느꼈던 CS팀에 대한 호기심에 이끌려 다음 날 CS팀에 구경을 가봐야겠다고 생각했다. cs-mail 채널에서 간접적으로 느꼈던 분위기를 CS팀으로부터 직접 느껴보기도 하고.
👉🏼 이렇게 5개월째 접어드니
입사 후 서비스 개발자로서 CS팀이 하는 일에 관심을 갖게 된 이유는 두 가지다.
- 제품의 질을 높이자: 제품의 질은 좋고 멋진 기능 이전에 기본과 디테일에 있다. 내가 놓친 기본과 디테일은 사용자들이 제일 잘 알 것이다.
- 일정에 쫓겨 야근하는 개발팀 vs 매일 야근하는 CS팀: 이 차이는 무엇일까?
🤯 dave & 🤪 green:
왓챠&왓챠플레이 서비스의 CS프로세스를 구축하며 여러 비효율적인 부분을 개선하고, CS퀄리티를 높이고자 많은 노력을 했어요. 크고 작은 변화를 겪으며 효율은 높아졌지만, 고객수는 더욱 증가했고 그만큼 개선을 위해 투자할 수 있는 시간은 줄어들었어요. 익숙함을 벗어던질 획기적인 변화가 필요한 순간이었습니다.
CS팀이 생각하는 왓챠의 CS란?
🤯 dave:
고객만족, 고객행복이라는 단어는 꽤 익숙해요. CS팀의 역할은 무엇일까요? CS가 고객을 행복하게 만들 수 있을까요?고객만족/행복은 제품의 서비스가 고객의 니즈와 일치하거나 기대를 뛰어 넘을 때 발생해요. 그렇기 때문에 만족과 행복은 제품을 통해서 전달해야 한다고 생각해요. 다만 모든 고객의 니즈를 충족할 수 있는 서비스는 없기에 고객 불만은 생길 수밖에 없고 이때 발생하는 불만을 CS에서 얼마나 잘 축소하고 해결하는지가 왓챠 CS의 중요한 KPI입니다.여기서 말하는 불만은 단순히 서비스에 대한 불편뿐만이 아니에요. 제품 내에서 해결되지 않는 의문, 오해 혹은 고객이 제품을 이용하는 데 원활하지 못한 모든 것들도 불만에 포함되어요.즉 CS의 목표는 고객의 이런 불만을 축소하고 해결하여 온전히 제품을 사용할 수 있도록 하는 거예요. CS에서 제대로 통제할 수 없는 고객만족과 행복을 목표로 지향하다 보면 자연스럽게 불필요한 과잉 친절과 서비스를 하게 되고 장기적으로 CS팀의 생산성 저하나 제품단에 불필요한 부하를 줄 수도 있어요. CS는 고객이 제품을 이용하면서 길을 잃지 않도록 안내하고, 이를 위해 때때로 곳곳에 이정표를 세워 둬야 한다고 생각합니다.그럼 CS팀의 미션은 무엇일까요?CS팀의 미션은 고객들의 불만의 최소화 및 해소를 통해 온전히 제품(서비스)에 집중할 수 있도록 하는 것이에요. 고객만족, 고객행복과 같은 신기루가 아닌 명확한 방향과 목표를 갖고 이를 팀 내에서 명확하게 공유하는 것이 중요하다고 생각합니다.🤪 green:
CS는 본래 Customer Satisfaction이라는 뜻을 가지고 있지만 저는 Core Section이라고 재해석해요. 어떤 운동이든 코어 운동이 중요하게 여겨지는데, 이유는 코어 부위가 단단해야 어떤 동작을 하든 몸이 흐트러지지 않거든요. 마찬가지로 CS팀은 고객들과의 커뮤니케이션에서도 그리고 같이 일하는 직원들과의 관계에서도 코어 운동의 역할만큼 매우 중요해요.제품이 아무리 좋아도 상담에서 실망을 하는 고객은 언제나 떠나기 쉽고, 제품에 장애나 버그가 있더라도 만족스러운 답변을 경험한 고객은 언제든지 다시 돌아올 수 있어요.CS채널을 통해 많은 고객들로부터 다양한 의견이 들어와요. 모든 의견이 중요하지만 이 의견들을 현재 회사의 상황에 맞춰 잘 분류하고 시기적절하게 직원들에게 전달하는 역할을 해요. 이러한 신뢰 속에 다른 팀에서는 CS팀에서 전달하는 고객들 의견을 우선 순위가 높다고 믿고 최대한 빨리 해결하기 위해 노력해요.즉 제품을 실제 사용하는 고객들과 제품을 만드는 왓챠의 모든 팀 사이에서 CS팀은 매우 중요한 역할을 하고 있어요.
CS팀과 협업하기
CS팀과 진행했던 작업은 총 세가지 일로 나눌 수 있다.
- 매번 단순 반복되는 일을 코드로 자동화하기
- 자주 활용하는 관리자 기능을 개선하여 업무 프로세스를 보다 효율적으로 만들기
- 제품을 개선하여 정량적인 CS 업무량 줄이기
입사한 지 얼마 되지 않았고 아무래도 프론트엔드 개발자다 보니 데이터베이스나 관리자 사이트의 구조적인 면에서 많은 수정을 가하기 어려워 보였다. 따라서 내부 구조보다는 외부에서 개선할 수 있는 일 그리고 노력 대비 효과가 클 것 같은 부분에 집중했다.
처음 협업을 시작하며 스스로 가졌던 목표는 단순/반복 노동을 최대한 줄여 결과적으로 CS 1건을 처리하는 평균 시간을 수초 정도 줄이는 것이었다. 노동은 예측 불가능한 불만과 성향을 가진 사용자들을 접하는 정신 노동만으로도 충분하니까!
1. 자동화 봇 만들기
개발팀에서 매일 스크럼을 하듯 CS팀에서도 팀원의 KPI를 분석하고 그날의 업무를 돌아보기 위한 용도로 그날의 업무량을 측정한다. 이메일과 전화, 두가지 경로를 통해 고객들을 응대하고 있으며, 매 CS를 처리할 때마다 CS 내용분류, 날짜, 대응 경로 등을 구글 스프레드시트에 기록한다.
이 봇은 CS팀이 일하는 모습을 지켜보면서 가장 처음 개선점으로 계획했던 일이다. 제품이나 관리자 페이지와 무관해서 다른 팀원의 도움 없이 해결할 수 있는 일이고, 최대한 줄이는 것을 목표로 삼았던 단순/반복 업무이며, 무엇보다 CS팀이 본질적으로 갖는 가치와는 먼 업무를 위한 업무로 반드시 필요하지만 충분히 자동화가 가능한 것으로 보였다.
봇의 작동 원리
- Google API를 활용하여 보낸편지함에서 CS팀원의 이름으로 된 라벨이 붙은 메일 목록을 가져온다.
- 접수 시간은 API로 가져온 메일이 답장으로 보낸 메일에서 받은 시간으로 저장한다.
- 처리 시간은 메일이 보내진 시간으로 저장한다.
- 접수 시간과 처리 시간의 차이에 따라 처리하는 데 걸린 일수를 계산하여 저장한다.
- CS 메일 분류는 CS팀과 라벨 규칙을 정의하여 대분류/소분류로 나누어 저장한다.
- 해당 건의 맥락을 파악해야 하는 경우를 위해 해당 메일 링크를 첨부하여 저장한다.
2. 작은 버튼 하나가 팀원을 춤추게 한다.
만약 코드 1줄이 CS 개당 평균 처리 시간을 1초라도 줄여줄 수 있다면 이거야 말로 최고의 효율 아닌가? CS팀 뿐만 아니라 관리자 도구를 사용하는 모든 팀원들에게 적용될 수 있는 이야기다. 자주 쓰는 버튼의 위치를 옮겨주는 것, 자주 이동하는 페이지들에 단축키를 설정하여 마우스를 조금이라도 덜 쓰게 해주는 것, 항상 같은 순서로 동작하는 기능이라면 한번의 클릭만으로 연결된 동작을 한번에 처리해주는 것 등등.
듣다보면 개발자들은 문득 드는 생각이 있다. 내 이야기 아니야? 훌륭한 개발자들은 게으르다. 게을러서 가능한 한 많은 작업을 자동화시키고, 단축키화 시키고, 마우스까지 손이 가는 것도 싫어서 가능한 한 키보드만으로 처리할 수 있는 환경을 만들고, 찾아가는 게 귀찮아서 알아서 알람이 오도록 만든다. 개발자와 비개발자의 차이는 귀찮은 정도가 아니라 귀찮음을 해결하기 위해 무엇을 해야하는지, 그것을 하기 위해 들어가는 노력이 얼마큼인지 아는지 모르는지이다. 누구나 귀찮은 것은 똑같이 귀찮다.
3. 더 나은 제품으로 CS 줄이기
더 효율적으로 일을 하기 전에 애초에 할 일이 줄어든다면? 소개팅에 나선 사용자가 상대에게 충분히 만족해 주선자를 다시 찾을 일이 없다면? 세 번째 협업은 멋진 기능 대신 구멍난 배를 메우는 일이다.
그동안 우리 제품에서는 결제 수단 변경 기능을 제공하지 않아, 카드를 잃어버리거나 교체한 경우 부득이하게 이용권이 만료되기를 기다렸다가 다시 이용권을 재구매해야 했다.이 과정에서 CS를 찾는 사용자도 많았을 것이고, 아마도 이 허들은 사용자의 서비스 해지 가능성도 높였을 것이다. 최대한 작은 노력을 들이고자 시작한 협업이라, 모바일 결제는 고려 대상에서 제외하여 오직 카드로 결제하는 사용자에 대해 결제 수단 변경 기능을 제공하고자 했다.
개발자와의 협업은 CS팀에게 어떤 경험이 되었는지?
🤯 dave:
가그린 봇은 cs팀이 제품과 어드민 외의 영역에서 개발자와 논의하고 무언가를 진행한 첫 경험이었어요. 이전에는 제품과 업무 플로우를 구분해서 여겼어요. 개발은 제품의 영역에만 해당되고, 업무 플로우 개선을 위해서는 운영적인 부분과 서드 파티의 활용만을 생각했어요. 하지만 가그린봇이 개발되고 실제 업무에 활용하면서 개선의 폭과 가능성이 훨씬 크다는 것을 깨닫게 되었어요. ‘이건 어쩔 수 없이 이렇게 해야 해’ 라고 생각했던 일이 정말 놀랍게도 자동화 된 순간 느꼈던 감정은 아직도 잊을 수 없습니다.기술의 장막을 두려워하지 말고 부딪혀라!1. 아래의 이유로 비개발자가 개발자에게 요청할 때 어려움이 있을 수밖에 없어요.
- 요청하는 내용이 얼마만큼의 리소스가 필요한지 모름
- 요청하는 내용이 실제 구현 가능한지에 대한 의문2. 때문에 개발 관련한 최소한의 지식은 최대한 쌓으면 좋을 듯 해요.(넓고 얕게)
- 개발자에게 분명한 니즈 전달과 개발이 시작되기 위한 첫걸음3. 원활한 커뮤니케이션을 위해서는 누구보다 제품을 잘 파악하는 것이 중요합니다.
🤪 green:
왓챠는 각자의 자리에서만 일을 하고 퇴근하는 것이 아니라 많은 직원들이 자유롭게 자리를 옮겨 다니며 서로에게 관심을 가지면서 일을 해요. 슬랙이라는 업무 툴에서는 물론 오프라인 환경에서도요.저는 여기 저기 자리를 옮겨 다니며 일하는 걸 좋아하는데, 그 중에서 사무실 라운지에 앉아있으면 다른 팀의 직원들과 자연스럽게 이야기를 하게 돼요. 서로 요즘의 업무 근황과 고민하는 포인트들을 얘기 하다보면 각 팀에서 서로 도움을 줄 수 있는 방법에 대해 이야기 하게 되고, 고객들에게 답변 나가는 내용들을 같이 보며 현재 개발팀의 상태나 개선점에 대해서도 자연스럽게 이야기할 수 있어요.결제 카드 변경이나 특정 분류의 CS 메일이 갑자기 많이 들어오면 슬랙의 CS 채널에 알람이 오는 기능들은 이러한 자유로운 대화 속에서 나온 결과물이에요.CS 업무는 대부분이 고객들과 커뮤니케이션을 하고, 빠른 답변을 요구하는 문의들로 인해 스스로 내 주의를 환기시켜 주지 않으면 고객들 문의에 답만 하다가 퇴근하는 경우가 많게 돼요. 이런 부분이 관성이 되면 시스템이나 프로세스에 대한 개선점은 생각하지 못하게 되기도 해요. 따라서 밀려오는 CS에서 한 걸음 물러서서 다른 팀원들 특히 개발자들과 이야기하는 시간을 갖는 것이 중요한 걸 경험했어요.
CS팀과의 협업 이후
이 글의 초안을 완성한 이후로도 관리자 사이트에는 CS팀을 위한 작은 기능들이 더해졌고 자동화 봇은 슬랙봇이 더해져 CS팀이 원할 때 언제든 돌아가도록 명령을 내릴 수 있다. 봇은 CS 메일함도 주기적으로 확인하여 우리가 미처 파악하지 못한 이슈가 발생했을 때 CS 유입량이 급증하는 경우 자동으로 슬랙에 알림도 보내주고 있다. 마지막으로 무엇보다 곳곳에 난 빈 틈을 메워 줄 세 번째 CS 팀원이 생겼다. 야호 👏🏼
작은 회사는 앞만 보고 달린다. 빠르게 달리는 만큼 너울도 길고 깊다. CS는 회사에서 유일하게 나아가야 할 앞보다 뒤에 남겨진 너울을 더 많이, 오래 바라보는 팀이다. 나는 그런 CS팀과 협소하게나마 협업을 하고 그들의 생각과 비전을 단지 엿들어보는 시간을 가지는 것만으로도 충분히 가치있다고 생각한다. 좋고 멋진 기능을 추가하는 일도 좋지만 제품 곳곳에 난 구멍을 하나씩 메우는 일은 앞으로 회사가 한단계 더 나아갈 추진력을 갖는 데 도움을 주는 일이 아닐까 생각한다.
CS팀이 지향하는 CS란?
🤯 dave:
‘우리 CS팀 하고 싶은거 다 하자!’규모가 있는 대부분의 CS조직은 부서와 개인의 성과를 평가하기 위해 굉장히 디테일하게 세분화된 KPI를 사용해요.
‘응답율/응답시간/처리시간/만족도/퇴사율/당일처리율/TO준수율 등’
지나치리만큼 세분화된 KPI도 결국은 더 나은 성과를 내기 위한 여러 수단 중 하나일 거예요. 이런 방식이 업무 효율을 관리하는 데 효과적이라는 건 의심의 여지가 없지만 자칫 CS에서 해낼 수 있는 다양한 가능성을 한정하고 업무를 수동적이고 경직되게 할 수 있다고 생각해요. 왓챠 CS도 효율이 매우 중요하지만 효율 자체가 목적은 아니에요. 높은 효율을 통해 챙긴 자원을(시간, 열정, 에너지 등) 더 나은 CS운영을 위해 고민하고 투자할 수 있도록 사용하는 게 보다 더 중요한 일일 거예요.
CS는 누구보다 먼저, 또 가장 많이 고객의 반응을 확인할 수 있는 업무인 만큼 그 반응들을 통해 다양한 인사이트를 얻을 수 있어요. 여기서 얻은 인사이트를 통해 제품 개선에 도움을 줄 수 있고 CS프로세스를 변경할 수도 있고 필요하다면 여러 서비스 정책을 변경할 수도 있고요. 때문에 당장의 CS처리에 모든 리소스를 쓰는 것보다 다양한 경험과 시도를 하는 게 더욱 중요하다고 생각해요.
이를 위해 앞으로도 목적과 수단이 도치되지 않도록 항상 경계하고, 목적을 위해 무엇이든 자유롭게 도전하는 것이 CS팀이 지향하는 문화입니다.
🤪 green:
대게 사람들은 CS라고 하면 다닥다닥 붙어있는 테이블에 앉아 헤드셋을 쓰고 고객들의 불만을 듣는 모습을 떠올릴 거예요. 그 장면만 본다면 누가 CS일을 하고 싶을까요? 그건 CS가 아니라 소위 콜센터의 모습이에요.왓챠의 CS모습은 많이 달라요. 다양한 채널을 통해 들어오는 고객들의 의견을 바탕으로 누구에게나 오픈된 채널에서 다른 팀원들과 적극적으로 대화하고 공유하며 더 좋은 제품을 만들기 위해 고민하고 노력해요.
들어오는 문의를 ‘CS팀 인원만 늘려서 정해진 시간 안에 최대한 많은 CS를 처리하자’라는 업무 방식은 지양해요. 우리의 지향점은 ‘끊임없이 제품과 CS프로세스를 개선하며 보다 똑똑하고 효율적인 방법으로 고객의 사용 경험을 높이자’예요. 이를 위해 자유롭게 공유되는 슬랙 채널과 회의에 참석하며 회사의 전반적인 상황을 익히는 것은 물론이고, 다른 팀과의 원활한 커뮤니케이션을 통해 개발, 콘텐츠, 데이터 등 얕지만 넓은 범위의 지식을 쌓는 데 힘을 쓰고 있어요. 요즘은 매주 목요일에 하는 CS팀 스터디에 다른 팀의 직원을 초청하여 업무 관련한 지식 및 현재 그 팀에서 중요한 이슈 등을 배우고 있어요.
또한 ‘왓챠만의 CS브랜드를 만들자’ 라는 더 큰 목표가 있어요. 친절과 빠른 응대로만 귀결되어 왔던 CS이미지를 다른 방향으로 바꿔보려고 해요. 고객한테 줄 수 있는 만족감은 넓은 시각에서 보면 매우 다양한데 현재 국내에서는 ‘고객이 왕, 친절, 빠른 답변’ 과 같이 제품과 사용자와의 유대 관계가 아닌 오로지 고객에만 초점이 맞춰져 있어서 항상 아쉬웠어요. 아직 구체화 되진 않았지만 이건 아직 비밀이랍니다. 호호.
Top comments (0)