평균 해결 시간 (MTTR)

MTTR 공식: MTTR = (해당 기간 내 모든 티켓의 해결 타임스탬프 - 생성 타임스탬프 합계) / 해당 기간 내 해결된 티켓 수. 원시 평균은 극히 소수의 장기 미해결 티켓에 의해 크게 왜곡될 수 있습니다. 예를 들어, 90일 동안 미해결 상태인 버그 하나가 평균을 극적으로 왜곡할 수 있는 반면, 중앙값은 일반적인 고객 경험을 정확하게 반영합니다. Support Ops는 평균 MTTR과 중앙값 MTTR을 모두 보고해야 하며, 다음 기준에 따라 MTTR을 분류해야 합니다: 티켓 우선순위 (엔터프라이즈 SaaS의 P1 MTTR은 2~4시간이어야 하며, P4 MTTR은 10영업일 이상일 수 있으며 허용됩니다); 티켓 유형 (청구 관련 티켓은 몇 시간 내에 마감되지만, 엔지니어링 에스컬레이션은 몇 주가 걸릴 수 있습니다); 채널 (채팅 MTTR은 15분 미만이어야 하며, 이메일 MTTR은 시간 단위로 측정됩니다); 고객 등급 (엔터프라이즈와 SMB는 매우 다른 MTTR 목표를 가질 수 있습니다). 단일 통합 숫자로 보고된 MTTR은 이러한 모든 차원을 행동하기 어렵고 조작하기 쉬운 수치로 혼합합니다.

MTTR 감소는 시간이 어디에 소요되는지 파악하는 것을 필요로 합니다. 해결 프로세스에는 개선이 가능한 명확한 단계가 있습니다. 상담원 평가 시간 (첫 접촉부터 완전 진단까지): 지식 기반의 구조화된 진단 워크플로우 (예: '[증상]에 대해 다음 5가지 사항을 순서대로 확인'), CRM 통합을 통한 계정 컨텍스트 자동 채우기, 티켓 텍스트 기반의 AI 제안 솔루션을 통해 단축됩니다. 엔지니어링 대기 시간 (엔지니어링 응답을 기다리는 Tier 2 에스컬레이션): 엔지니어링 에스컬레이션 SLA를 정의하고 준수 여부를 모니터링하고, 이전에 엔지니어링이 필요했던 문제를 Tier 2가 해결할 수 있도록 Tier 2 진단 도구를 구축하며, 일반적인 엔지니어링 에스컬레이션 패턴에 대한 해결 라이브러리를 구축하여 단축됩니다. 고객 대기 시간 (상담원이 고객에게 추가 정보를 제공하도록 기다리는 시간): 상담원이 순차적인 후속 조치 대신 필요한 모든 정보를 한 메시지에 요청하고, '고객 대기 중' 상태 기반의 자동 재개방을 통해 대기 중인 티켓이 해결된 것으로 표시되지 않도록 하며, 사전 예방적 후속 타이머 (24시간 내 응답이 없으면 고객과 상담원에게 자동 알림 전송)를 통해 단축됩니다. 진단 후 보류 (해결책은 알지만 프로세스에 의해 차단됨): 승인 없이 일반적인 수정 사항을 구현할 수 있는 상담원의 권한을 명확히 정의하여 단축됩니다.

MTTR-CSAT 관계는 비선형적이고 직관적이지 않습니다. MTTR을 줄이면 일반적으로 CSAT가 향상됩니다. 고객은 더 빠른 해결을 선호하기 때문입니다. 그러나 성급한 해결, 조기 티켓 마감 또는 피상적인 수정으로 달성된 MTTR 감소는 CSAT에 적극적으로 해를 끼칩니다. 예를 들어, 문제를 실제로 해결하지 않고 2시간 만에 마감된 티켓은 매우 낮은 CSAT 점수를 생성하고 재개될 가능성이 높습니다 ('재연락률'로 측정됨). 충돌 지점: 경영진이 CSAT 보호 장치 없이 MTTR 감소를 KPI로 장려할 때, 상담원은 해결 품질보다 마감 속도를 최적화합니다. 즉, 지름길을 택하고, 철저한 확인 전에 티켓을 해결된 것으로 표시하며, 진정한 도움 없이 복잡한 문제를 지식 기반으로 회피합니다. Support Ops는 이를 다음과 같이 완화합니다: 모든 운영 대시보드에서 MTTR을 CSAT 및 재연락률과 함께 보고하여 (재연락 신호를 통해 조작을 명확히 함); 상담원에게 회피를 통해 달성된 빠른 MTTR보다 신중하게 처리된 복잡한 문제의 긴 MTTR이 더 가치 있다고 명시적으로 알림; 그리고 열망적인 속도 목표보다는 현실적인 해결 품질 타임라인을 반영하는 티켓 유형별 MTTR 목표를 설정합니다.