고객 지원에서 흔히 나오는 “이 티켓은 누가 처리하는가”라는 질문은 단순하게 들립니다. 규모가 작은 팀에서는 답이 “누구든 시간이 되는 사람”입니다. 하지만 규모가 큰 팀에서는 그 답이 통하지 않습니다. 비밀번호 재설정과 데이터베이스 마이그레이션을 같은 사람이 효율적으로 처리할 수는 없기 때문입니다.
지원 등급은 이에 대한 구조적인 답입니다. 유입되는 문제를 복잡도에 따라 세 개의 층으로 나누어, 적절한 기술 수준의 담당자가 적절한 문제를 처리하도록 합니다. 이 글에서는 각 등급이 실제로 무엇을 하는지, 티켓이 등급 간에 어떻게 에스컬레이션되는지, 그리고 팀이 분담을 잘못하는 지점을 다룹니다.
주요 이점
- 문제에 맞는 기술: 단순한 문제는 전문가를 기다리지 않고 Tier 1에서 해결되고, 복잡한 문제는 일반 담당자가 추측하지 않고 적절한 주의를 받습니다.
- 더 빠른 평균 해결: 티켓의 60-80%가 Tier 1에서 종료되므로 Tier 2와 Tier 3의 전문가가 병목이 되지 않습니다.
- 더 명확한 커리어 성장: 상담원은 Tier 1에서 Tier 2, Tier 3로 성장하며, 각 전환 단계마다 명확한 기술 기준이 있습니다.
- 예측 가능한 인력 배치: 각 등급의 물량을 독립적으로 예측할 수 있어 역량 계획이 실행 가능해집니다.
각 등급이 실제로 처리하는 일
구체적인 분담은 업종에 따라 다르지만 원칙은 일관됩니다.
Tier 1 최전선 상담원
Tier 1은 첫 번째 접점입니다. 모든 유입 티켓은 여기에서 시작됩니다(우선순위가 높은 계정을 다른 곳으로 명시적으로 라우팅하는 규칙이 있는 경우는 제외).
Tier 1이 처리하는 일: 계정 관련 질문, 비밀번호 재설정, 주문 상태, 표준 제품 정보, 1차 불만 접수, 기본적인 문제 해결, 그리고 지식 베이스에 해결책이 문서화된 모든 문제.
필요한 기술: 커뮤니케이션 능력, 사용자 수준의 제품 이해, 일반적인 문제에 대한 정형 응답 준수, 에스컬레이션 시점을 판단하는 판단력.
일반적인 해결률: 잘 설계된 구조라면 전체 유입 티켓의 60-80%가 Tier 1에서 종료되어야 합니다. Tier 1의 종료율이 그보다 낮다면 지식 베이스가 부족하거나 에스컬레이션 트리거가 너무 느슨한 것입니다.
Tier 2 제품 전문가
Tier 2는 Tier 1이 해결하지 못한 문제를 맡습니다. 더 깊은 제품 지식, 워크플로 이해, 또는 정책 예외를 허용할 권한이 필요한 문제입니다.
Tier 2가 처리하는 일: 복잡한 구성 문제, 워크플로별 문제, 환불 예외, 에스컬레이션된 불만, 제품 깊이가 필요한 기술적 질문, 여러 시스템에 걸친 사례.
필요한 기술: 깊은 제품 지식, 고객이 보고한 문제를 재현하는 능력, 백엔드 도구와 관리자 인터페이스에 대한 숙련도, 정해진 범위 내에서의 정책 예외 판단력.
일반적인 해결률: Tier 2는 에스컬레이션된 건의 70-85%를 종료해야 합니다. 나머지는 Tier 3로 에스컬레이션되거나 제품/엔지니어링 변경이 필요합니다.
Tier 3 엔지니어링 또는 제품 팀
Tier 3는 코드 변경, 인프라 작업, 또는 해결되지 않은 버그가 필요한 문제가 도착하는 곳입니다. 대부분의 기업에서 Tier 3는 전담 지원 상담원으로 구성되지 않으며, 엔지니어링 팀이나 제품 팀이 순환적으로 지원을 담당합니다.
Tier 3가 처리하는 일: 확인된 버그, 코드 수정이 필요한 통합 실패, 데이터 손상, 보안 사고, 제품의 근본적인 한계를 유발하는 엣지 케이스, 그리고 기반 시스템 변경이 필요한 모든 문제.
필요한 기술: 엔지니어링 지식, 시스템 직접 접근, 패치나 핫픽스를 작성하는 능력, 인시던트 대응 경험.
일반적인 물량: 전체 유입 티켓의 5% 미만이어야 합니다. Tier 3에 티켓이 넘쳐난다면 Tier 2의 에스컬레이션 기준이 잘못되었거나 제품에 시스템적인 문제가 있는 것입니다.
에스컬레이션이 실제로 작동하는 방식
에스컬레이션은 대부분의 등급 구조가 무너지는 지점입니다. 실패를 일으키는 두 가지 패턴이 있습니다.
너무 성급한 에스컬레이션. Tier 1이 3분 이상 걸리는 모든 티켓을 에스컬레이션하면 Tier 2가 병목이 되고 Tier 1은 존재 이유를 잃습니다. 올바른 에스컬레이션 트리거는 구체적입니다. 재현 불가, 정책 예외 필요, 고객이 명시적으로 상사를 요청, 또는 문제가 알려진 난이도 높은 범주에 해당하는 경우입니다.
너무 늦은 에스컬레이션. Tier 1이 역량을 넘어서는 문제에 계속 매달리면 해결 시간이 급증하고 CSAT가 무너집니다. 시간 기반 에스컬레이션, 즉 해결되지 않은 채 N분이 지나면 자동으로 Tier 2로 승격하는 방식이 이를 방지합니다.
건강한 패턴은 명확한 에스컬레이션 기준과 엄격한 시간 상한입니다. 둘 중 하나가 아니라 둘 다 함께여야 합니다.
팀이 분담을 잘못하는 지점
초기 단계 팀에서 Tier 1과 Tier 2를 합치는 것. 규모가 작은 팀은 분담을 아예 생략하는 경우가 많은데, 이는 물량이 늘어나기 전까지는 통합니다. Tier 2를 도입할 적절한 시점은 같은 전문가가 다른 업무에서 계속 빠져나가는 때이며, 그것이 전담 등급을 만들어야 한다는 시장의 신호입니다.
Tier 3에 Tier 2 업무를 시키는 것. Tier 2에서 해결되었어야 할 문제에 몇 시간씩 쓰는 엔지니어는 제품을 만들지 않는 엔지니어입니다. 이는 보통 Tier 2에 지식이 부족해서가 아니라 Tier 2에 도구 접근 권한이 없기 때문에 발생합니다.
인수인계 프로토콜이 없는 것. 맥락도, 재현 단계도, 고객 이력도 없이 에스컬레이션된 티켓은 Tier 2를 처음부터 시작하게 만듭니다. 인수인계 프로토콜(무엇을 시도했는지, 고객이 무엇이라고 했는지, Tier 1이 무엇을 결론지었는지)은 부가적인 부담이 아니라 에스컬레이션이 작동하고 있다는 증거입니다.
도구가 하는 역할
등급 구조에는 에스컬레이션 흐름을 뒷받침하는 도구가 필요합니다. 새 티켓을 기본적으로 Tier 1로 보내는 라우팅 규칙, 전체 맥락을 넘기는 에스컬레이션 버튼, Tier 2와 Tier 3가 Tier 1의 대화 이력을 볼 수 있는 가시성입니다.
Cekat과 같은 플랫폼은 라우팅과 인수인계 메커니즘을 하나의 워크스페이스 안에서 처리하므로, 에스컬레이션 시 고객 기록, 대화 이력, 지금까지의 해결 시도가 티켓과 함께 넘어갑니다. 이로써 티켓이 상위 등급으로 이동할 때 발생하는 “처음부터 시작” 문제가 사라집니다.
어디서 시작할까
팀이 작다면(5명 미만) 공식적인 등급 구조는 아직 이른 편입니다. 대신 평균 시간을 지속적으로 초과하는 두세 가지 티켓 유형을 파악하십시오. 그것이 새롭게 생겨나는 Tier 2 범주이며, 언제 공식화해야 하는지를 알려주는 신호입니다.
팀이 더 크고 물량이 늘고 있다면 현재의 분담을 측정하십시오. 오늘 각 단계에서 해결되는 티켓은 얼마나 되는지. 40% 이상이 첫 상담원을 넘어 에스컬레이션된다면 Tier 1에는 더 나은 도구나 더 나은 교육이 필요합니다. 10% 미만만 에스컬레이션된다면 Tier 1이 전문가가 처리해야 할 업무를 흡수하고 있을 가능성이 큽니다.
고객 서비스, 고객 케어, 고객 지원이 하나의 팀 안에서 책임을 어떻게 나누는지에 대한 관련 관점은 고객 서비스 vs 고객 케어 vs 고객 지원을 참고하십시오.
지원 등급은 관료적인 층이 아닙니다. 이는 성장 문제에 대한 구조적인 답입니다. 복잡도와 무관하게 모든 문제에 같은 양의 주의를 기울이지 않으면서 더 많은 물량을 처리하는 방법입니다.
답글 남기기