해결 시간

지원 조직이 처음 재기 시작한 숫자는 첫 답변까지 걸린 시간이었습니다. 재기 쉽고 개선하기도 쉽습니다. 사람을 늘리거나 근무 시간을 넓히면 곧바로 내려갑니다.

그래서 그 숫자만 보던 조직에서는 이상한 일이 생겼습니다. 첫 답변 시간은 30분으로 좋은데 고객 불만은 줄지 않습니다. 기록을 열어 보면 이유가 보입니다. 30분 안에 답장은 갔는데 내용이 확인해 보고 연락드리겠다는 문장이었습니다. 그 뒤로 나흘이 지나 있습니다.

담당자를 탓할 일도 아닙니다. 재는 숫자가 첫 답변이면 사람은 첫 답변을 맞추는 쪽으로 움직입니다. 들어온 문의에 빠르게 한 줄씩 붙이고 나면 그날의 성과가 채워지고, 실제로 푸는 일은 뒤로 밀립니다.

해결 시간은 그 뒤쪽을 재려고 만든 값입니다. 문의가 끝까지 처리됐는지를 보는 숫자여서, 첫 답변 시간과 나란히 놓고 볼 때만 뜻을 갖습니다.

문의가 접수된 시각과 해결로 닫힌 시각의 차이를 구하고, 그 값들을 모아 대표값을 냅니다.

정하고 시작할 것이 넷입니다.

1. 시작점입니다. 고객이 보낸 시각으로 잡습니다. 우리가 확인한 시각이 아닙니다. 주말에 들어온 문의를 월요일 아침부터 세면 고객이 기다린 시간이 숫자에서 사라집니다.
2. 끝점입니다. 해결됐다고 판단한 시각이 아니라 고객이 확인한 시각으로 잡는 편이 낫습니다. 담당자가 답변을 보내고 바로 닫으면, 그 답으로 안 풀려 다시 문의가 들어올 때 새 건으로 잡힙니다. 그러면 한 문제가 두 건이 되고 두 건 다 짧게 나옵니다.
3. 기다린 시간의 처리입니다. 고객에게 추가 정보를 요청하고 답을 기다린 이틀을 포함할지 정합니다. 보통 그 구간을 빼고 세는 값을 함께 둡니다. 두 값이 크게 다르면 우리 쪽이 느린 것이 아니라 정보를 한 번에 못 묻고 있다는 신호입니다.
4. 대표값입니다. 평균과 중위값이 다르게 나옵니다. 열 건이 2·3·2·4·3·2·5·3·2·90시간이었다면 평균은 11.6시간이고 중위값은 3시간입니다. 90시간짜리 한 건이 평균을 끌어올린 것이라 운영에는 중위값이 낫고, 최악의 경험을 보려면 상위 5퍼센트 값을 따로 봅니다.

문의 종류별로 나눠 세지 않으면 값이 뜻을 잃습니다. 비밀번호 초기화와 데이터 이관 요청을 한 평균에 넣으면 그 값으로는 아무것도 판단할 수 없습니다. 단순 문의, 설정 문의, 장애, 기능 요청으로 나누면 각 갈래의 값이 서로 다른 일을 가리킵니다.

절대 기준은 없습니다. 무엇을 파는지와 무엇을 약속했는지가 값을 정합니다. 몇 시간 안에 답하겠다고 정해 둔 지원 응답 약속이 있으면 그 약속이 기준선입니다. 약속이 24시간이면 중위값 3시간은 넉넉한 값이고, 약속이 4시간이면 같은 3시간이 빠듯한 값입니다.

읽을 때 보는 것은 셋입니다.

1. 갈래별 변화입니다. 같은 종류의 문의가 지난달보다 오래 걸리면 원인이 있습니다. 담당자가 줄었거나, 제품이 바뀌어 담당자가 모르는 영역이 생겼거나, 개발팀으로 넘기는 절차가 막힌 경우입니다.
2. 꼬리입니다. 중위값이 3시간인데 상위 5퍼센트가 90시간이면 소수의 고객이 아주 나쁜 경험을 하고 있습니다. 그 90시간짜리 건들을 열어 보면 대개 한 종류입니다. 개발팀 확인이 필요한 건이거나, 담당자 사이에서 세 번 넘어간 건입니다.
3. 재문의율입니다. 해결 시간이 짧아졌는데 같은 고객의 재문의가 늘었으면 빨리 닫은 것이지 해결한 것이 아닙니다. 두 값은 함께 봐야 합니다.

줄이는 방법은 담당자를 재촉하는 것이 아닙니다. 대개 셋입니다. 자주 오는 문의를 고객이 스스로 찾아 해결하도록 만들어 접수 자체를 줄이는 문의 감축, 담당자가 답을 찾을 수 있게 내부 자료를 정리하는 일, 그리고 개발팀으로 넘겨야 하는 건의 기준과 경로를 미리 정해 두는 일입니다. 세 번째가 꼬리를 가장 크게 줄입니다.

"첫 응답은 30분인데 해결은 나흘이에요. 두 숫자를 같이 봐야 합니다."

한쪽만 좋은 상태를 짚는 말입니다.

"중위값은 3시간인데 상위 5퍼센트가 90시간입니다. 그 건들만 따로 봅니다."

꼬리를 분리해 원인을 찾는 방식입니다.

"해결 시간은 줄었는데 재문의가 늘었어요. 빨리 닫은 것 같습니다."

숫자가 좋아진 이유를 의심하는 말입니다.

페이지덱에서는 수아가 문의를 넷으로 나눠 봅니다. 단순 문의, 설정 문의, 장애, 기능 요청입니다. 단순 문의는 중위값 1시간, 설정 문의는 4시간, 장애는 갈래를 따로 두어 발생부터 복구까지로 재고, 기능 요청은 이 숫자에 넣지 않습니다.

기능 요청을 뺀 이유가 있습니다. 그 갈래는 해결까지 몇 달이 걸리거나 아예 안 하기로 결정되는 건들이라, 같이 세면 평균이 무의미해지고 담당자는 그 건들을 서둘러 닫으려 합니다. 대신 기능 요청은 접수 후 며칠 안에 할지 안 할지 답했는지로 따로 봅니다.

해결 시간을 짧게 만드는 것이 목표라고 여기는 경우가 많습니다. 숫자가 작아지면 좋아 보이니 자연스럽습니다. 하지만 이 값은 닫는 버튼을 누르는 시점으로 계산됩니다. 담당자에게 이 숫자로 성과를 걸면 답이 될지 모르는 안내를 보내고 바로 닫는 쪽으로 움직입니다. 그러면 같은 문제가 새 건으로 두 번 세 번 들어오고, 각 건은 짧게 잡히고 고객은 같은 이야기를 세 번 합니다. 걸어야 할 것은 이 값 하나가 아니라 이 값과 재문의율과 만족도를 함께 본 판단입니다.

담당자를 늘리면 줄어든다고 생각하는 것도 흔합니다. 첫 응답 시간은 실제로 인원에 곧바로 반응하니 같으리라고 보는 것입니다. 그런데 해결 시간의 꼬리는 인원이 아니라 막힌 경로에서 나옵니다. 개발팀 확인이 필요한 건이 어디로 가야 하는지 정해져 있지 않으면 담당자가 열 명이어도 그 건은 나흘을 기다립니다. 인원을 늘려 줄어드는 것은 대기 시간이고, 꼬리를 줄이는 것은 절차입니다.