고객 지원 담당자

제품을 쓰다 막힌 사람은 어떻게든 연락할 곳을 찾습니다. 회사가 작을 때 그 연락은 대표 메일함이나 만든 사람의 메신저로 곧장 들어옵니다. 고객이 열 곳이면 이쪽이 오히려 빠릅니다. 만든 사람이 직접 답하니 오해가 낄 자리가 없습니다.

무너지는 지점은 대개 고객이 수백 곳이 될 때입니다. 아침에 문의 40건이 쌓여 있으면 개발자는 오전을 통째로 거기에 쓰고, 오후에 코드를 붙잡으면 답을 기다리는 고객이 다시 쌓입니다. 어제 온 문의에 답했는지 아무도 모르는 상태가 되고, 같은 오류를 세 사람이 각각 다르게 설명하는 일도 생깁니다.

실제로 이렇게 나타납니다. 고객이 "지난주에 문의드렸는데요" 하고 다시 연락하는데, 받은 사람은 그 기록을 어디서 찾아야 할지 모릅니다. 문의가 개인 메일함에 흩어져 있으면 누가 무엇을 약속했는지 확인할 길이 없습니다.

고객 지원 담당자는 이 일을 전담으로 떼어 낸 자리입니다. 들어온 문의를 한 곳에 모아 접수하고, 순서를 정해 처리하고, 내용을 남기는 일을 맡습니다. 답이 빨라지는 것보다 큰 변화는 답에 기록이 남는다는 것입니다.

하루는 대기 중인 티켓 목록을 여는 것으로 시작합니다. 티켓은 문의 하나를 처리할 일 하나로 끊어 등록한 항목이고, 접수 시각과 고객사, 주고받은 내용, 지금 상태가 함께 붙어 있습니다. 처리는 대체로 아래 순서로 돕니다.

1. 순서를 정합니다. 먼저 들어온 것부터가 아니라 영향 범위와 약속한 응답 시간 기준입니다. 결제가 안 되는 건이 화면 색이 이상하다는 건보다 앞서고, 두 시간 안에 첫 답을 주기로 한 기업 고객의 건이 그 앞에 섭니다.
2. 첫 답을 보냅니다. 접수했다는 사실과 지금 무엇을 확인하고 있는지를 알립니다. 문의가 들어온 뒤 여기까지 걸린 시간을 첫 응답 시간이라고 부르고, 지원 조직에서 가장 자주 보는 숫자입니다.
3. 재현해 봅니다. 고객이 쓴 문장만으로는 부족해서 어떤 화면에서 무엇을 눌렀는지 되묻고 같은 조건을 만들어 확인합니다. 이 단계에서 절반 이상이 설정 문제로 판명됩니다.
4. 답을 씁니다. 자주 나오는 질문은 미리 저장해 둔 답변 틀인 매크로를 꺼내 고객 상황에 맞게 고쳐 씁니다. 처음부터 쓰는 시간을 아끼면서 답변의 수준을 고르게 유지하는 방법입니다.
5. 넘길 것은 넘깁니다. 제품의 결함이면 개발팀에 재현 절차와 함께 전달하고, 반나절 이상 파고들어야 하는 건이면 기술 지원으로 보냅니다. 이렇게 상위 담당으로 넘기는 절차를 에스컬레이션이라고 합니다.
6. 남깁니다. 같은 질문이 반복되면 도움말 센터에 문서를 추가합니다. 잘 쓴 문서 하나가 같은 질문 수백 건을 아예 들어오지 않게 만듭니다.

하루 처리량은 개인 사용자가 많은 제품이면 수십에서 백 건대까지 가고, 기업 고객만 상대하면 건수가 적은 대신 한 건에 오래 걸립니다.

혼자서 끝나는 자리가 아니라 문의를 받아 적절한 곳으로 흘려보내는 자리에 가깝습니다. 붙어 있는 상대는 넷입니다.

같은 조직 안에서는 CSM과 가장 자주 붙습니다. 담당 고객사에서 문의가 여러 건 들어오면 지원 담당자가 그 사실을 알립니다. 문의가 갑자기 늘어난 계정은 뭔가 잘못되고 있다는 신호라서, CSM 은 그 신호를 받아 고객에게 먼저 연락합니다.

도입 초기 고객은 온보딩 담당자에게 넘깁니다. 계약 첫 달의 질문은 결함이 아니라 설정이 안 끝난 데서 나오는 경우가 많고, 이런 건은 답변 한 통보다 화면을 같이 보는 편이 빠릅니다.

개발팀과는 결함을 사이에 두고 만납니다. 지원 담당자가 쓴 재현 절차의 품질이 그 결함이 언제 고쳐지는지를 좌우합니다. "안 됩니다" 라고 적힌 전달과 "결제 화면에서 카드 두 개를 등록한 계정만 재현됩니다" 라고 적힌 전달은 개발팀이 손대는 시점이 며칠씩 차이 납니다.

제품팀과는 쌓인 기록으로 만납니다. 한 달치 문의를 유형별로 묶으면 무엇이 자주 걸리는지가 드러나고, 그 묶음이 고객의 소리의 재료가 됩니다. 이 흐름 전체를 어떻게 굴릴지 정하는 일은 고객 지원 운영이 맡습니다.

"이 건은 CS 에서 답할 수 있는 범위가 아니라 개발팀으로 넘겼습니다."

지원 담당자 선에서 풀 수 없는 결함이라는 뜻입니다.

"어제 문의 40건 중에 30건이 같은 오류예요. 장애 아닌가요?"

같은 유형이 몰리는 것을 장애 신고로 읽어야 한다는 제안입니다.

"매크로 좀 고쳐 주세요. 지난주에 정책 바뀐 게 반영이 안 됐어요."

저장해 둔 답변 틀이 낡아 잘못된 안내가 나가고 있다는 지적입니다.

페이지덱에서는 지원 담당자가 무료 플랜 문의는 이메일로만 받고, 기업 고객에게는 전용 대화 채널을 열어 두 시간 안에 첫 답을 줍니다. 오전에 같은 오류 신고가 열 건 넘게 몰리면 그 자리에서 개발팀에 알리는 것이 규칙입니다. 한 건씩 답하다 보면 장애라는 사실을 알아채는 데 반나절이 걸리기 때문입니다.

수아는 담당 고객사의 문의가 늘면 지원 쪽에서 먼저 연락을 받습니다. 지난 분기에 한 고객사의 문의가 2주 동안 평소의 세 배로 늘었는데, 그 회사에 새 팀이 들어와 아무 교육 없이 쓰기 시작한 탓이었습니다.

정해진 답을 복사해 보내는 단순한 일이라고 보는 시각이 흔합니다. 매크로를 쓰는 모습만 보면 그렇게 보입니다. 하지만 실제로 시간을 잡아먹는 것은 답을 쓰는 단계가 아니라 그 앞의 재현 단계입니다. 고객이 쓴 몇 줄에서 어떤 화면의 어떤 조건인지 알아내는 일은 제품 전체를 알아야 가능합니다. 이 자리를 단순 업무로 보고 인수인계 없이 사람을 바꾸면 같은 문의를 처리하는 데 걸리는 시간이 눈에 띄게 늘어납니다.

문의 건수를 줄이는 것이 이 자리의 목표라고 생각하는 오해도 있습니다. 숫자만 보면 줄어드는 쪽이 좋아 보입니다. 하지만 문의가 줄어드는 데는 두 가지 이유가 있습니다. 제품이 쉬워졌거나, 고객이 말하기를 포기했거나입니다. 뒤쪽이면 문의는 줄어드는데 해지는 늘어납니다. 그래서 건수 하나만 보지 않고 재문의 비율이나 해결까지 걸린 시간을 함께 봅니다.