지원 티켓

문의가 공용 메일함으로 들어오던 시절에는 처리라는 말이 답장을 보낸다는 뜻이었습니다. 답장을 보내면 스레드가 읽은 메일로 내려가고 그것으로 끝났습니다. 문제는 그 방식으로 아무것도 셀 수 없었다는 점입니다.

실제로 벌어진 일은 이런 모양입니다. 같은 문의에 두 사람이 각자 답장을 보내 고객이 서로 다른 답을 받습니다. 어려운 문의는 아는 사람에게 전달하는데 그 사람이 휴가에서 돌아오면 이미 나흘이 지나 있습니다. 월요일에 몰린 문의 중 몇 건이 답을 못 받았는지 물으면 아무도 모릅니다. 받은편지함마다 흩어져 있기 때문입니다.

셀 수 없다는 것이 특히 큰 문제였습니다. 하루에 몇 건이 들어오는지 모르면 사람이 모자란 것인지 특정 기능이 고장 난 것인지 구분할 수 없고, 인원을 늘려야 할 때와 제품을 고쳐야 할 때를 가릴 근거도 없습니다. 지원 티켓은 문의 하나를 셀 수 있고 넘길 수 있는 물건으로 만들려고 도입한 형식입니다. 번호와 상태를 달면 지금 열려 있는 건이 몇 개인지 한 화면에 나옵니다.

한 건은 여섯 항목을 갖춥니다.

1. 번호입니다. 셀 수 있게 만드는 것이 전부이고, 고객과 이야기할 때 무엇을 가리키는지 헷갈리지 않는 효과가 따라옵니다.
2. 요청자와 계정입니다. 누가 보냈는지만 적고 어느 고객사인지 연결하지 않으면 이 문의가 매출 얼마짜리 계정에서 왔는지 알 수 없습니다. 페이지덱은 접수 즉시 계정을 붙여 우선순위 판단에 씁니다.
3. 제목과 내용, 그리고 재현 정보입니다. 무엇을 하려다 무엇이 일어났는지, 어느 화면에서 몇 시에 일어났는지 적습니다. 이 세 가지가 없으면 2차 담당자가 같은 질문을 다시 하게 되고 그동안 시간만 흐릅니다.
4. 상태입니다. 미처리, 답변함, 고객 대기, 종료로 나눕니다. 고객 대기를 따로 두는 이유는 우리가 늦는 것과 고객의 답을 기다리는 것을 섞으면 지원 속도를 잘못 재기 때문입니다. 첫 응답 시간, 곧 문의가 들어온 뒤 첫 답변까지 걸린 시간을 정확히 재려면 이 구분이 있어야 합니다.
5. 담당자와 우선순위입니다. 우선순위는 감이 아니라 기준으로 정하고, 페이지덱은 요금제와 영향 범위를 함께 봅니다. 기업 계약에서 전체 사용자가 로그인을 못 하는 건은 최상위, 일반 요금제에서 한 사람이 겪는 화면 깨짐은 하위입니다.
6. 분류 태그입니다. 기능별 또는 원인별로 칸을 미리 만들어 두고 담당자가 하나를 고릅니다. 목적은 세기 위해서입니다. 한 달에 같은 태그가 마흔 건 쌓이면 그것은 개별 문의가 아니라 제품 과제이고, 고객의 소리, 곧 고객이 남긴 의견을 모아 제품에 반영하는 활동으로 넘어갑니다.

대화 기록은 이 여섯 항목에 붙어 따라다닙니다. 담당자가 바뀌어도 대화가 통째로 넘어가는 것이 메일 스레드와 갈라지는 지점입니다.

첫 줄은 고객이 씁니다. 그런데 고객이 보낸 문장만으로는 처리할 수 있는 티켓이 되지 않을 때가 많습니다. 안 된다는 세 글자로 접수되는 건도 드물지 않아, 상담사가 3번 항목을 되물어 채우는 일이 실질적인 작성 작업입니다. 페이지덱은 이 되묻는 질문을 세 개로 정해 두었습니다. 무엇을 하려고 했는지, 무엇이 일어났는지, 마지막으로 정상이던 때가 언제인지입니다.

한 티켓에 한 문제만 담습니다. 고객이 메일 하나에 세 가지를 적어 보냈으면 세 건으로 쪼갭니다. 쪼개지 않으면 두 개는 해결되고 하나는 남은 티켓이 종료도 미처리도 아닌 상태가 되고, 통계에서는 한 건으로 세어집니다.

독자는 다섯입니다. 1차 상담사가 접수하고 답합니다. 지원 등급, 곧 난이도에 따라 1차와 2차로 나눈 구조에서 2차 담당자는 넘어온 티켓의 재현 정보부터 읽습니다. 태오는 제품 결함으로 넘어온 건을 읽고, 지현은 태그별 집계를 읽습니다. 수아는 갱신을 앞둔 계정의 미해결 건수를 읽습니다. 다섯 건 넘게 열려 있는 계정은 갱신 대화가 시작되기 전에 정리합니다.

고객도 독자입니다. 번호와 상태를 볼 수 있게 열어 두면 진행 상황을 묻는 문의가 줄어듭니다. 답이 늦는 동안 고객이 가장 답답해하는 것은 늦는 것보다 접수가 됐는지조차 모르는 상태입니다.

"그 건 티켓 번호 주시겠어요? 어제 답변한 건과 같은 건인지 확인하겠습니다."

번호가 대화의 기준점 노릇을 한다는 뜻입니다.

"이 티켓 고객 대기로 바꿔 주세요. 로그 받기로 하고 이틀 기다리는 중입니다."

우리 지연이 아니라 고객의 답을 기다리는 상태로 표시한다는 말입니다.

"권한 태그가 이번 달에 마흔 건이에요. 이건 지원에서 풀 문제가 아닙니다."

티켓 집계가 제품 과제를 만들어 낸다는 사례입니다.

페이지덱에서는 아침에 미처리 목록을 우선순위 순으로 훑고 30분 안에 전부 첫 답을 보냅니다. 당장 답이 없는 건에도 접수됐고 무엇을 확인하는 중이라는 답을 보냅니다.

주마다 한 번은 종료된 티켓을 다시 봅니다. 같은 고객이 같은 태그로 세 번 이상 열었으면 개별 처리가 아니라 그 계정의 설정이나 교육을 봐야 한다는 신호입니다. 이 점검이 해결 시간, 곧 문의를 끝까지 처리하는 데 걸린 시간을 줄이는 데 가장 크게 작동했습니다.

티켓 수가 적을수록 좋다고 읽는 경우가 가장 많습니다. 문의가 적으면 제품에 문제가 없어 보이니 그렇게 읽기 쉽습니다. 하지만 이 숫자는 접수 창구를 줄이기만 해도 내려갑니다. 문의 버튼을 찾기 어렵게 만들고 안내 문서 끝에만 두면 티켓은 절반이 되고 말없이 떠나는 고객이 늘어납니다. 접수되지 않은 불만은 사라진 것이 아니라 보이지 않게 된 것입니다.

티켓을 지원팀 내부 기록으로 보는 것도 흔한 오해입니다. 처리용 도구이니 처리하는 사람만 보면 된다고 여기기 쉽습니다. 그런데 태그와 계정이 붙은 티켓 더미는 제품팀이 다음 분기에 무엇을 고칠지 정하는 가장 싼 자료이고, 갱신 자리에서는 이 계정을 그동안 어떻게 대했는지 보여 주는 기록입니다. 내부 기록으로만 다루면 태그를 성실히 붙일 이유가 없어지고, 반년 뒤에는 절반이 기타로 채워져 아무것도 세지 못합니다.