IT 기획자가 긴밀하게 소통해야 하는 부서, CS!
최전방에서 고객과 소통하며 고객의 사정을 아는 부서는 CS이다.
IT 기획자로 근무하면 CS(Customer Service), 고객 커뮤니케이션 부서와 긴밀히 소통해야 하는 경우가 많다.
서비스 이용자들이 겪는 불편을 알아야 개선 포인트를 파악할 수 있고, 또 어떤 원인에서 불편사항이 발생했는지 명확히 알아야 CS부서에서 대응이 가능하기 때문이다.
또한 서비스나 제품이 훌륭하더라도 CS가 부족하면 고객은 해당 기업 또는 브랜드에 크게 실망하고 뒤 돌아 서게 된다. 그렇다면 좋은 CS를 위해 기획자는 어떤 역할을 할 수 있을지 살펴보자.
CS에서 가장 중요한 건 진심
국내 최대 게임 회사의 CS와 QA를 담당하던 계열사에서 인턴십을 했었다. 게임의 아이템을 잃어버린 경우, 히스토리 데이터를 확인하여 복구 가능 여부를 판단하고 이를 고객에게 안내하는 업무였다.
만약 데이터 보관 기간이 지났거나, 분실 여부를 알 수 없는 경우 등 케이스에 따라 복구가 불가할 땐 이를 고객에게 안내하는 것이 쉽지 않았다. 게임 속에서 아이템은 캐릭터를 넘어, 고객의 자산이었기 때문이다. 더 나아가 유료 아이템을 분실한 경우, 고객이 느끼는 상실감은 상당히 컸다.
평소 게임을 하지 않아 이 업무를 하기 전에는 잘 몰랐다. 그러나 담당 업무를 이해하고자 주말에도 게임을 즐겨하며 만렙을 앞두게 되자, 사용자들이 느꼈을 상실감에 대해 진정으로 공감하게 됐다.
그러던 어느 날, 아이템 복구가 불가하여 지속적으로 항의를 보내오던 고객을 담당하게 됐다. 비속어와 함께 장문의 메일을 계속해서 보내오던 고객이라, 히스토리에는 기계적인 답변들이 쌓여있었다.
그래서 이번에는 천편일률적인 답변이 아닌 고객이 느꼈을 상실감에 대해 진심으로 공감하며 안타까운 마음을 담아 불가피한 정책에 대해 안내했다.
놀랍게도 그 안내 이후, 수개월이 넘게 지속되던 항의 메일은 더 이상 오지 않았다. 고객에게 필요했던 건 정책상 불가피하더라도 불편을 드린 것에 대한 진심 어린 사과와 공감 그리고 개선하고자 하는 의지였던 것이다.
그렇게 오래 지속되었던 고객의 한(?)을 풀어 드린 것을 계기로 진심을 다해 업무를 했고, 놀랍게도 인턴십이 끝날 때는 특별 채용 제의를 받기도 했다.
이러한 제안이 가능했던 이유는 근무했던 회사가 정성 어린 CS사례로 인터넷에서 화제가 될 정도로 CS를 중요하게 생각하던 회사였기 때문이다. 심지어 CS를 제대로 하기 위해 전담 계열사를 설립해서 운영할 정도로 말이다.
CS 체험 프로그램을 운영하는 회사
특별한 신입사원 프로그램을 통해서도 CS를 경험했었다. 재직했던 기업에서는 신입공채로 입사하면 인사팀에서 준비한 다양한 프로그램들이 있었다. 그중 가장 인상 깊었던 것 중 하나는 바로 CS 기업 방문 프로그램이다.
회사에서 아웃소싱으로 운영하고 있는 고객 커뮤니케이션 회사에 방문하는 프로그램이었다. 하루 동안, CS 담당 직원분의 옆 자리에 앉아 접수되는 불편사항을 함께 청취하는 것이다.
해당 프로그램을 통해 비교적 자주 접수되는 불편 사항은 무엇인지, 개선이 필요하다고 판단되는 것은 무엇인지에 대해 보고서를 작성해야 했다. 보고서 작성은 생각보다 어렵지 않았다. 고객 문의를 청취하고 있으면 저절로 알게 됐기 때문이다.
그만큼 CS 부서는 서비스를 이용하는 다수의 고객이 무엇을 가장 불편해하고 어떤 것에 개선이 시급하다고 느끼는지 가장 잘 알 수밖에 없는 최전방의 부서였다.
또한 서비스가 불편하면 지속적으로 불필요한 안내를 해야 하는 CS로 인해 일하시는 분들이 얼마나 괴로우신지 체감할 수 있었다. 기획자로서 서비스를 편리하게 만들어야겠다는 동기부여가 되는 좋은 프로그램이었다.
위에서 언급한 사례처럼 사용자 중심의 서비스를 중요하게 생각하는 기업들은 CS를 전담할 계열사를 설립하기도 하고 기업에 입사한 신입사원들에게 CS 체험 프로그램을 제공하기도 하며 CS를 중요하게 바라보고 있다.
기획자의 CS프로세스
CS부서에서 서비스 불편 사항에 대한 확인 요청이 오는 경우, 가장 먼저 정상 작동 여부를 확인한다.
개발 오류에 의한 것인가?
만약 개발 오류가 원인인 경우, 담당 개발자에게 오류 사실을 알린 후 수정까지 소요될 시간을 확인하여 CS부서로 전달한다.
그러나 만약 정상 작동이라면 개선이 필요한 사항인지 아닌지에 대해 판단해야 한다.
1) 개선이 필요한 사항인가
2) 정책적으로 제한하는 사항인가
개선이 필요한 사항이라면 개선 방향을 빠르게 검토한다. 만약 빠른 개선이 가능할 것으로 확인되면 바로 개선 작업을 진행하며 해당 내용을 CS부서로 전달한다.
그러나 만약 정책적으로 위배되는 사항으로 인해 고객이 불편함을 겪고 있다면, CS부서에 정책사항을 안내하고 해당 정책이 반드시 필요한 내용인지 검토해야 한다.
특히 정책 변경이 필요한 경우에는 해당 정책이 만들어진 이유에 대해 꼼꼼하게 확인한다. 오랫동안 변경된 적 없는 타 서비스의 정책들과 충돌하지 않을지도 함께 검토해야 하기 때문이다.
그러나 이러한 과정을 거치다 보면 빠르게 고객에게 대응하는 것이 어려울 때가 있다. 그렇기 때문에 서비스를 새로 기획할 때는 물론이고 서비스의 작은 부분이라도 변경될 예정이라면 해당 내용을 미리 CS부서로 안내하는 시간을 가져야 한다.
CS부서와 기획서를 공유하는 프로세스
기획서는 개발자, 디자이너 외 다양한 부서에 공유되지만, 특히 CS부서에게 변경될 상세한 서비스 플로우와 정책을 공유해야 한다.
서비스 변경 내용이 CS 부서에 공유되지 않은 채, 잘못 대응하게 되면 고객은 당황스럽고 CS부서의 담당자는 재직 중인 회사의 서비스도 잘 모르는 무능한 직원으로 비치게 된다. 이러한 상황의 책임은 누구에게 있는가. 바로 PM/PO인 기획자에게 있다.
그렇기 때문에 반드시 변경 예정인 서비스 요소와 정책에 대해 사전에 CS부서에게 상세히 공유해야 한다.
CS부서와의 정기적인 회의
이를 위해서는 기획팀과 CS팀이 정기적으로 회의를 진행하는 것도 좋다.
현재 재직 중인 회사는 주요 카테고리로 분류된 CS 통계를 모니터링하는 보고서가 매주 공유되며 어떤 개선이 필요한지 정기적으로 논의하는 자리가 있다. 해당 미팅에서는 기획자가 지난 논의사항에 대해 검토 결과와 진행사항을 공유하게 된다.
기획자는 평소 다양한 경로를 통해 서비스를 개선점을 고민하지만, 특히 CS부서와의 미팅에서 나오는 개선점들은 서비스의 가장 기본이 되는 요소인 경우가 많다. 이러한 개선점들은 당장 성과가 나오는 서비스 아이디어는 아닐지라도, 서비스의 편리한 운영과 직결되는 가장 핵심적인 것이다. 그렇기 때문에 기획자에게 더욱 필요한 미팅이다.
CS 실시간 모니터링
이 외에도 슬랙 채널에서 고객 문의 및 앱 리뷰가 실시간으로 업로드되는데, 이슈에 대한 것이라면 각 담당자가 문제의 원인은 무엇이고 개선이 필요한 사항인지에 대한 코멘트를 남기는 프로세스가 있다.
바쁘게 업무를 하고 있던 중, 담당 서비스의 이슈가 업로드되면 당황스러울 때도 물론 있다. (가끔은 제발 내가 담당하는 서비스는 안 올라왔으면 하고 바랄 때도 있지만) 덕분에 이슈를 빠르게 체크할 수 있고 관련자들을 태그 하여 빠르게 추가 개선점을 논의할 수 있어 좋은 프로세스이다.
CS 방지 프로세스
고객에게 CS가 온 경우 외에도 기획자는 CS부서의 불필요한 리소스가 들지 않도록 2가지를 미리 챙겨야 한다.
1) 사전공지
2) QnA
3) 친절한 서비스 플로우와 문구
변경된 서비스에 대해 고객이 당황하여 문의를 보내오지 않도록 사전에 서비스 변경사항에 대해 공지를 올린다. 또한 문의가 올 것으로 예상되는 내용에 대해서는 QnA 페이지에 추가할지 여부를 검토해 볼 필요가 있다. 마지막으로 서비스의 플로우와 문구가 친절해야 서비스 사용 방법에 대한 이해가 부족하여 불필요하게 발생하는 CS를 줄일 수 있다.
서비스의 최전방에서 고객과 직접 소통하고 있는 CS. CS와의 커뮤니케이션을 중요하게 생각하는 것이 곧 사용자 중심에서 고객에게 진정 필요한 것이 무엇일지 더 깊게 관여할 수 있는 것을 잊지 말자.
