지원 티켓 보고서 작성 방법: 단계별 가이드

고객 지원 티켓 보고서는 대부분 정의의 문제입니다. 생성된 티켓, 해결된 티켓, 최초 답변 시간, 해결 시간 등은 모두 직관적으로 보이지만, 이들 각각은 동일한 헬프 데스크 내에서도 두 가지 이상의 공식적인 의미를 가지고 있습니다.

집계 규칙을 명확히 정의하면 보고서는 저절로 작성됩니다. 이 단계를 건너뛰면 정직한 두 사람이 동일한 데이터를 내보내더라도 몇 시간씩 차이가 나는 결과를 얻게 될 것입니다.

이 가이드에서는 보고서에 포함되어야 할 내용, 정의가 갈라지는 네 가지 지점, 그리고 티켓 내보내기 데이터를 통해 보고서를 작성하는 방법을 다룹니다.

고객 지원 티켓 보고서에 포함되어야 할 내용

단순한 수치만으로는 거의 아무것도 알 수 없습니다. 숫자를 안전하게 해석할 수 있게 만드는 것은 바로 데이터의 구성 방식입니다.

요소	포함해야 하는 이유
해당 기간 내 생성된 티켓	수요 측면
해당 기간 내 해결된 티켓	공급 측면 (명시된 상태 규칙 기준)
기간 말 기준 백로그	해결되거나 종결되지 않은 모든 티켓
최초 답변 시간	명시된 기준 시간 및 정의 적용
해결 시간	최초 해결 또는 최종 해결 여부를 명시적으로 지정
재오픈된 티켓	다른 수치들이 숨기고 있는 품질 신호
답변되지 않은 티켓	프로세스가 완전히 실패한 지점
명시된 날짜 기준 및 범위	포함된 채널, 브랜드 및 대기열

두 개의 행은 겉보기보다 훨씬 더 큰 무게감을 가집니다. 재오픈된 티켓과 답변되지 않은 티켓은 보고서가 단순히 점수판에 그치지 않고 실질적으로 유용해지는 지점입니다.

Zendesk는 기본 공식을 공개하므로 정의를 주관적인 의견이 아닌 검증 가능한 사실로 만들어 줍니다. Zendesk의 지표 및 속성 참조 문서에서 각 항목을 확인할 수 있습니다.

가장 간단한 것부터 시작해 보겠습니다. 해결된 티켓은 "해결됨 또는 종결됨 상태의 티켓 수"를 의미하므로, 이 지표는 단일 상태가 아닌 두 가지 상태를 모두 아우릅니다.

"최초 답변 시간"에는 두 가지 공식 정의가 있습니다

이 부분은 가장 많은 이견이 발생하는 지점이며, 솔루션 제공업체에서도 이에 대해 직접 경고하고 있습니다.

Zendesk의 SLA 문서에는 단 한 줄로 이렇게 명시되어 있습니다. "SLA 답변 시간과 Zendesk 기본 답변 시간 지표를 혼동하지 마십시오."

기본 지표는 누가 답변하는지에 대해 엄격합니다. Zendesk는 "최초 답변 시간은 상담사의 답변만을 기준으로 계산된다"고 명시하고 있습니다. 자동화 및 봇 관련 작업은 "최초 답변 시간을 계산할 때 고려되지 않습니다."

반면 SLA 지표는 그렇지 않습니다. SLA에서 최초 답변 시간은 "티켓 생성 시점부터 상담사의 첫 번째 공개 댓글(또는 자동 답변)이 등록될 때까지의 시간"입니다. Zendesk는 "공개 댓글로 자동 답변을 보내는 트리거를 설정하면 답변 시간 지표가 충족된다"고 덧붙입니다.

이 두 가지를 함께 읽어보면 그 결과는 극명합니다. 자동 응답기는 SLA 목표를 충족할 수 있지만, Zendesk 기본 최초 답변 시간은 계속해서 흘러가게 됩니다.

따라서 SLA 달성률 98%와 최초 답변 시간 중앙값 4시간을 보여주는 보고서가 서로 모순되는 것은 아닙니다. 두 가지 서로 다른 항목을 각각 올바르게 보고하고 있는 것뿐입니다.

알아두면 좋은 두 가지 사소한 예외가 있습니다. 상담사가 티켓을 생성하고 첫 번째 댓글이 공개인 경우를 예로 들어 보겠습니다. 소요 시간 지표 참조 문서에 따르면, 두 번째 타임스탬프는 "상담사의 두 번째 공개 댓글로 이동"합니다.

또한 공유된 티켓은 계산에 포함되지 않습니다. Zendesk는 상담사가 티켓 공유 기능을 사용하여 다른 계정에서 공개 댓글을 작성하는 경우, "이는 해당 계정의 최초 답변 시간에 반영되지 않는다"고 설명합니다.

"해결 시간" 역시 두 가지 정의가 있습니다

해결 지표에서도 동일한 구분이 적용되며, 여기서는 두 버전 모두 기본적으로 제공됩니다.

최초 해결 시간은 "티켓 생성 시점부터 최초 해결까지의 소요 시간"이며, "티켓 상태가 처음으로 해결됨으로 설정된 시점"에 종료됩니다.

최종 해결 시간은 "티켓 생성 시점부터 가장 최근 해결까지의 소요 시간"입니다. 이는 "티켓 상태가 마지막으로 해결됨으로 설정된 시점"에 종료됩니다.

한 번만 해결된 티켓의 경우 두 수치는 동일합니다. 하지만 해결되었다가 재오픈된 후 다시 해결된 티켓의 경우, 두 번째 해결 과정에 소요된 시간만큼 두 수치 사이에 차이가 발생합니다.

이것이 바로 재오픈된 티켓을 보고서에 포함해야 하는 이유입니다. Zendesk는 이를 "해결된 후 다시 오픈된" 티켓으로 정의하며, 이 지표에는 "동일한 업데이트 과정에서 해결된 후 바로 재오픈된 티켓은 포함되지 않는다"고 명시하고 있습니다.

사람들이 흔히 놓치는 이차적인 영향도 있습니다. 해결된 티켓의 일일 평균은 "현재 해결됨 또는 종결됨 상태인 경우에만" 집계됩니다. 따라서 오늘 재오픈된 티켓은 지난달의 해결된 티켓 수에서 조용히 제외됩니다.

결과적으로 6월에 실행한 보고서의 수치는 8월에 다시 실행했을 때 동일하게 나타나지 않을 수 있습니다. 시스템 오류가 아니라, 데이터의 기본 상태가 변경되었기 때문입니다.

대기 시간과 작업 시간을 구분하는 두 가지 지표가 더 있습니다. 요청자 대기 시간은 신규, 등록, 보류 상태에 머문 시간의 합계이며, 상담사 대기 시간은 대기 중 상태에 머문 시간의 합계입니다.

이 두 지표는 평균 해결 시간만으로는 답할 수 없는 질문에 대한 해답을 제공합니다. 고객의 답변을 기다리느라 해결 시간이 길어진 것과 대기열이 밀려서 해결 시간이 길어진 것은 완전히 다른 문제입니다.

캘린더 시간 또는 업무 시간

모든 답변 및 해결 수치는 두 가지 기준 시간을 기반으로 존재하며, 이 중 하나를 선택하는 것은 필수적입니다.

Zendesk는 두 가지를 모두 저장합니다. 첫 번째 공개 답변이 등록된 후, "시스템은 최초 답변 시간을 캘린더 시간과 업무 시간 기준으로 각각 계산"합니다. 두 지표 모두 "티켓 데이터와 함께 저장"됩니다.

기본적으로 표시되는 화면은 중립적이지 않습니다. Zendesk는 기본 제공되는 Explore 보고서가 "캘린더 시간 기준으로 정보를 표시한다"고 설명합니다. 업무 시간 지표는 "직접 만드는 보고서에서 사용 가능"합니다.

따라서 오전 9시부터 오후 5시까지 근무하는 팀은 기본 보고서에서 성과가 느린 것처럼 보일 수 있습니다. 금요일 오후 6시에 접수된 티켓은 월요일 아침이 되기 전까지 약 63시간의 캘린더 시간이 누적되지만, 업무 시간 기준으로는 거의 0시간에 가깝습니다.

실시간 대화 채널에는 한 가지 복잡한 문제가 더 있습니다. 메시징 및 채팅의 최초 답변 시간(초) 지표는 "설정된 메시징 업무 시간 및 실시간 채팅 운영 시간 설정을 무시"합니다.

또한 채팅 답변 시간 SLA는 선택 사항입니다. Zendesk는 실시간 채팅의 답변 시간 SLA가 "기본적으로 비활성화되어 있다"고 명시하고 있으므로, 해당 지표가 보이지 않는 것은 완벽한 성과를 거두어서가 아니라 단지 설정이 꺼져 있기 때문일 수 있습니다.

수동으로 보고서를 작성하는 방법

옵션 1: 지표 그룹별로 탭 나누기

지표 필드가 포함된 티켓 목록을 내보낸 다음, 데이터를 요약하기 전에 수량, 답변 시간, 해결 시간을 각각 별도의 탭으로 분리합니다.

데이터를 내보낼 때 한 가지만 선택하지 말고 캘린더 시간과 업무 시간 열을 나란히 유지하세요. 나중에 다른 기준의 데이터를 요구받게 될 것입니다.

시간 지표의 경우 평균값 대신 중앙값을 계산하세요. 연휴 동안 열려 있던 소수의 티켓이 평균값을 크게 왜곡하여 실제 상황과 전혀 맞지 않는 수치를 만들어낼 수 있습니다.

스프레드시트의 한계는 상태 변경 이력을 볼 수 없다는 점입니다. 각 티켓의 현재 상태만 제공되므로, 재오픈 동작은 이력 재구성이 아닌 재오픈 횟수 데이터를 통해 파악해야 합니다.

옵션 2: 정의 탭을 먼저 작성하기

답변 시간 정의, 기준 시간, 해결 지표, 해결됨 상태 규칙, 대상 채널, 날짜 기준을 먼저 기록해 둡니다.

그런 다음 보고서가 보장하지 않는 사항도 기록하세요. SLA 달성률과 기본 최초 답변 시간이 서로 다른 것을 측정한다는 점을 명시해 두면, 동료가 이 두 가지를 동일한 수치로 오인하여 인용하는 것을 방지할 수 있습니다.

이 방법의 한계는 늘 그렇듯 규칙을 문서화하는 것과 실제로 적용하는 것은 다르다는 점입니다. 다음 분기가 되면 누군가는 기억에 의존해 피벗 테이블을 다시 만들고 있을 것입니다.

옵션 3: 평균을 내기 전에 세분화하기

시간 지표를 계산하기 전에 채널별로 데이터를 분류하세요. 이메일, 채팅, 전화 티켓은 작동 방식이 완전히 다르므로, 이를 혼합한 중앙값은 그 어떤 채널의 실제 상황도 대변하지 못합니다.

그런 다음 수치를 왜곡하는 티켓을 제외하거나 표시해 두세요. 몇 주 동안 고객의 답변을 기다리고 있는 티켓은 해결 시간 평균에 포함하기보다 별도의 항목으로 분류해야 합니다.

제외된 항목과 그 수량을 명시하세요. 필터링 기준을 보지 못하는 독자는 아무런 필터도 적용되지 않았다고 생각할 것입니다.

한계점은 세분화할수록 작업량이 배로 늘어난다는 것입니다. 3개의 채널, 2개의 기준 시간, 2개의 해결 지표만 곱해도 관리해야 할 숫자가 12개나 됩니다.

공통적인 한계. 세 가지 옵션 모두 내보낸 데이터가 모든 대기열에 대해 동일한 날짜 기준과 단일 날짜 범위를 다루고 있다고 가정합니다. 탭마다 날짜 범위가 섞이는 것은 이 보고서에서 가장 흔히 발생하는 보이지 않는 오류입니다.

수동 방식의 한계와 지체되는 지점

첫 번째 고객 지원 티켓 보고서를 작성하는 데는 반나절이 걸립니다. 하지만 네 번째 보고서를 작성할 때는 더 오랜 시간이 걸리는데, 그 사이에 헬프 데스크의 설정이 변경되었기 때문입니다.

새로운 채널이 활성화되면 성과와 무관한 이유로 혼합 중앙값이 변동됩니다. 새로운 지역을 위해 업무 시간이 수정되면, 과거의 모든 업무 시간 수치도 함께 변경됩니다.

여기에 재오픈 효과까지 더해집니다. 지난 분기의 수치가 더 이상 재현되지 않으며, 그 이유를 설명하는 데 보고서를 처음부터 다시 만드는 것보다 더 많은 시간이 걸리게 됩니다.

압박을 받는 상황에서만 드러나는 네 번째 비용도 있습니다. 누군가 이번 분기에 고객 지원 속도가 빨라졌는지 묻는다면, 정직한 답변을 하기 위해 먼저 기준 시간, 정의, 채널 구성 비율을 명확히 밝혀야 합니다.

동일한 맥락에서 만족도 측면을 살펴보려면 NPS 보고서 작성 방법 가이드를 참조하세요. 티켓 수량 자체가 문제라면, 문의 편향 측면을 다룬 사전 판매 고객 지원을 위한 AI 에이전트 구축 방법 가이드를 확인해 보세요.

Powerdrill Bloom으로 보고서를 작성하는 방법

Step 1: 내보낸 티켓 데이터 업로드하기

내보낸 티켓 데이터 또는 티켓 및 SLA 데이터를 함께 업로드합니다. Powerdrill Bloom은 데이터를 수신하는 즉시 열의 프로필을 분석하므로, 중앙값을 계산하기 전에 빈 타임스탬프, 혼합된 날짜 형식, 최초 답변이 누락된 티켓 등을 먼저 감지해 냅니다.

Step 2: 자연어로 보고서 설명하기

규칙을 다시 설계하는 대신 정의를 그대로 입력하세요. 답변 시간 정의, 기준 시간, 원하는 해결 지표, 해결됨 상태 규칙, 대상 채널을 지정합니다.

그런 다음 오류를 잡아낼 수 있는 질문을 던지세요. 상담사 답변이 전혀 없는 티켓은 몇 개인지, 어떤 티켓이 재오픈되었는지 물어보세요. 단일 혼합 수치 대신 채널별 중앙값을 요청하세요.

Step 3: 차트, 보고서 또는 프레젠테이션 덱 내보내기

채널별 지표 테이블이나 백로그 데이터가 포함된 생성 대비 해결 티켓 차트를 추출합니다. 숫자 옆에 정의가 함께 표시되는 슬라이드도 한 번에 생성할 수 있습니다.

흔히 하는 실수들

SLA 달성률을 최초 답변 시간으로 인용하는 것. 하나는 자동 답변을 인정하는 반면, 다른 하나는 자동화된 작업을 완전히 제외합니다.

캘린더 시간과 업무 시간을 비교하는 것. 기본 보고서는 전자를 제공하지만, 목표는 아마도 후자를 기준으로 설정되었을 것입니다.

답변 및 해결 시간에 평균값을 사용하는 것. 방치된 소수의 티켓이 평균값을 왜곡하여 실제 상황과 전혀 맞지 않는 수치를 만들어냅니다.

채널을 혼합하는 것. 채팅과 이메일의 중앙값은 구조적으로 다를 수밖에 없으며, 이를 혼합하면 두 채널의 특성이 모두 가려집니다.

어떤 해결 시간인지 명시하지 않고 보고하는 것. 최초 해결 시간과 최종 해결 시간은 반올림 오차 같은 변형이 아니라 서로 다르게 저장되는 별개의 지표입니다.

해결된 티켓 수를 최종 수치로 취급하는 것. 해결된 티켓 수에는 현재 해결됨 또는 종결됨 상태인 티켓만 포함되므로, 재오픈이 발생하면 과거의 수치가 변경됩니다.

답변되지 않은 티켓을 제외하는 것. 이는 상담사 답변이 1회 미만인 티켓으로 정의되며, 보고서가 드러낼 수 있는 가장 명백한 프로세스 실패 사례입니다.

결론

답변 정의를 명시하고, 기준 시간을 지정하고, 최초 또는 최종 해결 여부를 선택하고, 상태 규칙을 명확히 하고, 채널별로 세분화하고, 재오픈 및 답변되지 않은 티켓을 보여주세요. 그래야 비로소 실질적인 조치를 취할 수 있는 고객 지원 티켓 보고서가 완성됩니다.

이 보고서로 할 수 없는 일은 다른 회사의 수치와 단순 비교하는 것입니다. 정의는 설정하기 나름이므로, 어딘가에서 읽은 벤치마크 수치는 거의 확실히 다른 규칙을 기준으로 측정되었을 것입니다.

대신 고정된 규칙 세트를 바탕으로 자사의 과거 이력과 비교하여 추적하세요. 그래야 실제로 개선이 이루어지고 있는지 정확히 파악할 수 있습니다.

매달 보고서를 다시 작성하느라 하루를 꼬박 허비하고 있다면, 내보낸 티켓 데이터를 활용해 Powerdrill Bloom을 사용해 보세요. AI report generator 페이지와 voice of customer summarizer 페이지도 함께 확인해 보시기 바랍니다.

자주 묻는 질문

SLA 달성률이 최초 답변 시간과 일치하지 않는 이유는 무엇인가요?

두 지표는 서로 다른 이벤트를 측정합니다. Zendesk의 SLA 최초 답변 시간은 자동 답변으로도 충족될 수 있는 반면, 기본 최초 답변 시간 지표는 자동화 및 봇 작업을 완전히 제외합니다.

최초 해결 시간과 최종 해결 시간 중 어떤 것을 보고해야 하나요?

보고서에 명시한 기준에 따라 보고하세요. 최초 해결 시간은 티켓이 처음으로 해결됨 상태로 설정될 때 종료됩니다. 최종 해결 시간은 마지막으로 해결됨 상태로 설정될 때 종료되므로, 재오픈된 티켓이 있을 경우 두 수치 사이에 차이가 발생합니다.

고객 지원 지표는 캘린더 시간과 업무 시간 중 어느 것으로 측정되나요?

두 가지 모두 저장됩니다. Zendesk의 기본 제공 Explore 보고서는 캘린더 시간을 표시하며, 직접 작성하는 보고서에서는 업무 시간 지표를 사용할 수 있습니다.

지난 분기의 해결된 티켓 수가 변경된 이유는 무엇인가요?

해결된 티켓 수에는 현재 해결됨 또는 종결됨 상태인 티켓만 포함됩니다. 해당 기간이 종료된 후 티켓이 재오픈되면 해당 기간의 집계에서 제외됩니다.

자사의 해결 시간을 업계 벤치마크와 비교할 수 있나요?

대략적인 비교만 가능합니다. 정의, 기준 시간, 채널 구성 비율은 모두 설정에 따라 달라지므로, 공개된 벤치마크 수치는 귀사의 기준과 다른 규칙으로 측정되었을 가능성이 매우 높습니다.