고객 이슈를 분류하고, 우선순위를 지정하고, 라우팅하고, 첫 응답을 작성합니다. — Claude Skill

---

name: ticket-triage description: 지원 티켓 또는 고객 이슈를 분류하고 우선순위를 정합니다. 새 티켓이 들어와 분류, P1-P4 우선순위 지정, 담당 팀 결정, 라우팅 전 중복 또는 알려진 이슈 여부 확인이 필요할 때 사용하세요. argument-hint: "<ticket or issue description>"

/티켓-분류

익숙하지 않은 플레이스홀더가 보이거나 어떤 도구가 연결되어 있는지 확인해야 한다면 CONNECTORS.md를 참고하세요.

들어온 지원 티켓 또는 고객 이슈를 분류하고, 우선순위를 정하고, 라우팅합니다. 제안 초기 응답가 포함된 구조화된 분류 평가를 생성합니다.

사용법

/ticket-triage <ticket text, customer message, or issue description>

예시:

• /ticket-triage Customer says their dashboard has been showing a blank page since this morning
• /ticket-triage "I was charged twice for my subscription this month"
• /ticket-triage User can't connect their SSO — getting a 403 error on the callback URL
• /ticket-triage Feature request: they want to export reports as PDF

업무흐름

1. 이슈 파싱

입력을 읽고 다음을 추출합니다.

• 핵심 문제: 고객이 실제로 무엇을 겪고 있나요?
• 증상: 어떤 구체적 동작이나 오류를 보고 있나요?
• 고객 맥락: 누구인가요? 사용 가능한 계정 세부사항, 요금제 수준, 이력가 있나요?
• 긴급 신호: 막혀 있나요? 제작인가요? 몇 명의 사용자가 영향을 받나요?
• 감정 상태: 좌절함, 혼란스러움, 담담함, 에스컬레이션 중?

2. 분류와 우선순위 지정

아래 범주 분류 체계와 우선순위 프레임워크를 사용합니다.

• 주요 범주(버그, 사용 방법, 기능 요청, 결제, 계정, 연동, 보안, 데이터, 성능)와 선택적 보조 범주를 지정합니다
• 영향과 긴급도를 기준으로 우선순위(P1-P4)를 지정합니다
• 이슈가 매핑되는 제품 영역를 식별합니다

3. 중복 및 알려진 이슈 확인

라우팅 전에 사용 가능한 출처를 확인합니다.

• ~~지원 플랫폼: 유사한 열려 있거나 최근 해결된 티켓 검색
• ~~지식 베이스: 알려진 이슈 또는 기존 문서 확인
• ~~프로젝트 트래커: 기존 버그 보고 또는 기능 요청가 있는지 확인

아래 중복 감지 프로세스를 적용합니다.

4. 라우팅 결정

아래 라우팅 규칙을 사용해 범주와 복잡도 기준으로 어떤 팀 또는 대기열가 처리해야 하는지 권고합니다.

5. 분류 출력 생성

## 분류: [한 줄 이슈 요약]

**범주:** [주요] / [보조 해당 시]
**우선순위:** [P1-P4] — [간단한 근거]
**제품 영역:** [영역/팀]

### 이슈 요약
[고객이 겪는 문제에 대한 2-3문장 요약]

### 핵심 세부사항
- **고객:** [알고 있는 경우 이름/계정]
- **영향:** [영향받는 대상과 내용]
- **우회 방법:** [가능 / 불가 / 알 수 없음]
- **관련 티켓:** [발견 시 유사 이슈 링크]
- **알려진 이슈:** [예 — 링크 / 아니요 / 확인 중]

### 라우팅 추천
**라우팅 대상:** [팀 또는 대기열]
**이유:** [간단한 이유]

### 제안 초기 응답
[첫 답변 초안 고객에게 — 이슈를 인정하고,
기대치를 설정하고 가능한 경우 우회 방법을 제공합니다.
아래 자동 응답 템플릿을 출발점으로 사용하세요.]

### 내부 메모
- [이어받는 담당자를 위한 추가 맥락]
- [버그인 경우 재현 단서]
- [주의할 에스컬레이션 신호]

6. 다음 단계 제안

분류를 제시한 뒤:

• "고객에게 보낼 전체 답변를 작성할까요?"
• "이 이슈에 대한 추가 맥락을 검색할까요?"
• "트래커에서 알려진 버그인지 확인할까요?"
• "에스컬레이션할까요? /고객-에스컬레이션으로 패키징할 수 있습니다."

---

범주 분류 체계

모든 티켓에는 주요 범주를 지정하고, 필요하면 보조 범주를 추가합니다.

범주 판정 팁

• 고객이 버그와 기능 요청를 모두 보고한다면 버그가 주요입니다
• 버그 때문에 로그인할 수 없다면 범주는 버그입니다(계정가 아님) - 근본 원인가 범주를 결정합니다
• "전에는 작동했는데 이제 작동하지 않습니다" = 버그
• "다르게 작동했으면 합니다" = 기능 요청
• "어떻게 작동하게 하나요?" = 사용 방법
• 애매하면 버그 쪽으로 기울이세요 - 묵살보다 조사하는 편이 낫습니다

우선순위 프레임워크

P1 — 치명적

기준: 운영 시스템 중단, 데이터 손실 또는 손상, 보안 침해, 전체 또는 대부분의 사용자 영향.

• 고객이 제품을 전혀 사용할 수 없음
• 데이터가 손실, 손상, 노출되고 있음
• 보안 인시던트가 진행 중
• 이슈가 악화되거나 범위가 확장되고 있음

SLA 기대치: 1시간 이내 응답. 해결 또는 완화까지 지속 작업. 1-2시간마다 업데이트.

P2 — 높음

기준: 주요 기능 고장, 중요한 업무흐름 차단, 다수 사용자 영향, 우회 방법 없음.

• 핵심 업무흐름가 깨졌지만 제품은 부분적으로 사용 가능함
• 여러 사용자가 영향을 받거나 핵심 계정가 영향받음
• 시간 민감 업무가 막힘
• 합리적인 우회 방법가 없음

SLA 기대치: 4시간 이내 응답. 당일 적극 조사. 4시간마다 업데이트.

P3 — 중간

기준: 기능 부분 고장, 우회 방법 있음, 단일 사용자 또는 작은 팀 영향.

• 기능이 올바르게 작동하지 않지만 우회 방법가 있음
• 불편하지만 중요 업무를 막지는 않음
• 단일 사용자 또는 작은 팀이 영향받음
• 고객이 긴급 에스컬레이션 중이 아님

SLA 기대치: 영업1일 차일 이내 응답. 영업일 3일 이내 해결 또는 업데이트.

P4 — 낮음

기준: 사소한 불편, 외관상 이슈, 일반 질문, 기능 요청.

• 기능에 영향을 주지 않는 외관상 또는 UI 이슈
• 기능 요청와 개선 아이디어
• 일반 질문 또는 사용 방법 문의
• 단순하고 문서화된 해결책이 있는 이슈

SLA 기대치: 영업일 2일 이내 응답. 정상 속도로 해결.

우선순위 에스컬레이션 신호

다음 경우 자동으로 우선순위를 올립니다.

• 고객이 SLA 허용 시간보다 오래 기다림
• 여러 고객이 같은 이슈를 보고함(패턴 감지됨)
• 고객이 명시적으로 에스컬레이션하거나 임원 관여를 언급함
• 기존 우회 방법가 더 이상 작동하지 않음
• 이슈 범위가 확장됨(더 많은 사용자, 더 많은 데이터, 새로운 증상)

라우팅 규칙

범주와 복잡도 기준으로 티켓을 라우팅합니다.

중복 감지

새 티켓을 만들거나 라우팅하기 전에 중복를 확인합니다.

1. 증상으로 검색: 유사한 오류 메시지 또는 설명이 있는 티켓 찾기
2. 고객으로 검색: 같은 고객의 같은 이슈의 열린 티켓이 있는지 확인
3. 제품 영역로 검색: 같은 기능 영역의 최근 티켓 찾기
4. 알려진 이슈 확인: 문서화된 알려진 이슈와 비교

중복를 찾은 경우:

• 새 티켓을 기존 티켓에 연결합니다
• 이 알려진 이슈가 추적 중임을 고객에게 알립니다
• 새 보고의 추가 정보를 기존 티켓에 더합니다
• 새 보고가 긴급도를 추가하면 우선순위를 올립니다(더 많은 고객 영향 등)

범주별 자동 응답 템플릿

버그 — 초기 응답

제보해 주셔서 감사합니다. [구체 영향]가 업무에 얼마나
지장을 줄 수 있는지 이해합니다.

이 이슈를 [우선순위] 이슈로 기록했고, 저희 팀이 조사 중입니다.
[우회 방법이 있는 경우: "그동안에는 [우회 방법]를 사용하실 수
있습니다."]

[SLA 기간] 이내에 확인한 내용을 업데이트드리겠습니다.

사용 방법 — 초기 응답

좋은 질문입니다! [직접 답변 또는 문서 링크]

[더 복잡한 경우: "단계를 안내해드리겠습니다:"]
[단계 또는 가이드]

도움이 되었는지 알려 주세요. 추가 질문이 있으면 말씀해 주세요.

기능 요청 — 초기 응답

제안해 주셔서 감사합니다. [기능]가 업무흐름에 왜 가치가
있는지 이해합니다.

이 내용을 문서화했고 제품 팀과 공유했습니다. 구체적인
일정을 약속드릴 수는 없지만, 이 피드백은 로드맵 우선순위에
직접 반영됩니다.

[대안이 있으면: "그동안에는 비슷한 목표를 달성하는 데
[대안]가 도움이 될 수 있습니다."]

결제 — 초기 응답

결제 이슈는 빠른 확인이 필요하다는 점을 이해합니다. 바로
확인해 보겠습니다.

[단순한 경우: 해결 세부사항]
[단순한 경우: 해결 세부사항] 이내에
답변드리겠습니다."]

보안 — 초기 응답

알려 주셔서 감사합니다. 저희는 보안 우려을 매우 중요하게
다루며 즉시 검토하고 있습니다.

이 건을 보안 팀에 에스컬레이션했습니다. [기간] 이내에
확인 결과를 후속 확인하겠습니다.

[조치가 필요한 경우: "그동안에는 [보호 조치]을 권장합니다."]

분류 모범 사례

1. 분류하기 전에 전체 티켓을 읽으세요 - 뒤쪽 메시지의 맥락가 평가를 바꾸는 경우가 많습니다
2. 설명된 증상만이 아니라 근본 원인 기준으로 분류하세요
3. 우선순위가 애매하면 더 높은 쪽으로 정하세요 - SLA 위반에서 회복하는 것보다 에스컬레이션 해제이 쉽습니다
4. 라우팅 전에 항상 중복와 알려진 이슈를 확인하세요
5. 다음 사람이 맥락를 빠르게 이어받을 수 있도록 내부 메모를 작성하세요
6. 중복 조사을 피하기 위해 이미 확인했거나 배제한 내용을 포함하세요
7. 패턴을 표시하세요 - 같은 이슈가 반복되면 개별 티켓이 낮은 우선순위여도 패턴을 에스컬레이션하세요