최초 응답 시간 보고서 작성 방법: 완벽 가이드

최초 답변 시간(First response time)은 고객이 티켓을 접수한 시점부터 첫 번째 상담원의 답변을 받기까지 대기하는 시간입니다. 최초 답변 시간 보고서는 평균값 대신 중앙값과 90분위수로 나누어 주간 대기 시간을 추적합니다. 두 개의 타임스탬프가 포함된 티켓 내보내기 파일만 있으면 프롬프트 하나 또는 수식 세 개로 이 보고서를 만들 수 있습니다.

측정은 간단합니다. 하지만 보고 단계에서 팀들은 자신도 모르게 잘못된 판단을 내리곤 합니다. 기본 통계치와 기본 백분위수 함수 모두 가장 오래 대기한 고객들을 감추기 때문입니다.

최초 답변 시간의 의미와 계산 방법

최초 답변 시간(FRT)은 티켓이 접수된 시점부터 상담원이 고객에게 첫 번째 답변을 보낼 때까지 경과한 시간입니다. 수식은 보이는 것처럼 매우 간단합니다.

최초 답변 시간 = 첫 번째 사람의 답변 타임스탬프 − 티켓 생성 타임스탬프

두 가지 의사결정을 거쳐야 이 한 줄짜리 수식을 팀원 모두가 실제로 동의할 수 있는 지표로 만들 수 있습니다.

자동 접수 확인 메일도 포함해야 할까요? 포함해서는 안 됩니다. "메시지가 접수되었습니다"라는 자동 회신은 질문에 대한 답변이 아닙니다. 이를 포함하면 차트는 아름답게 나오겠지만 고객은 불만을 갖게 됩니다. 이는 대개 의도적인 기만이라기보다는 단순한 실수이며, FRT가 왜곡되어 좋게 보이는 가장 흔한 원인입니다.

업무 시간 외의 시간도 포함해야 할까요? 달력 기준 시간으로 계산하면 금요일 저녁에 접수되어 월요일 아침에 답변한 티켓은 60시간 동안 방치된 실패 사례가 됩니다. 하지만 영업 시간 기준으로 계산하면 1시간 미만이 될 수 있습니다. 둘 다 틀린 것은 아닙니다. 다만 동료와 서로 다른 기준으로 이야기할 때 갈등이 시작됩니다.

평균 FRT는 세 번째 결정 사항이며, 대부분의 도구가 알아서 결정해 주는 부분입니다. 답변 시간은 오른쪽으로 치우친 분포(right-skewed)를 보입니다. 즉, 대부분의 티켓은 빠르게 처리되지만 극소수의 티켓은 아주 오랫동안 대기합니다. 이 때문에 평균값은 거의 아무도 실제로 경험하지 못한 수치로 끌려 올라가게 됩니다. 대신 중앙값과 90분위수를 보고서에 사용하세요.

시작하기 전에 필요한 것

• 대화당 한 행으로 구성된 티켓 내보내기 파일.
• 두 개의 타임스탬프: 티켓 접수 시간 및 상담원의 최초 답변 시간.
• 자동 접수 확인 및 내부 메모를 제외한 "최초 답변"의 정의.
• 영업 시간 기준으로 보고서를 작성하려는 경우, 고객 지원 운영 시간.
• 데이터가 부족한 주에 그럴듯해 보이는 엉터리 수치가 나오지 않도록 하기 위한 최소 데이터양 규칙.

무언가를 만들기 전에 마지막 세 가지를 먼저 결정하세요. 나중에 이를 변경하면 차트의 이전 주 데이터가 모두 무효화되며, 기준이 계속 바뀌는 추세선은 추세선이 없는 것보다 못합니다.

스프레드시트에서 보고서를 만드는 방법

옵션 1: 두 개의 타임스탬프를 소요 시간으로 변환하기

최초 답변 타임스탬프에서 접수 타임스탬프를 빼고 결과를 시간 형식으로 지정합니다. 이것이 달력 기준 시간으로 계산한 각 티켓의 가공되지 않은 최초 답변 시간입니다.

대신 영업 시간 기준이 필요한 경우 보통 NETWORKDAYS.INTL 함수부터 시작합니다. Microsoft의 공식 문서에는 이 함수가 반환하는 값이 명확하게 설명되어 있습니다. 이 함수는 주말에 해당하는 요일을 지정하는 매개변수를 사용하여 "두 날짜 사이의 전체 작업 일수"를 제공합니다. 주말 및 휴일 인수에 지정된 날짜는 "작업 일수로 간주되지 않습니다."

'전체 작업 일수'라는 문구에 주목하세요. 이 함수는 시간이 아닌 일 단위로 결과를 반환하므로, 한 근무 교대 시간 내에서 4시간을 대기한 것과 7시간을 대기한 것이 동일하게 표시됩니다. 하루 미만의 소요 시간을 계산하려면 작업 일수와 하루 중 남은 시간을 결합하는 구조가 필요합니다. 이것이 바로 영업 시간 기준 보고서 작성이 단순한 수식 적용을 넘어 하나의 프로젝트가 되는 이유입니다.

옵션 2: 중앙값 및 90분위수 계산하기

MEDIAN 함수는 일반적인 대기 시간을 보여줍니다. 꼬리 부분(긴 대기 시간)의 경우 Excel은 두 가지 백분위수 함수를 제공하는데, 여기서 동일한 데이터에 대해 서로 다른 두 가지 결과가 나올 수 있습니다.

PERCENTILE.EXC 함수는 "0에서 1 사이(0과 1 제외)의 범위"에서 k 값을 허용합니다. 관련 문서에 따르면 "k가 1/(n + 1)의 배수가 아니면 PERCENTILE.EXC는 보간을 수행하여 k번째 백분위수 값을 결정합니다." PERCENTILE.INC 함수는 "0에서 1 사이(0과 1 포함)의 범위"에서 k를 허용하며, k가 "1/(n - 1)의 배수가 아닐 때" 보간을 수행합니다.

분모가 다르고, 보간법이 다르며, p90 결과도 달라집니다. 둘 다 틀린 것은 아닙니다. 이는 두 가지 관례일 뿐이며, 보고서에서 이 두 함수를 명확한 기준 없이 번갈아 사용하면 대기열의 실제 상태가 아니라 수식의 특성을 보여주는 꼴이 됩니다.

제외(exclusive) 버전에는 더 까다로운 면이 있습니다. 관련 문서에서는 "지정된 백분위수 k에 대해 보간할 수 없는 경우 Excel에서 #NUM! 오류를 반환합니다"라고 경고합니다. 데이터가 부족한 주에 특정 대기열에 티켓이 몇 개 없다면 p90 계산 자체가 실패할 수 있습니다.

옵션 3: 보고서 레이아웃 구성하기

티켓을 주 단위로 그룹화합니다. 중앙값과 p90을 두 개의 선으로 나란히 배치하고, 그 뒤에 티켓 수를 막대그래프로 추가합니다. 티켓 수는 단순한 장식이 아닙니다. 독자가 단 11개의 티켓으로 인해 발생한 일시적인 급증을 과도하게 해석하는 것을 방지해 줍니다.

그런 다음 기준 시간과 백분위수 계산 방법을 명시하는 텍스트 한 줄을 추가합니다. 이 문장이 있어야 회의에 참석하지 않은 다른 사람도 다음 분기에 동일한 보고서를 재현할 수 있습니다.

스프레드시트 방식의 한계

세 단계 중 어느 것도 어렵지 않습니다. 문제는 누군가 헬프데스크 뷰를 편집할 때마다 열 이름이 바뀌는 내보내기 파일을 가지고 매주 이 세 단계를 반복해야 한다는 점입니다.

구체적으로 다음 세 가지 번거로운 일이 반복됩니다.

답변 열이 깔끔하게 정리되어 있는 경우는 드뭅니다. 자동 접수 확인, 내부 메모, 상담원 답변이 같은 필드에 들어가는 경우가 많아 첫 번째 행이 항상 사람의 첫 번째 답변은 아닙니다. 이를 분리하는 것은 수식으로 해결할 수 없으며, 내보낼 때마다 직접 판단해야 합니다.

백분위수는 매번 결정을 내려야 합니다. 어떤 함수를 사용할지, 어떤 주에 충분한 데이터양이 확보되었는지, 데이터가 부족한 대기열에서 계산 오류가 발생할 때 무엇을 표시할지 결정해야 합니다.

영업 시간 기준은 유지 관리가 필요합니다. 고객 지원 운영 시간 기준을 적용하기로 결정하면, 모든 공휴일과 근무 교대 변경 사항을 워크북에 반영해야 합니다. 하나라도 놓치면 한 주 전체의 데이터가 왜곡됩니다.

그 결과, 보고서를 작성한 그 주에는 정확하지만 이후에는 서서히 데이터가 어긋나게 됩니다.

AI로 최초 답변 시간 보고서를 만드는 방법

1단계: 티켓 내보내기 파일 업로드

Powerdrill Bloom을 열고 헬프데스크에서 내보낸 파일을 바로 업로드합니다. Excel, CSV, PDF, 문서 파일 업로드를 지원하므로 가공되지 않은 내보내기 파일을 그대로 업로드할 수 있습니다.

자동 생성된 타임스탬프를 포함하여 모든 타임스탬프 열을 그대로 유지하세요. 어떤 답변이 계산에 반영되었는지 증명하고, 나중에 파일을 다시 내보내지 않고도 정의를 변경하는 데 필요합니다.

2단계: 기준 시간 및 원하는 통계치 지정하기

수식 대신 자연어로 측정 방식을 설명하세요. 어떤 타임스탬프에서 시간이 시작되고 어떤 답변에서 끝나는지, 주말을 포함할지 여부를 지정합니다. 그런 다음 주별 중앙값과 90분위수를 요청하고, 티켓 수도 함께 표시해 달라고 하세요.

데이터가 부족한 주에 어떻게 처리할지도 지정하세요. 최소 티켓 수 미만일 때는 백분위수 표시를 숨기도록 요청합니다. 이는 오류 셀이 표시되는 것보다 낫고, 단 4개의 행을 기준으로 그럴듯하게 계산된 숫자가 나오는 것보다 훨씬 낫습니다.

각 수치는 근거가 되는 행 데이터와 함께 제공되므로, 의심스러운 주가 있다면 논쟁할 필요 없이 데이터를 직접 열어서 확인할 수 있습니다.

3단계: 보고서 생성 및 프롬프트 저장

주간 축을 기준으로 두 개의 선과 하나의 막대 시리즈를 요청하고, 어떤 백분위수 기준이 사용되었는지 명시하는 노트를 추가합니다. 이를 이미지, 시트 또는 슬라이드로 내보냅니다.

다음 주에는 새 내보내기 파일을 업로드하고 동일한 프롬프트를 실행하기만 하면 됩니다. 정의가 고정되어 유지되므로 주간 비교가 진정한 의미를 갖게 됩니다. make graphs from Excel 페이지에서 차트 작성 방법을 직접 확인하실 수 있습니다.

최초 답변 시간 보고서에 포함되어야 할 요소

요소	포함해야 하는 이유	누락 시 발생하는 문제
중앙값 선	일반적인 고객의 대기 시간	평균값은 아웃라이어(이상치) 뒤에 숨어버림
90분위수 선	가장 느린 10% 고객의 경험	꼬리 부분(가장 오래 대기한 고객)의 고통이 보이지 않음
티켓 수 막대그래프	모든 수치 변화에 대한 맥락 제공	데이터가 적은 주가 추세로 오인됨
기준 시간 명시	달력 기준 시간 또는 영업 시간	두 팀이 서로 다른 수치를 인용함
백분위수 계산 방법 명시	재현성	보고서를 다시 만들 때 동일한 주의 수치가 달라짐
최소 데이터양 규칙	데이터가 부족한 세그먼트에 대한 정직한 보고	오류가 발생하거나 허구의 정확성이 표시됨
채널별 상세 분석	실제로 대기 시간이 가장 긴 곳이 어디인지 파악	하나의 불량한 대기열이 전체 수치를 끌어내림

실제 적용 예시

240개의 티켓이 접수된 어느 한 주를 예로 들어 보겠습니다. 평균 최초 답변 시간은 5.1시간, 중앙값은 1.4시간, p90은 19.7시간입니다.

세 수치 모두 정확합니다. 하지만 평균값은 그 누구의 실제 경험도 대변하지 못합니다. 대부분의 고객은 90분 미만으로 대기했고, 가장 느린 10%는 하루의 대부분을 대기했습니다. 평균값만 제시하면 독자는 대기열이 전반적으로 평범하다고 결론을 내리겠지만, 실제로는 대기 시간이 매우 빠르면서도 꼬리 부분(일부 지연 건)에 문제가 있는 상태입니다. 꼬리 부분의 문제를 해결하는 방법은 느린 대기열을 해결하는 방법과 다릅니다. 이것이 바로 단일 셀이 아닌 차트로 이를 구분해서 보여주어야 하는 이유입니다.

보고서를 망치지 않고 세그먼트 분류하기

다음으로 제기될 당연한 질문은 어떤 채널이나 대기열이 가장 느린가 하는 것입니다. 세그먼트별로 나누는 것은 유용하지만, 동시에 보고서가 왜곡되기 가장 쉬운 방법이기도 합니다.

보고서의 신뢰성을 유지하기 위한 두 가지 규칙이 있습니다. 주간 데이터양이 최소 기준 이상인 경우에만 세그먼트를 나누고, 독자가 기준선으로 삼을 수 있도록 차트에 전체 추세선을 유지하는 것입니다. 일주일에 티켓이 9개만 들어오는 대기열은 주간 뷰가 아니라 월간 뷰로 보는 것이 적절합니다.

추세보다 세그먼트 분류가 더 중요하다면, 5개의 겹치는 선을 그리는 것보다 대기열별 중앙값과 p90을 보여주는 작은 표를 만드는 것이 더 많은 정보를 전달할 수 있습니다.

최초 답변 시간을 개선하는 방법

보고서는 개선 방향을 제시할 수 있을 때만 가치가 있습니다. 자주 활용되는 네 가지 해결책이 있으며, 보고서를 통해 어떤 해결책이 필요한지 파악할 수 있습니다.

중앙값은 좋으나 꼬리 부분이 나쁜 경우는 대개 속도가 아니라 커버리지(운영 시간)의 문제입니다. 근무 시간 외에 접수된 티켓이나 담당 전문가가 한 명뿐인 대기열의 티켓은 담당자가 복귀할 때까지 방치됩니다. 상담원의 성과를 평가하기 전에 티켓이 접수된 시간대를 먼저 확인하세요.

데이터양은 일정한데 중앙값이 상승하는 경우는 대개 대기열에 아무도 템플릿을 가지고 있지 않은 새로운 유형의 티켓이 유입되고 있음을 의미합니다. 채널별 상세 분석을 통해 이를 확인할 수 있습니다.

데이터양과 중앙값이 함께 상승하는 경우는 인력 충원의 문제이며, 데이터양 막대그래프가 그 강력한 근거가 됩니다.

아무도 신뢰하지 않는 변화 없는 보고서는 정의의 문제입니다. 보고서 상단에 기준 시간과 백분위수 계산 방법을 공개하면 논쟁이 사라집니다.

이 보고서와 함께 활용할 수 있는 데이터양 및 상태 뷰에 대해서는 support ticket report 및 CSAT report 가이드를 참조하세요. 동일한 대기열의 문의 인입 감소(deflection) 측면은 customer service chatbot 페이지에서 다루고 있습니다.

바람직한 목표의 모습

팀들은 종종 데이터 분포를 파악하기도 전에 최초 답변 시간 목표를 설정하곤 하는데, 이 때문에 목표가 무의미해지거나 달성 불가능해집니다.

하나의 숫자 대신 두 개의 숫자를 설정하고 둘 다 공개하세요. 중앙값 목표는 일반적인 경험을 나타내고, p90 목표는 수용할 수 있는 최악의 경험을 나타냅니다. 중앙값이 1.4시간이고 p90이 19.7시간인 팀은 꼬리 부분에 문제가 있는 것입니다. 단일한 2시간 목표를 설정하면 이러한 문제가 전혀 드러나지 않습니다.

그런 다음 목표와 함께 기준 시간을 명시하세요. 영업 시간 기준의 "2시간"과 달력 기준 시간의 "2시간"은 서로 다른 약속입니다. 지원 팀과 경영진은 각자 자신들의 관점에 유리한 쪽으로 해석할 것입니다.

흔히 하는 실수

평균값 보고하기. 이는 오른쪽으로 치우친 분포에서 오해를 불러일으키기 가장 쉬운 통계치이며, 대부분의 스프레드시트 도구에서 기본값으로 설정되어 있습니다.

자동 회신을 최초 답변으로 계산하기. 이는 차트는 훌륭해 보이지만 그 누구의 실제 경험과도 일치하지 않는 결과를 낳는 가장 빠른 방법입니다.

분기 중간에 백분위수 함수 변경하기. 누군가 수식을 수정한 바로 그 주에 p90이 개선되었다면, 여러분이 측정한 것은 대기 시간의 개선이 아니라 수식의 수정 결과일 뿐입니다.

달력 기준 시간과 영업 시간 혼용하기. 달력 기준 시간에서 주말은 48시간의 실패를 의미합니다. 영업 시간 기준으로는 0시간이 될 수 있습니다. 하나를 선택하고 명확히 표시하세요.

복잡함을 줄이기 위해 데이터양 시리즈 제외하기. 막대그래프가 있어야만 데이터가 적은 주와 실제 지표의 퇴보를 구분할 수 있습니다.

분포 없이 목표 달성 여부만 보고하기. 단지 "2시간 목표를 달성했다"는 숫자 하나만으로는 9시간을 대기한 고객들에 대해 아무것도 알 수 없습니다.

결론

최초 답변 시간 보고서는 고객이 실제로 체감하는 몇 안 되는 지원 지표 중 하나이므로 제대로 작성할 가치가 있습니다. 두 개의 선, 하나의 막대 시리즈, 명시된 기준 시간, 그리고 명시된 백분위수 기준을 갖춘 보고서는 단일 평균값만 보여주는 그 어떤 대시보드보다 뛰어납니다.

매주 보고서를 다시 만드는 것이 번거롭다면, 정의를 저장된 프롬프트로 옮기고 새 내보내기 파일이 있을 때마다 다시 생성하세요. 지난달 티켓 내보내기 파일로 Powerdrill Bloom 체험해보기를 사용하여 동일한 축에서 중앙값과 꼬리 부분을 확인해 보세요.

자주 묻는 질문

고객 서비스에서 최초 답변 시간이란 무엇인가요?

고객의 티켓이 접수된 시점부터 실제 상담원의 첫 번째 답변이 제공될 때까지 경과한 시간입니다. 자동 접수 확인 메일은 고객의 질문에 답변하는 것이 아니므로 보통 제외됩니다.

최초 답변 시간 계산 공식은 무엇인가요?

첫 번째 사람의 답변 타임스탬프에서 티켓 생성 타임스탬프를 뺍니다. 영업 시간 기준 버전의 경우, 전체 작업 일수를 반환하고 주말과 공휴일을 정의할 수 있는 NETWORKDAYS.INTL 함수에서 시작하여 하루 중 남은 시간을 더합니다.

최초 답변 시간 보고서에는 평균값과 중앙값 중 무엇을 사용해야 하나요?

중앙값과 함께 90분위수를 나란히 사용해야 합니다. 답변 시간은 오른쪽으로 치우친 분포를 보이므로, 대기 시간이 매우 긴 소수의 티켓이 평균값을 끌어올려 실제로는 거의 아무도 경험하지 못한 수치로 만들기 때문입니다.

PERCENTILE.EXC와 PERCENTILE.INC의 차이점은 무엇인가요?

두 함수는 서로 다른 보간 규칙을 사용합니다. PERCENTILE.EXC는 k가 1/(n + 1)의 배수가 아닐 때 보간을 수행하며, 0과 1을 제외한 범위의 k 값을 허용합니다. PERCENTILE.INC는 1/(n - 1)을 사용하며, 0과 1을 포함한 k 값을 허용합니다.

p90 계산 시 #NUM! 오류가 반환되는 이유는 무엇인가요?

PERCENTILE.EXC는 배열이 비어 있거나 k가 0에서 1 범위를 벗어날 때 이 오류를 반환합니다. 또한 요청한 백분위수에 대해 보간을 수행할 수 없을 때도 이 오류를 반환하는데, 이는 주로 데이터가 부족한 주에 발생합니다.