문의 감축
Ticket Deflection
지표
고객이 스스로 답을 찾아 접수되지 않은 문의의 비율로, 사람이 답해야 할 양 자체를 줄였는지 볼 때 씁니다.
등장 배경
지원 조직의 일은 오랫동안 들어온 것을 잘 처리하는 일로만 이해됐습니다. 그래서 재는 숫자도 처리 쪽에 있었습니다. 첫 답변이 몇 시간 뒤에 나갔는지, 한 건을 끝내는 데 며칠이 걸렸는지입니다.
그 틀에서는 사용자가 늘 때 답이 하나뿐이었습니다. 사용자가 두 배가 되면 문의도 두 배가 되니 사람을 두 배로 뽑습니다. 구성원 45명짜리 회사에서 지원 담당자가 둘에서 넷, 여덟으로 늘면 그 비용이 제품 만들 돈을 갚아먹습니다. 그런데도 노력은 문의당 처리 시간을 줄이는 쪽으로만 갔습니다. 3분짜리 답을 2분 30초로 줄이는 일입니다.
도움말 문서를 만들어 두는 회사는 있었지만 효과를 말할 방법이 없었습니다. 문서를 쓴 달에 문의가 조금 줄어든 것 같아도 그게 문서 때문인지 그달에 큰 장애가 없어서인지 가릴 수 없었습니다. 문의 감축은 그 빈자리에 숫자를 하나 놓은 것입니다. 들어온 것을 잘 처리했는지 대신 들어오지 않게 만들었는지를 봅니다. 이 값이 있으면 도움말과 챗봇에 쓴 시간이 인건비를 얼마나 아꼈는지 계산할 수 있게 됩니다.
계산 방법
세는 방식이 셋입니다. 무엇을 분모로 잡는지가 다르고, 같은 회사도 둘 이상을 함께 씁니다.
- 도움말 조회 기준. 도움말 문서를 본 방문 중 문의로 이어지지 않은 비율입니다. 한 달에 문서 조회가 4,000건이고 그 방문 중 400건이 결국 문의를 남겼다면 90퍼센트입니다.
- 사용자당 문의 기준. 활성 사용자 1,000명당 월 문의 건수를 계속 재고 그 값이 줄어든 만큼을 감축으로 봅니다. 1,000명당 42건이던 것이 여섯 달 뒤 27건이 되면 36퍼센트 줄어든 것입니다.
- 챗봇 기준. 챗봇 대화 중 사람에게 넘기지 않고 끝난 비율입니다. 챗봇은 대화 창구에서 자동으로 답하는 장치입니다. 세 방식 중 가장 깔끔하게 세어지는데, 챗봇을 거치지 않고 메일로 오는 문의는 아예 계산에 안 들어갑니다.
1번에는 함정이 있습니다. 문의로 이어지지 않은 방문을 해결된 것으로 세지만, 실제로는 답을 못 찾고 포기한 경우도 여기 들어갑니다. 그 둘을 가르려면 다른 신호를 함께 봐야 합니다. 같은 사람이 같은 문서를 사흘 안에 세 번 다시 보는지, 그 방문 뒤에 제품을 아예 안 쓰게 되는지, 문서 끝에 붙인 도움이 됐는지 묻는 버튼에 어떻게 답하는지입니다.
어느 방식을 쓰든 지원 티켓 기록이 기준선을 줍니다. 지원 티켓은 접수된 문의 한 건입니다. 지난 여섯 달 동안 유형별로 몇 건이 들어왔는지가 있어야 줄었다는 말을 할 수 있습니다.
좋은 수준의 기준
절대 기준은 없습니다. 제품이 복잡하고 고객사마다 설정이 다른 제품은 애초에 스스로 풀 수 있는 문의의 비율이 낮습니다. 개인이 혼자 쓰는 단순한 도구는 대부분의 질문이 이미 나와 있는 답이라 수치가 높게 나옵니다. 그래서 다른 회사 숫자와 견주는 것은 쓸모가 적습니다.
대신 자기 값의 추세를 봅니다. 두 번째 방식이 여기에 맞습니다. 사용자당 문의 건수가 여섯 달 전보다 줄었으면 좋아진 것이고, 사용자가 늘면서 그 값이 유지되기만 해도 지원 인원을 비례해 늘리지 않아도 된다는 뜻입니다.
유형별로 나눠 봐야 합니다. 전체 감축률 하나는 무엇을 더 쓸지 알려 주지 않습니다. 페이지덱의 문의 유형 일곱 개 중 계정 초대와 청구서 재발급은 문서로 90퍼센트가 풀립니다. 반면 연동하다 막힌 문의는 20퍼센트도 안 풀립니다. 뒤쪽은 문서를 더 써도 줄지 않으니 제품을 고쳐야 합니다.
같이 볼 값은 첫 응답 시간입니다. 첫 응답 시간은 문의가 들어온 뒤 사람이 처음 답할 때까지 걸린 시간입니다. 감축이 오르면 남은 문의에 쓸 시간이 늘어 이 값이 짧아집니다. 감축은 올랐는데 첫 응답 시간이 그대로면 줄어든 것이 쉬운 문의뿐이거나, 줄어든 만큼 인원을 먼저 줄인 경우입니다.
실무 용례
"지난 분기에 도움말 열두 편 썼는데 1,000명당 문의가 42건에서 34건으로 줄었습니다."
문서 작업의 효과를 숫자로 보고하는 말입니다.
"감축률 92퍼센트는 좋은 게 아닐 수 있습니다. 문의 버튼을 찾기 어렵게 만든 건 아닌지 보죠."
높은 값을 의심하는 질문입니다.
"연동 문의는 문서로 안 줄어요. 그건 제품에서 풀어야 합니다."
문서로 풀릴 유형과 아닌 유형을 가르는 판단입니다.
페이지덱에서는 지현이 분기마다 문의를 유형별로 세어 어느 유형에 문서를 쓸지 정합니다. 기준은 두 가지입니다. 건수가 많고, 답이 항상 같은 유형입니다. 지난 분기에는 계정 초대 관련 문의가 월 180건이었고 답이 거의 같아서 여기에 문서 셋과 자주 묻는 질문 항목 여섯 개를 붙였습니다. 자주 묻는 질문은 반복되는 질문과 답을 짧게 모아 둔 문서입니다.
두 달 뒤 그 유형 문의가 월 60건으로 줄었습니다. 지현이 함께 확인한 것은 초대 기능 자체의 사용 완료율입니다. 문의만 줄고 기능을 끝까지 쓰는 비율이 같이 떨어졌다면 사람들이 물어보기를 포기한 것이라, 그때는 문서가 아니라 화면을 고쳐야 합니다.
흔한 오해
감축률이 높으면 무조건 좋다고 보는 경우가 가장 많습니다. 문의가 적을수록 잘 만든 제품처럼 보이니 자연스러운 오해입니다. 다만 이 값은 문의를 어렵게 만들어도 올라갑니다. 문의하기 버튼을 세 번 클릭 뒤에 두거나 도움말을 다 읽어야 열리게 하면 접수 건수는 줄어듭니다. 줄어든 것은 문의이고 남은 것은 해결되지 않은 문제라서, 다음 갱신 시점에 이유 없이 떠나는 고객으로 돌아옵니다. 그래서 이 값은 혼자 보지 않고 만족도와 갱신율과 함께 봅니다.
도움말을 많이 쓰면 감축된다고 보는 것도 흔합니다. 문서 수가 늘면 답이 있는 질문도 늘어날 것처럼 계산됩니다. 하지만 찾아지지 않는 문서는 없는 문서와 같습니다. 고객은 제품 기능 이름을 모르는 상태로 검색창에 자기 말로 칩니다. "구성원 권한 관리" 라고 제목을 달아 둔 문서는 "다른 사람 초대하는 법" 이라고 검색한 사람에게 나오지 않습니다. 그래서 문서를 쓸 때 실제 문의에 적힌 표현을 그대로 제목과 본문에 넣습니다. 문서를 쉰 편 쓰고도 감축이 움직이지 않는 경우는 대개 제목이 우리 말로 되어 있을 때입니다.
자주 헷갈리는 용어
| 용어 | 무엇인가 | 문의 감축과의 차이 |
|---|---|---|
| 도움말 센터 | 고객이 스스로 찾아볼 수 있게 정리한 문서 모음 | 수단입니다. 문의 감축은 그 수단이 실제로 통했는지를 재는 숫자입니다 |
같이 보면 좋은 페이지
연관 용어
마지막 업데이트 2026-09-16