첫 응답 시간

문의에 답이 오지 않는 동안 고객이 겪는 일은 문제 자체보다 침묵입니다. 결제가 두 번 빠져나갔다는 메일을 보낸 사람은 몇 시간 동안 그 메일이 도착하기는 했는지조차 알 수 없습니다. 그래서 같은 내용을 채팅으로 한 번 더 쓰고, 그래도 조용하면 전화를 겁니다. 문의는 한 건에서 세 건으로 늘어나고 지원팀은 더 바빠집니다.

지원팀 안에서도 답할 말이 없었습니다. "요즘 대응이 느린 것 같다" 는 말에 담당자는 "그럴 리가요, 다 그날 안에 답하는데요" 하고 답하고, 양쪽 다 근거가 없으니 대화가 거기서 끝납니다. 어제 들어온 문의 중 몇 건이 아직 답을 못 받았는지 아무도 대지 못하는 상태였습니다.

첫 응답 시간은 이 침묵의 길이를 숫자로 만든 것입니다. 문제를 풀었는지가 아니라 반응했는지를 따로 떼어 재는 게 핵심적인 선택입니다. 원인 파악에 이틀이 걸리는 문의라도 10분 만에 "확인하고 있습니다" 라는 답이 가면 고객은 기다릴 수 있습니다. 해결과 반응은 다른 일이고, 그중 반응은 실력과 상관없이 바로 개선할 수 있습니다.

문의 한 건마다 접수된 시각과 첫 답변이 나간 시각의 차이를 구하고, 그 값들을 한 기간에 걸쳐 모아 대표값을 냅니다.

세는 단위는 지원 티켓 한 건입니다. 지원 티켓은 접수된 문의 하나를 번호와 담당자와 상태를 달아 관리하는 단위인데, 이게 없으면 같은 고객의 세 번째 메일이 새 문의인지 앞 문의의 재촉인지 구분되지 않아 숫자가 흐려집니다.

계산은 세 단계입니다.

1. 시작 시각을 정합니다. 고객이 메일을 보내거나 채팅 창에 첫 메시지를 남긴 시각입니다.
2. 끝 시각을 정합니다. 담당자가 그 문의에 처음 답을 보낸 시각입니다. "접수되었습니다" 라는 자동 회신은 여기 들어가지 않습니다. 자동 회신을 세면 모든 문의의 첫 응답 시간이 1초가 되어 이 숫자는 아무것도 재지 않게 됩니다.
3. 두 시각의 차이를 건마다 구해 한 달치를 모으고 대표값을 냅니다. 10분·25분·40분·2시간·9시간이 나왔다면 가운데 값인 40분이 대표값입니다.

대표값으로는 평균보다 중앙값을 씁니다. 평균은 한 건의 극단값에 끌려다닙니다. 위 다섯 건의 평균은 2시간 27분인데, 이건 다섯 건 중 네 건의 실제 경험보다 훨씬 나쁜 숫자입니다.

영업시간을 어떻게 다룰지도 미리 정합니다. 금요일 저녁 7시에 들어온 문의에 월요일 오전 10시에 답하면 시계로는 63시간이지만, 평일 9시부터 6시까지만 세는 방식으로는 1시간입니다. 24시간 지원을 약속했으면 시계 시간으로 세고, 영업시간만 운영하면 영업시간으로 셉니다. 두 방식을 섞으면 지난달과 이번 달을 비교할 수 없습니다.

기준선은 채널이 정합니다. 채팅 창구에서는 고객이 화면 앞에 앉아 기다리고 있으므로 2분을 넘기면 대화가 끊긴 것처럼 느껴지고, 메일은 몇 시간 뒤에 받아도 자연스럽습니다. 같은 팀에서 채팅 1분과 메일 4시간이 동시에 좋은 값일 수 있습니다.

절대값보다 약속 대비 달성률을 먼저 봅니다. 지원 응답 약속은 몇 시간 안에 첫 답을 주겠다고 미리 정해 둔 기준입니다. 4시간을 약속했다면 볼 숫자는 평균 2시간이 아니라 "네 시간 안에 답한 비율 94퍼센트" 쪽입니다. 평균이 좋아도 열 건 중 한 건이 하루를 넘기면 그 한 건이 환불 요청이 됩니다.

그래서 분포를 함께 봅니다. 중앙값 40분에 95번째 백분위수 9시간이라는 조합은, 대부분 빠르지만 스무 건 중 한 건은 반나절을 방치된다는 뜻입니다. 꼬리가 길어지는 자리는 대개 정해져 있습니다. 주말과 야간, 담당자가 한 명뿐인 언어권, 아무도 자기 일이라고 생각하지 않는 애매한 문의입니다.

숫자가 나쁘면 사람을 더 뽑기 전에 들어오는 양을 먼저 봅니다. 같은 질문이 반복되고 있으면 도움말 센터에 문서 하나를 올려 그 문의를 아예 줄이는 쪽이 빠르고, 답변 문장이 매번 비슷하면 매크로로 저장해 두면 됩니다. 매크로는 자주 쓰는 답변을 템플릿으로 저장해 두고 고객 상황에 맞는 부분만 고쳐 보내는 장치입니다.

"첫 응답 시간 중앙값은 30분인데 95퍼센타일이 8시간이에요. 야간 문의가 다 거기 몰려 있습니다."

평균만 보면 괜찮아 보이지만 특정 시간대가 방치되고 있다는 보고입니다.

"자동 회신 말고 사람이 답한 시각으로 다시 뽑아 주세요."

지금 숫자가 실제 응답이 아니라 시스템 회신을 세고 있다는 지적입니다.

"이번 달은 첫 응답만 지키고 해결 시간은 목표를 못 맞췄어요."

빠르게 반응은 했지만 끝까지 처리하는 데는 오래 걸렸다는 뜻입니다.

페이지덱에서는 수아가 매주 월요일에 이 숫자를 가져옵니다. 채팅 중앙값이 3분에서 11분으로 늘어난 주가 있었는데, 특정 기능의 오류 문의가 한꺼번에 들어와 한 사람이 그 건들만 붙들고 있던 날이 원인이었습니다. 수아는 인원을 늘리자고 하는 대신 태오에게 그 오류의 수정 일정을 물었습니다.

기업 고객이 걸린 문의는 따로 봅니다. 계약서에 응답 시간이 적혀 있는 고객의 문의가 대기 줄 뒤쪽에 서 있으면 그건 단순히 늦은 게 아니라 약속을 어기는 중이라서, 규원이 분기마다 확인하는 항목에 들어 있습니다.

첫 응답 시간이 짧으면 지원을 잘하고 있다고 읽는 경우가 가장 많습니다. 고객이 가장 먼저 겪는 숫자이니 그렇게 보이는 게 자연스럽습니다. 하지만 이 값은 반응 속도만 재고 문제가 풀렸는지는 재지 않습니다. 이 숫자만 목표로 걸면 담당자는 "확인 후 안내드리겠습니다" 를 먼저 보내고 실제 조사는 나중에 시작하는 쪽으로 움직입니다. 반년 뒤에는 첫 응답 시간이 40분에서 8분으로 줄어든 채 고객 불만은 그대로이거나 늘어난 상태가 됩니다. 그래서 이 값은 언제나 해결 시간과 함께 봅니다.

값이 나쁠 때 원인이 지원팀에 있다고 보는 것도 흔한 오해입니다. 응답이 늦으니 답하는 사람이 느린 것처럼 보이지만, 대기 줄이 길어지는 원인은 대개 들어오는 양 쪽에 있습니다. 결제 화면 하나가 헷갈리게 생겨서 하루에 문의가 서른 건씩 들어오는 상황을 지원팀 인원으로 막으려 하면 사람을 두 배로 늘려도 숫자는 조금만 나아집니다. 반복되는 문의의 내용을 제품팀에 넘기지 않으면 이 지표는 계속 지원팀만의 숙제로 남습니다.