계층형 지원 모델

Tier 1 (최전선 지원): 모든 초기 문의를 처리합니다. 범위: 일반적인 사용 방법 질문(기술 자료에서 답변 가능), 계정 관리(비밀번호 재설정, 청구 문의, 요금제 변경), 표준 사용 사례에 대한 기본 구성 안내, 버그 보고서 분류(재현 단계 수집 및 문제 재현 가능 여부 확인). 해결 목표: 이 계층에서 모든 문의의 70~80%를 에스컬레이션 없이 해결합니다. 주요 역량: 광범위한 제품 지식, 뛰어난 의사소통 능력, 효율적인 기술 자료 활용. Tier 2 (고급 지원): Tier 1에서 에스컬레이션된 문제를 처리합니다. 범위: Tier 1이 접근할 수 없는 API 또는 데이터 조사가 필요한 복잡한 다중 시스템 문제, 백엔드 로그 분석이 필요한 버그 확인, 맞춤형 구성 컨설팅, 통합 문제 해결. 해결 목표: 모든 문의(Tier 1 에스컬레이션)의 15~25%를 해결합니다. 주요 역량: 심층적인 기술 지식, 데이터베이스 및 로그 접근 권한. Tier 3 (엔지니어링 지원): Tier 2에서만 에스컬레이션된 문제를 처리합니다. 범위: 코드 변경이 필요한 확인된 버그, 수동 데이터베이스 개입이 필요한 데이터 무결성 문제, 보안 조사. 해결 목표: 전체 문의의 2~5%를 해결합니다. 주요 역량: 엔지니어링 전문 지식, 프로덕션 시스템 접근 권한.

에스컬레이션 기준은 양극단을 방지하기 위해 명확해야 합니다. 과소 에스컬레이션(Tier 1이 자신의 범위를 넘어선 문제를 해결하려는 시도)은 긴 처리 시간, 잘못된 해결책, 고객 불만을 초래합니다. 과도한 에스컬레이션(Tier 1이 다소 복잡한 모든 것을 에스컬레이션하는 것)은 Tier 2 백로그를 생성하고 최전선에서 처리되어야 할 문제에 값비싼 기술 인력을 낭비하게 합니다. Tier 1 → Tier 2 에스컬레이션 트리거: 고객이 표준 문제 해결 체크리스트 완료 후에도 문제가 지속됨을 확인한 경우; 문제가 백엔드 로그, API 응답 본문 또는 내부 관리 도구에 대한 읽기 접근 권한을 요구하는 경우; 문제가 여러 고객에게 영향을 미치는 것으로 보이는 경우(잠재적인 광범위한 버그); 또는 고객이 즉각적인 기술 검토를 요청하는 엔터프라이즈 계정인 경우. Tier 2 → Tier 3 에스컬레이션 트리거: Tier 2가 코드에서 재현 가능한 버그를 확인한 경우(구성 또는 데이터 문제가 아님); 문제가 데이터 마이그레이션, 데이터베이스 복구 또는 프로덕션 핫픽스를 요구하는 경우; 문제가 보안 관련 사항으로 보안 팀 검토가 필요한 경우. 이러한 기준은 지원 기술 자료에 문서화되며 중요한 제품 변경 시마다 업데이트됩니다.

Tier 2 및 Tier 3의 에스컬레이션 대기열은 SaaS 지원 운영에서 흔하고 비용이 많이 드는 병목 현상입니다. 예방 전략: Tier 1 품질 게이트 — Tier 1 상담원이 에스컬레이션 전에 표준화된 에스컬레이션 템플릿(재현 단계, 시도된 해결책, 오류 메시지, 계정 세부 정보)을 작성하도록 요구합니다. 문서화가 미흡한 에스컬레이션은 Tier 1로 반환되어 완료되도록 하여 정보 품질을 향상하고 Tier 2 조사 시간을 단축합니다. Tier 2 SLA 모니터링 — 총 해결 시간뿐만 아니라 Tier 2 및 Tier 3 대기열에 대한 계층 내 시간을 별도로 추적합니다. Tier 2에서 48시간을 초과하는 백로그 노후화는 관리자 검토를 트리거해야 합니다. 엔지니어링 개입 감소 — Tier 3로 가장 자주 에스컬레이션되는 문제 범주를 식별하고, Tier 2가 엔지니어링 개입 없이 진단하고 해결할 수 있도록 Tier 2 도구(관리 도구, 진단 유틸리티)를 구축합니다. Product Ops는 매월 계층별 에스컬레이션 비율을 추적합니다. Tier 1→2 에스컬레이션 비율이 증가하면 Tier 1의 역량 강화 또는 기술 자료 확장이 필요한 새로운 제품 복잡성을 나타낼 수 있습니다.