'CS팀'과 '제품팀'의 협업을 최대로 이끄는 10가지 Tips!

지난 아티클에서는 CS팀과 제품팀의 관계가 매끄럽지 않은 이유와 이를 극복했을 때 CS팀, 제품팀, 그리고 고객에게 어떤 이익이 생기는지 알아보았습니다. 오늘은 어떻게 CS팀과 제품팀의 관계를 잘 만들어갈 수 있는지, Erika Warren이 작성한 아티클의 일부를 발췌하여 소개하겠습니다!

Part 1. 업무 공유하기

(a) CS팀의 업무를 셰도잉하여, 팀 간의 공감과 신뢰를 이끌어내기

효과적인 협업을 이끌기 전, 신뢰와 존중을 우선적으로 쌓을 필요가 있다. 또한, 제품팀이 CS팀보다는 우선순위 업무를 결정할 권한이 크기 때문에, 제품팀에서 먼저 나서서 관계 개선에 힘쓰는 방향성이 옳다. 고객의 사용성 조사를 시행할 때, CS팀의 업무를 셰도잉 해보자.

CS팀의 업무를 셰도잉 하는 것은 아래의 장점이 있다.

1. 고객의 피드백과 이슈를 직접 확인할 수 있다.

2. 고객에 대한 직감을 기를 수 있다.

3. 팀 간의 공감대를 형성할 수 있다.

4. CS팀과 PM간의 대화를 만들 수 있다.

5. 다른 업무 흐름에 대한 가시성을 전달할 수 있다.

위잔트(Wyzant)라는 미국의 과외 플랫폼은 한 달에 최소 1회, 몇 시간동안 모든 제품팀이 CS팀의 업무를 한다. 많은 제품팀 팀원들은 이 방법이 본인의 업무에도 효과적이라는 것을 깨닫고, 추가적인 시간을 CS 셰도잉에 할애하기도 한다. 그리고, 셰도잉 문화는 확장되어 전사 직원이 분기에 최소 한 번씩은 해보는 일이 되었다. CS 업무 셰도잉은 고객과 주기적으로 소통하지 않는 직군의 직원들이 회사의 미션과 비전을 다시 한 번 생각하는 계기가 된다.

CS 셰도잉 문화를 세팅하는 것이 번거롭거나 힘들거라 생각하는 분들도 있을 것이다. 하지만, 내 경험으로는 결코 번거롭지 않다. 이렇게 한 번 해보라.

1. 제품팀 팀장은 CS팀 팀장과 만나, 셰도잉 프로그램의 목표와 장점을 설명한다.

2. CS팀이 너무 바쁘지 않은 적당한 시간을 골라, 두 팀이 함께 스케쥴을 만든다. 바쁘지 않은 시간으로 시간을 정하는 이유는, 이렇게 되면 전화나 챗 응답의 사이사이에 팀원들 간에 대화를 할 수 있고, 다양한 이슈도 살펴볼 수 있기 때문이다.

3. CS 팀원이 먼저 CS건을 응대하면, 제품 팀원들이 해당 응대 건에 함께 한다.

4. 두 팀이 함께 앉아서 전화 응대를 함께 듣는다. (세일즈포스나 젠데스크는 리모트로도 전화 응대 셰도잉을 할 수 있는 기능이 있다.)

5. 주간 셰도잉 세션이 끝난 후, 제품팀은 CS 매니저들과 그 경험에 대한 브리핑을 진행한다. 마지막 브리핑은 특히 정말 중요하다. 이는 바쁜 PM들이 정말로 셰도잉을 진행도록 하는 책임감을 주며, CS 매니저들은 제품팀 팀원들이 같은 정보를 보고 어떻게, 무엇을 말하는지 인사이트를 얻을 수 있다.

(b) 사용자 리서치의 연장선에 CS팀을 포함시키기

신뢰감이 탄탄하게 형성됐다면, 사용자 조사의 연장으로 CS팀을 어떻게 활용할지 생각해볼 때이다. CS팀의 규모가 제품이나 리서치팀보다 큰 경우가 많다. 게다가 그들은 고객과 맞닿아있는 조직 아닌가!

간단히 할 수 있는 방법은 다음과 같다.CS팀이 고객 응대를 마치면서, 특정 이슈 한 가지에 대해서 고객에게 질문하게끔 요청한다.고객과의 소통을 통해, 더욱 깊은 고객 리서치를 함께 진행한다.

(c) 피드백 시스템에 대해 공동의 오너십 형성하기

'피드백 기록'은 오래도록 나왔던, 기능 관련 요청을 정량적으로 트래킹하는 툴이다. 당연히, 이 툴은 CS팀과 함께 사용했을 때 더욱 효과적이다!

이 툴을 활용하여, PM은 일부 업무를 CS팀에게 위임할 수 있으며, CS팀은 제품과 비즈니스에 대한 감각을 키울 수 있다. 피드백 시스템을 기록하는 실무자는 어떻게, 그리고 왜 PM들이 특정 피드백을 우선시하는지 그 맥락을 이해하기 시작하게 된다. CS팀의 실무자 중 업무를 잘하는 한 명이 이를 팀에게 알릴 수 있으며, PM이 부재할 때 제품에 대한 결정도 도울 수 있다.

(d) CS팀에게 QA와 베타테스트 관련 도움 받기

제품의 기능에 대해 CS팀원들이 가장 능숙하고 지식이 많은 경우가 많다. 위잔트(Wyzant)의 제품팀은 중요한 기능 릴리즈 전에 CS팀원에게 테스팅을 부탁하는 습관을 만들었다. 이는 에러를 줄이기 때문에 제품팀에게 좋고, 개발의 과정에 참여할 수 있기 때문에 CS팀에게 좋으며, 완성도 높은 경험을 할 수 있기 때문에 고객에게 좋고, 그렇기 때문에 회사에 이롭다.

제품팀이 CS팀을 고객과 회사를 잇는 다리로 생각한다면, 임팩트가 큰 일을 할 수 있다. CS팀은 좀 더 존중받고, 중요한 업무에 직접적으로 관여한다는 느낌을 받을 수 있으며, 시간을 어디에 쓰는게 좋을지 확인할 수 있게 된다.

Part 2. 공통의 언어를 만들기

고객과 문제에 대해 얘기할 때, 공동의 '용어'를 만들지 않으면, 같은 얘기를 다른 말로 진행하는 현상이 생길 수 있다.

(a) 함께 이슈의 분류 체계 만들기

CS팀은 생산성을 측정하는 수치로, '응대 수'와 '응대 당 시간'을 사용하는데, 이는 이슈 하나를 해결하는데 사용되는 시간과 비용을 예상하기 위한 수치이다. 이 수치는 CS팀이 사용하기에는 문제가 없어 보이지만, 제품팀에게 작동하지 않을 수도 있다. 제품팀은 특정 고객과 케이스, 그리고 라이프사이클 단계를 기반으로 구조화되어 있으며, CS 인입 건들의 기능적이고 단편적인 면보다는 조금 더 전체적인 경험을 고려하기 때문이다.

공통의 언어가 없는 상태에서 제품팀은 이슈 데이터를 무시하고 조금 더 쉽게 실행 가능한 데이터에만 집중할 수 있다. 이 문제를 피하기 위해서는 CS팀과 제품팀이 함께 체계법을 만들어야 한다.

위잔트(Wyzant)에서 새로운 체계법을 만들었을 때, 이는 기존의 체계법보다 더욱 직관적이었기 때문에 CS팀의 일을 줄일 수 있었으며, 단편적인 기능 이슈보다는 조금 더 거시적인 주제에 포커스가 맞춰졌다. 이 체계법을 만든 이후, 주간 회의 때 CS팀이 제공하는 수치들이 달리 보이기 시작했다.

(b) 미리 제품의 로드맵 공유하기

작은 기능 개선이나 버그 픽스를 요청하기에 가장 좋은 타이밍은 제품팀이 해당 내용에 대해 이미 집중하고 있을 때이다. PM은 CS팀, 세일즈팀 혹은 다른팀과의 대화의 자리를 만들어 제품에 대한 인사이트를 보강해야 한다. 대화를 통해, 기존에 있던 기능 결함을 직접 확인하며, 디자인의 방향성에 대한 인사이트를 제공하고, 불필요한 제품 개선 사이클의 시간을 줄일 수 있다.

“제품팀 여러분들, '추천' 기능을 곧 개선한다고 들었어요. 최근에 인입된 '추천 기능 관련 이슈'와 이에 대한 '고객 피드백'을 정리하여 전달드립니다.”라는 메시지를 CS팀에게 듣고 싶지 않은가?

여기에 보너스로 CS팀이 '고객에 대한 세부적인 특이 사항'까지 제품팀에 전달한다면, 제품팀과 리서치팀은 추후에 진행할 사용자 리서치에 참여할 의사가 있는 고객 리스트를 얻게 되는 것이다.

(c) 소통의 루프를 만들고, 이를 종료하기

CS와 제품팀 간의 협업의 루프를 종료하는 것이 필요할까? 사실, 이 단계가 가장 중요하다. 실수를 돌아보는 것도 중요하지만, 우리가 잘해낸 것을 반영하고 모든 직원들의 영향력과 가치에 대해 소통하는 것이 더욱 중요하기 때문이다. 잘 해낸 업무에 대해 소통하거나 축하한 후 CS팀이 해당 이슈를 종료하면, 임팩트를 내는데 기여한 팀은 이 소통 루프를 계속해서 만들려고 할 것이다.

위잔트(Wyzant)에서 PM들은 CS 매니저들과 만나 다가올 업무와 새로운 이슈에 대해 월 단위 토론을 진행했다. 이 때, 이메일이나 슬랙을 사용하기 보다는 면대면 미팅을 활용했는데, 우리는 CS팀이 얼마나 유용한 안건을 많이 들고 오는지 깨달았다.

Part 3. 공동의 목표를 세우는 문화 만들기

공동의 언어를 만든 후에는 목표를 중심으로 팀을 얼라인할 수 있다. 이는 두 팀이 같은 고충점과 목표에 집중할 수 있게 돕는다.

(a) 우선순위가 높은 로드맵은 어떤 이유로 만들어졌는지 공유하기

제품팀이 로드맵과 업무의 근원이 되는 이유를 CS팀과 소통하게 되면, CS팀은 제품팀이 가장 우선시하는 이슈의 유형과 맥락을 이해할 수 있게 되며, 이는 CS팀이 제품팀에게 인사이트를 더욱 효과적으로 공유할 수 있도록 한다.

또한, 우선 순위가 낮은 업무에 대한 소통도 CS팀 리더에게 도움이 되는데, 그 이유는 CS 팀원을 훈련시키고 고객에게 어떻게 반응해야할지 판단하는데 도움이 되는 인사이트이기 때문이다.

(b) CS팀의 목표치를 설정하기

CS팀 리더들에게 회사의 전략과 맞는 팀 목표를 세팅해주는 것도 하나의 효과적인 방법이다. 당신의 회사가 데이터 기반이라면, CS팀 또한 반드시 데이터 기반이어야만 한다.

위잔트(Wyzant)의 주요 수치는 '진행하는 과외 수 대비 CS 인입 건'이었다. 이는 위잔트가 J커브로 성장하도록 하는 능력을 측정했으며, 성장과 동시에 더 나은 고객 경험을 만드는 능력을 보여주었다. 이 목표치는 CS팀이 개발팀에 의존하지 않고 효율성을 높이는 방법을 생각하면서도, 개발팀이 더 높은 가치의 업무를 우선시하도록 하도록 만들었다. 또한, CS팀에게 자율권과 오너십을 선사했으며, 커리어 성장을 돕는 길이기도 했다.

(c) 주요 컨택 포인트를 만들어서 소통하기

PM이 수 많은 사람들과 소통할만한 시간이 있는 것은 아니다. 따라서, 하나의 컨택 포인트를 만들 필요가 있다.

“퀴즐렛(Quizlet)에서는 각각의 제품 스쿼드가 CS와 개발팀을 잇는 제품 서포트 전문가(PSS)와 소통했어요.” 퀴즐렛(Quizlet)에서 제품 리더를 했던 Natalie Rothfels가 말했다.

퀴즐렛(Quizlet)의 제품 서포트 전문가(PSS)는 제품팀이 거의 사용되지 않는 기능을 없앨 수 있도록 돕기도 했다. “비즈니스를 위해서는 기능을 없애는게 맞다는 확신이 있었지만, 1,000만 명의 고객 중 일부가 사용한다면 이는 여전히 많은 고객에게 영향을 줄 수도 있다는 생각을 했어요."

“기능을 없애기에 앞서, 우리는 PSS와 협업하여 우리가 고객에게 듣고 싶은 모든 것을 문서화했습니다. 우리는 화가 났을 많은 고객을 응대해야 하기 때문에, 미리 이슈를 트래킹할 방법들을 만들어 두었어요. 또한, 주별로 우리가 예상한 것이 맞았는지 리뷰하는 시간을 가졌답니다. 우리가 예상한대로 기능을 없애자, 화가 난 고객들이 많았어요. 하지만 미리 준비했기 때문에 미리 예측하여 대응할 수 있었고, CS팀의 화와 걱정이 조금은 줄었답니다."

• Written by Erika Warren (원문)

• Translated & Edited by Yong (최용경)