인시던트 관리 데이터 템플릿
인시던트 관리 데이터 템플릿
- 수집 권장 속성
- 프로세스 매핑을 위해 추적할 주요 활동
- 데이터 추출 방법
인시던트 관리 속성
| 이름 | 설명 | ||
|---|---|---|---|
|
이벤트 타임스탬프
EventTimestamp
|
활동이 발생한 정확한 날짜와 시간입니다. | ||
|
설명
이 타임스탬프는 댓글 추가나 상태 변경 등 인시던트 처리 과정에서 이벤트가 발생한 정확한 시점을 기록합니다. 케이스 내 모든 활동의 시간 순서를 확인할 수 있습니다. 시간 기반 process mining 분석에 필수적인 속성입니다. 활동 간 처리 시간을 계산하고, 대기 시간을 찾으며, 케이스 전체 처리 기간을 측정하고, 기간별 프로세스 성과를 분석하는 데 사용됩니다. 정확한 타임스탬프가 있어야 시간에 따른 케이스 흐름을 보여주는 애니메이션 프로세스 맵을 만들고, 평균 해결 시간과 같은 KPI를 추적하는 성과 대시보드를 구성할 수 있습니다.
중요한 이유
타임스탬프는 모든 활동의 시간 순서를 보여줍니다. 이를 바탕으로 소요 시간을 계산하고, 병목을 찾아내며, 시간에 따른 프로세스 성과를 분석할 수 있습니다.
확보 방법
Zendesk Ticket Audits API (/api/v2/tickets/{ticket_id}/audits), 각 감사 이벤트의 필드 created_at.
예시
2023-04-15T10:00:00Z2023-04-15T10:05:12Z2023-04-16T14:30:00Z
|
|||
|
인시던트 ID
TicketId
|
각 인시던트 티켓을 식별하는 시스템 생성 고유 ID입니다. | ||
|
설명
인시던트 ID는 Zendesk Support에서 각 인시던트 케이스를 고유하게 식별하는 기본 키입니다. process mining에서 CaseId로 사용되며, 인시던트 생성부터 종료까지 관련 활동과 상태 변경, 커뮤니케이션을 연결합니다. 분석에서는 이 ID를 사용해 인시던트별 전체 처리 과정을 재구성합니다. 이벤트 데이터를 모아 개별 케이스의 총 해결 시간, 인계 횟수, 서비스 수준 협약 준수 여부와 같은 지표를 추적할 수 있습니다. ID별로 이벤트를 그룹화하면 프로세스 흐름을 시각화하고, 자주 나타나는 경로를 파악하며, 표준 절차에서 벗어난 부분을 찾을 수 있습니다.
중요한 이유
모든 이벤트를 하나의 인시던트에 연결하는 필수 식별자입니다. 이를 통해 전체 처리 주기를 추적하고 프로세스 성과를 정확히 분석할 수 있습니다.
확보 방법
Zendesk Tickets API (/api/v2/tickets/{id}), 필드 id.
예시
19428230113521941055
|
|||
|
마지막 데이터 업데이트
LastDataUpdate
|
이 프로세스의 데이터가 마지막으로 새로 고쳐진 시점을 나타내는 타임스탬프입니다. | ||
|
설명
이 속성은 원천 시스템에서 데이터를 마지막으로 추출하거나 업데이트한 날짜와 시간을 기록합니다. 일반적으로 새로 고침 주기마다 전체 데이터 세트에 하나의 값이 적용됩니다. 데이터 거버넌스와 process mining 분석 사용자에게 중요한 정보입니다. 데이터가 얼마나 최신인지 파악할 수 있어 분석에 현재 이용 가능한 최신 정보가 반영되었는지 확인할 수 있습니다. 운영 성과를 모니터링하고 분석 결과를 바탕으로 적시에 의사결정을 내릴 때 특히 중요합니다.
중요한 이유
데이터의 최신 상태에 관한 정보를 제공하므로, 사용자는 분석에 반영된 데이터의 기준 시점을 확인할 수 있습니다.
확보 방법
데이터 새로 고침이 완료되면 ETL/데이터 파이프라인 프로세스에서 생성되는 타임스탬프입니다.
예시
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
|
|||
|
원천 시스템
SourceSystem
|
인시던트 데이터를 추출한 시스템입니다. | ||
|
설명
이 속성은 프로세스 데이터의 출처를 식별합니다. 이 화면에서는 모든 이벤트와 속성이 해당 시스템에서 추출되었음을 나타내는 'Zendesk Support'와 같은 고정값을 사용합니다. 여러 시스템의 데이터를 결합하는 환경에서는 데이터 출처를 구분하는 데 중요한 필드입니다. 데이터 무결성을 확인하고, Zendesk와 다른 ITSM 도구의 인시던트 관리 프로세스를 비교하는 등 출처별 분석을 수행할 수 있습니다.
중요한 이유
데이터 출처를 식별합니다. 데이터 거버넌스와 여러 원천 시스템의 데이터를 결합하는 분석에 중요합니다.
확보 방법
데이터 변환 과정에서 출처를 식별하도록 설정하는 고정값입니다.
예시
Zendesk SupportZendesk
|
|||
|
활동
ActivityName
|
인시던트 처리 주기의 특정 시점에 발생한 업무 활동 또는 이벤트의 이름입니다. | ||
|
설명
이 속성은 인시던트 관리 프로세스에서 수행된 특정 단계나 조치를 나타냅니다. 예를 들어 '인시던트 생성', '티켓을 상담원에게 배정', '인시던트 해결' 등이 있습니다. 이러한 활동은 Zendesk의 이벤트 로그나 감사 추적 데이터에 기록된 시스템 변경 사항에서 도출됩니다. process mining에서는 활동이 발생한 순서가 프로세스 맵을 구성하며, 이는 모든 분석의 기반이 됩니다. 활동 흐름을 분석하면 인시던트가 실제로 거치는 경로를 파악하고, 단계 사이의 병목을 찾으며, 재작업 경로(예: 해결된 티켓을 다시 여는 경우)를 측정하고, 정의된 표준 프로세스를 준수하는지 확인할 수 있습니다.
중요한 이유
활동의 순서가 프로세스 흐름을 정의합니다. 이는 비효율과 편차, 개선 기회를 찾는 process mining 분석의 기반입니다.
확보 방법
Zendesk Ticket Audits API의 이벤트에서 도출합니다. 예를 들어 status 필드의 Change 이벤트를 '상태 변경' 활동으로 매핑할 수 있습니다.
예시
인시던트 생성티켓을 상담원에게 배정상태가 Pending으로 변경인시던트 해결인시던트 종료
|
|||
|
SLA 상태
SlaStatus
|
인시던트의 현재 서비스 수준 계약(SLA) 상태입니다. | ||
|
설명
이 속성은 인시던트가 정해진 SLA 목표를 충족할 수 있는 상태인지, 이미 SLA를 위반했는지, 또는 SLA 타이머가 일시 중지되었는지를 나타냅니다. Zendesk는 설정된 정책에 따라 SLA 지표를 자동으로 추적합니다. 'SLA 준수 모니터링' 대시보드에서 중요한 속성입니다. 서비스 약속에 대한 성과를 직접 확인할 수 있습니다. SLA 위반 시점과 원인을 분석하면 조직은 프로세스의 취약점을 찾아 서비스 신뢰성을 높일 수 있습니다. '인시던트 SLA 준수율' KPI에도 활용됩니다.
중요한 이유
서비스 약속에 대한 성과를 직접 측정해 SLA 위반을 분석하고, 규정 준수를 선제적으로 모니터링할 수 있습니다.
확보 방법
Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json)에서 가져옵니다. sla_policy, breached_at 등의 필드를 바탕으로 산출합니다.
예시
진행 중일시 중지위반충족
|
|||
|
담당 그룹
AssignedGroup
|
현재 인시던트를 담당하는 지원팀 또는 그룹입니다. | ||
|
설명
이 속성은 인시던트를 담당하는 팀을 나타냅니다. 인시던트는 'L1 Support'에서 'Network Team'으로 이동하는 것처럼 지원 단계나 전문 그룹 사이를 오갈 수 있습니다. 프로세스 이관을 분석하고 병목을 찾을 때 중요한 기준입니다. 인시던트가 그룹 사이를 어떻게 이동하는지 살펴보면 팀 간 의존성을 측정하고, 팀별 대기 시간을 계산하며, 라우팅 규칙을 개선할 수 있습니다. '이관 및 재작업 분석' 대시보드에도 활용됩니다.
중요한 이유
팀별 담당 현황을 추적해 팀 간 이관을 분석하고, 팀별 병목을 찾으며, 대기 시간을 측정할 수 있습니다.
확보 방법
Zendesk Tickets API의 group_id 필드입니다. 변경 내역은 Ticket Audits API에 기록됩니다.
예시
L1 지원L2 네트워크 팀L3 인프라청구
|
|||
|
담당 상담원
Assignee
|
현재 인시던트 처리를 담당하는 지원 상담원입니다. | ||
|
설명
이 속성은 특정 시점에 인시던트를 담당하는 상담원을 식별합니다. 담당자가 바뀌면 한 사람에게서 다른 사람으로 업무가 이관된 것입니다. 담당 상담원을 분석하면 업무량 분배, 개인별 성과, 협업 패턴을 파악할 수 있습니다. 이 필드의 변경 내역은 '인시던트당 평균 이관 횟수' KPI를 계산하고, 인시던트가 여러 담당자에게 반복해서 전달되는 상황을 찾아내는 데 필요합니다. 잦은 이관은 지식 부족이나 비효율적인 라우팅을 나타낼 수 있습니다.
중요한 이유
담당 상담원을 식별해 업무량을 분석하고 이관 내역을 추적할 수 있습니다. 프로세스 비효율을 찾는 데도 중요합니다.
확보 방법
Zendesk Tickets API의 assignee_id 필드입니다. 변경 내역은 Ticket Audits API에 기록됩니다.
예시
John SmithJane Doe서비스 데스크 자동화
|
|||
|
우선순위
TicketPriority
|
인시던트에 지정된 우선순위입니다. 예: '낮음', '보통', '높음', '긴급'. | ||
|
설명
인시던트의 우선순위에 따라 대응과 해결에 필요한 긴급도가 정해집니다. 지원팀의 업무 우선순위와 리소스 배분에도 영향을 줍니다. 프로세스 분석에서는 우선순위별로 인시던트를 나누어 프로세스 흐름과 성과를 비교합니다. 예를 들어 '긴급' 인시던트가 '낮음' 우선순위의 인시던트보다 실제로 더 빨리 해결되는지 확인할 수 있습니다. SLA는 우선순위에 따라 정해지는 경우가 많으므로 규정 준수 모니터링에도 사용됩니다. '우선순위 변경률' KPI는 이 필드의 변경 내역을 바탕으로 계산합니다.
중요한 이유
분석 대상을 우선순위별로 나누고, 우선순위 지정의 효과를 평가하며, 긴급도별 SLA 준수 여부를 모니터링하는 데 중요합니다.
확보 방법
Zendesk Tickets API의 priority 필드입니다. 변경 내역은 Ticket Audits API에 기록됩니다.
예시
낮음보통높음긴급
|
|||
|
이벤트 종료 시간
EventEndTime
|
활동이 완료된 시점을 나타내는 타임스탬프입니다. | ||
|
설명
이벤트 종료 시간은 활동이 끝난 시점을 나타냅니다. 이벤트 로그에서는 같은 케이스에서 다음 순서로 발생한 활동의 시작 시간을 이전 활동의 종료 시간으로 추정하는 경우가 많습니다. 케이스의 마지막 활동은 시작 시간과 종료 시간이 같을 수 있습니다. 이 속성은 개별 활동의 소요 시간(ProcessingTime)과 활동 사이의 대기 시간을 계산하는 데 필요합니다. 병목 분석의 기초가 되는 정보로, 각 단계에 걸리는 시간뿐 아니라 단계가 시작되기 전 케이스가 얼마나 대기했는지도 확인할 수 있습니다.
중요한 이유
활동 소요 시간과 대기 시간을 계산해 상세한 병목 분석을 수행하고 프로세스 지연을 찾을 수 있습니다.
확보 방법
같은 케이스에서 다음 이벤트의 시작 시간을 기준으로 계산합니다. 마지막 이벤트의 종료 시간은 시작 시간 또는 케이스 종료 시간과 같을 수 있습니다.
예시
2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
|
|||
|
접수 채널
Channel
|
인시던트가 처음 접수된 채널입니다. 예: '이메일', '웹', 'API'. | ||
|
설명
이 속성은 최종 사용자나 시스템이 인시던트 티켓을 생성할 때 사용한 방식을 기록합니다. 접수 채널을 파악하면 인시던트가 발생하는 경로를 분석하고, 이에 맞춰 지원 프로세스를 조정할 수 있습니다. 채널별로 인시던트를 분석하면 서로 다른 패턴을 확인할 수 있습니다. 예를 들어 전화로 접수된 인시던트는 이메일로 접수된 인시던트보다 해결 시간이 짧을 수 있습니다. 이 정보는 '인시던트 처리량' 대시보드에 활용되며, 리소스 계획과 채널 최적화에도 도움이 됩니다.
중요한 이유
접수 경로별 인시던트 건수와 프로세스 성과를 분석해 채널별 개선과 리소스 배분을 지원합니다.
확보 방법
Zendesk Tickets API의 via.channel 필드입니다.
예시
웹이메일API전화
|
|||
|
티켓 상태
TicketStatus
|
이벤트 발생 시점의 인시던트 티켓 상태입니다. 예를 들어 'Open', 'Pending', 'Solved' 등이 있습니다. | ||
|
설명
이 속성은 인시던트 처리 주기의 여러 시점에서 티켓이 어떤 상태였는지 보여줍니다. Zendesk의 기본 상태에는 new, open, pending, on-hold, solved, closed가 있습니다. 이 필드의 변경을 추적하는 것은 process mining 활동을 생성하는 주요 방법입니다. 티켓 상태 분석은 프로세스를 이해하는 데 필수적입니다. 고객 답변을 기다리는 경우가 많은 'Pending'과 같은 특정 상태에 인시던트가 얼마나 오래 머무는지 파악할 수 있습니다. 또한 케이스 완료 시점을 정의하고 해결 시간을 계산하는 데도 중요합니다.
중요한 이유
상태 변경을 추적하면 프로세스 진행 상황을 파악하고, 대기 시간을 확인하며, 인시던트 처리 주기의 시작과 종료 시점을 정의할 수 있습니다.
확보 방법
Zendesk Tickets API의 status 필드입니다. 변경 내역은 Ticket Audits API에 기록됩니다.
예시
신규열림보류해결됨종료됨
|
|||
|
고객 조직
Organization
|
인시던트 요청자가 소속된 조직 또는 회사입니다. | ||
|
설명
이 속성은 인시던트를 고객 조직과 연결합니다. 고객별 서비스 수준과 지원 프로세스가 다를 수 있는 B2B 지원 환경에서 중요합니다. 조직별로 인시던트를 분석하면 지원팀이 고객 상태를 모니터링하고, 특정 고객에게 반복되는 문제를 찾아내며, 계약상 의무가 이행되는지 확인할 수 있습니다. 대시보드와 보고서를 고객 관점으로 필터링해 성과를 확인하는 데도 사용됩니다.
중요한 이유
고객별 분석을 통해 서비스 수준을 모니터링하고, 주요 고객의 추세를 파악하며, 고객 관계를 효과적으로 관리할 수 있습니다.
확보 방법
Zendesk Tickets API의 organization_id 필드입니다.
예시
Global Tech Inc.Innovate SolutionsData Corp
|
|||
|
근본 원인 범주
RootCauseCategory
|
인시던트의 근본 원인을 상위 수준에서 분류한 항목입니다. | ||
|
설명
이 속성은 인시던트가 발생한 근본 원인을 분류합니다. 일반적으로 인시던트 처리 주기 후반에 사후 검토나 문제 관리 과정에서 기록하며, 사용자 지정 필드에 저장합니다. '근본 원인 식별 정확도' 대시보드와 'RCA 범위' KPI에 필요한 데이터입니다. 근본 원인별로 인시던트를 분석하면 반복되는 문제를 찾아 영구적인 해결책을 마련하고 향후 인시던트 발생을 줄일 수 있습니다. 사후 대응에 그치지 않고 문제를 미리 예방하는 데 초점을 맞출 수 있습니다.
중요한 이유
인시던트 원인을 분류해 추세를 파악하고 재발을 방지함으로써 선제적인 문제 관리를 지원합니다.
확보 방법
일반적으로 사용자 지정 티켓 필드입니다. Zendesk Admin Center에서 Ticket Fields 설정을 확인하세요.
예시
소프트웨어 버그하드웨어 장애사용자 오류네트워크 장애
|
|||
|
만족도 평가
SatisfactionRating
|
인시던트 해결 후 최종 사용자가 제출한 만족도 평가입니다. | ||
|
설명
이 속성은 지원 경험에 대한 고객 의견을 기록하며, 일반적으로 티켓이 해결된 후 설문을 통해 수집합니다. Zendesk에서 주로 사용하는 평가는 '좋음' 또는 '나쁨'입니다. 만족도 평가는 프로세스 효율을 직접 측정하지는 않지만, 결과를 보여주는 중요한 지표입니다. process mining에서는 프로세스 변형과 만족도 평가를 함께 분석해 어떤 해결 경로가 고객 만족도를 높이는지 파악할 수 있습니다. 예를 들어 이관이 많은 인시던트의 평가가 더 낮은지 확인할 수 있습니다.
중요한 이유
프로세스 특성과 함께 분석할 수 있는 주요 결과 지표로, 프로세스 성과가 사용자 만족도에 미치는 영향을 파악하는 데 도움이 됩니다.
확보 방법
Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json)의 satisfaction_rating.score 필드입니다.
예시
좋음나쁨제공됨제공되지 않음
|
|||
|
심각도
Severity
|
인시던트가 비즈니스에 미치는 영향 수준입니다. | ||
|
설명
심각도는 인시던트가 비즈니스에 미치는 영향을 나타냅니다. 전체 긴급도를 정할 때 우선순위와 함께 고려하는 경우가 많으며, 일반적으로 Zendesk에서 사용자 지정 필드로 설정합니다. 심각도를 분석하면 처리 중인 인시던트의 중요도를 파악할 수 있습니다. 'SLA 준수 모니터링' 및 '우선순위 지정 효과 지표' 대시보드에서 데이터를 구분하는 기준으로도 사용됩니다. 심각도별 프로세스 흐름을 비교하면 심각도가 높은 인시던트에 적절한 속도와 리소스를 투입하고 있는지 확인할 수 있습니다.
중요한 이유
인시던트가 비즈니스에 미치는 영향을 나타내므로, 가장 중요한 문제에 집중해 효율적으로 해결할 수 있습니다.
확보 방법
일반적으로 사용자 지정 필드입니다. Zendesk Admin Center에서 Ticket Fields 설정을 확인하세요.
예시
1 - 심각2 - 높음3 - 보통4 - 낮음
|
|||
|
이관 횟수
HandoffCount
|
인시던트가 다른 상담원이나 그룹에 재배정된 총횟수입니다. | ||
|
설명
이 계산 지표는 인시던트의 담당자가 바뀐 횟수를 나타냅니다. 케이스에서 Assignee 또는 AssignedGroup 필드가 변경될 때마다 횟수가 증가합니다. 이관은 인시던트 관리에서 비효율과 지연을 일으키는 흔한 원인입니다. 이관 횟수가 많으면 라우팅 규칙이 명확하지 않거나, 지원팀의 지식이 부족하거나, 프로세스가 지나치게 복잡할 수 있습니다. 이 지표는 '인시던트당 평균 이관 횟수' KPI의 기준이며, '이관 및 재작업 분석' 대시보드에 중요합니다.
중요한 이유
담당자 변경으로 발생하는 프로세스 마찰을 수치화해 해결 시간을 늘리는 라우팅 비효율과 지식 부족을 찾을 수 있습니다.
확보 방법
인시던트의 AssignedGroup 또는 Assignee 필드가 변경된 횟수를 세어 계산합니다.
예시
0135
|
|||
|
자동화 여부
IsAutomated
|
활동을 자동화 시스템이 수행했는지 사람인 상담원이 수행했는지를 나타내는 불리언 값입니다. | ||
|
설명
이 파생 속성을 사용하면 사람이 수행한 이벤트와 시스템 자동화, 트리거 또는 API 연동으로 발생한 이벤트를 구분할 수 있습니다. 일반적으로 이벤트 작성자가 알려진 시스템 사용자에 해당하는지 확인해 판별합니다. 자동화 수준을 파악하는 것은 현대적인 프로세스 분석에서 중요합니다. 자동화 규칙의 효과를 평가하고, 자동화할 수 있는 수동 작업을 찾으며, 자동화가 효율과 해결 시간에 미치는 영향을 측정할 수 있습니다. 이 속성을 기준으로 자동화 활동과 수동 활동의 프로세스 흐름을 비교할 수 있습니다.
중요한 이유
사람의 작업과 시스템 작업을 구분해 자동화가 프로세스 효율에 미치는 영향을 분석하고, 추가 자동화 기회를 찾을 수 있습니다.
확보 방법
이벤트 작성자(Ticket Audits API의 author_id)가 알려진 시스템 사용자 또는 자동화 사용자에 해당하는지 확인해 산출합니다.
예시
truefalse
|
|||
|
접수자
Submitter
|
인시던트를 처음 신고한 최종 사용자 또는 시스템입니다. | ||
|
설명
이 속성은 티켓을 생성한 사람이나 주체를 식별합니다. 상담원이 다른 사람을 대신해 티켓을 생성할 수 있으므로 요청자와는 구분됩니다. 분석 시 접수자를 기준으로 어떤 사용자가 문제를 신고하는지 파악할 수 있습니다. 조직 데이터와 함께 살펴보면 특정 고객이나 사용자 그룹에서 인시던트가 많이 발생하는지 확인할 수 있습니다. 이를 바탕으로 선제적 지원이나 교육을 계획할 수 있습니다.
중요한 이유
인시던트 신고의 출처를 식별합니다. 특정 사용자, 부서 또는 자동화 시스템과 관련된 패턴을 분석할 수 있습니다.
확보 방법
Zendesk Tickets API의 submitter_id 필드입니다.
예시
alice.jones@example.combob.williams@example.com시스템 모니터
|
|||
|
최초 접촉 해결 여부
IsFirstContactResolution
|
인시던트가 다른 담당자나 그룹으로 이관되지 않고 최초 담당 상담원 또는 그룹에 의해 해결되었는지를 나타내는 불리언 값입니다. | ||
|
설명
최초 접촉 해결(First Contact Resolution, FCR)은 지원 센터의 효율과 고객 만족도를 측정하는 주요 지표입니다. 이 계산 속성은 다른 상담원이나 팀에 재배정되지 않고 해결된 인시던트를 표시합니다. 일반적으로 티켓이 최초 담당 상담원과 그룹에 배정된 상태로 '해결됨'에 도달했는지 확인합니다. process mining에서는 FCR 비율을 직접 계산하고, FCR 인시던트와 에스컬레이션이 필요한 인시던트의 처리 경로를 비교할 수 있습니다. 이를 통해 일선 지원팀의 해결 역량을 높일 기회를 찾을 수 있습니다.
중요한 이유
최초 지원 접점의 효율을 직접 측정하고, 프로세스 초기에 문제를 해결할 기회를 찾는 데 도움이 됩니다.
확보 방법
계산된 불리언 값입니다. 티켓 상태가 '해결됨' 또는 '종료됨'이고 인시던트 처리 주기 동안 담당 상담원이나 담당 그룹이 한 곳으로 유지된 경우 참입니다.
예시
truefalse
|
|||
|
케이스 처리 시간
CaseDuration
|
인시던트가 생성된 시점부터 최종 종료될 때까지 걸린 총시간입니다. | ||
|
설명
이 계산 지표는 인시던트 하나의 전체 처리 주기를 나타냅니다. 첫 이벤트(예: '인시던트 생성')와 마지막 이벤트(예: '인시던트 종료')의 타임스탬프 차이로 계산합니다. 케이스 처리 시간은 전체 프로세스 효율을 측정하는 주요 KPI입니다. 대시보드에서 평균 처리 주기를 표시하고, 장기 미해결 케이스를 찾으며, 시간에 따른 추세를 분석하는 데 널리 사용됩니다. 프로세스가 인시던트를 얼마나 빠르게 처리하고 해결하는지 보여주는 종합 지표입니다.
중요한 이유
전체 프로세스 처리 속도를 측정하고 해결 시간이 길어지는 원인을 찾는 주요 KPI입니다.
확보 방법
각 Incident ID의 마지막 이벤트와 첫 이벤트 타임스탬프 간 차이로 계산합니다.
예시
25920060480086400
|
|||
|
태그
Tags
|
분류와 맥락을 위해 인시던트에 적용하는 태그 목록입니다. | ||
|
설명
태그는 티켓에 추가해 맥락을 보완하거나 분류 및 라우팅에 활용할 수 있는 유연한 레이블입니다. 상담원이 직접 추가하거나 트리거와 자동화를 통해 자동으로 추가할 수 있습니다. 태그는 process mining 분석에 유용한 데이터입니다. 예를 들어 특정 제품 출시('launch_q4')나 알려진 서비스 중단('outage_20231027')과 관련된 인시던트만 필터링하는 등 세부적인 분석 기준을 만들 수 있습니다. 표준 티켓 필드만으로는 어려운 심층 분석도 가능합니다.
중요한 이유
인시던트를 유연하게 분류하고 필터링할 수 있어, 표준 필드만으로는 어려운 맥락별 상세 분석을 지원합니다.
확보 방법
Zendesk Tickets API의 tags 필드입니다.
예시
vip_usernetwork_issueoutage_20231027billing_related
|
|||
|
티켓 유형
TicketType
|
티켓의 분류입니다. 예: '인시던트', '문제', '질문', '작업'. | ||
|
설명
이 필드는 요청의 성격에 따라 티켓을 분류합니다. 인시던트 관리 프로세스에서는 계획되지 않은 IT 서비스 중단이나 품질 저하를 나타내는 '인시던트' 유형의 티켓을 주로 다룹니다. 분석에서는 이 속성을 필터로 사용해 프로세스 보기에 인시던트만 포함할 수 있습니다. ITSM 전반을 분석할 때는 인시던트, 문제, 서비스 요청 처리 프로세스를 비교하는 데도 활용할 수 있습니다.
중요한 이유
인시던트만 대상으로 데이터를 필터링해 인시던트 관리 주기에 맞는 프로세스 분석을 수행할 수 있습니다.
확보 방법
Zendesk Tickets API의 type 필드입니다.
예시
인시던트문제질문작업
|
|||
인시던트 관리 활동
| 활동 | 설명 | ||
|---|---|---|---|
|
상태가 Open으로 변경
|
상담원이 인시던트를 본격적으로 처리하기 시작했음을 나타냅니다. 일반적으로 티켓의 'status' 필드가 'new'에서 'open'으로 바뀐 기록을 바탕으로 추정하며, 조사와 진단 단계의 시작을 뜻합니다. | ||
|
중요한 이유
대기 상태에서 실제 처리 상태로 전환되는 시점입니다. 티켓이 'new' 상태에 머물다가 'open'으로 바뀌기까지 걸린 시간은 최초 응답 시간을 측정하는 주요 지표입니다.
확보 방법
티켓 감사 로그에서 'status' 필드의 새 값이 'open'이고 이전 값이 'new'인 'Change' 이벤트를 찾아 추정합니다.
기록
상태 필드가 'new'에서 'open'으로 변경된 것을 기준으로 추론합니다.
이벤트 유형
inferred
|
|||
|
인시던트 생성
|
Zendesk에서 새 티켓이 생성되면 인시던트 처리 주기가 시작됩니다. Zendesk의 티켓 생성 감사 로그에 명시적으로 기록되며, 각 케이스의 시작점이 됩니다. | ||
|
중요한 이유
주요 시작 활동입니다. 이 이벤트부터 다른 이벤트까지 걸린 시간을 분석하면 전체 티켓 처리 기간과 최초 응답 시간을 측정할 수 있습니다.
확보 방법
Zendesk 티켓 감사 로그에 명시적으로 기록되는 이벤트입니다. 새 티켓이 생성될 때마다 해당 타임스탬프와 함께 'Create' 이벤트가 생성됩니다.
기록
감사 로그의 티켓 생성 이벤트에서 직접 가져옵니다.
이벤트 유형
explicit
|
|||
|
인시던트 종료
|
티켓이 영구적으로 종료되면 인시던트 처리 주기가 끝납니다. Zendesk에서는 해결 처리 후 일정 시간이 지나면 자동으로 종료되는 경우가 많으며, 최종 상태 변경으로 기록됩니다. | ||
|
중요한 이유
프로세스의 최종 종료 활동입니다. '인시던트 생성'부터 이 이벤트까지의 시간을 계산해 전체 처리 기간을 확인할 수 있습니다.
확보 방법
티켓 감사 로그에서 'status' 필드의 새 값이 'closed'가 되는 'Change' 이벤트를 통해 가져옵니다.
기록
'status' 필드가 'closed'로 변경된 'Change' 이벤트를 찾아 식별합니다.
이벤트 유형
explicit
|
|||
|
인시던트 해결
|
상담원이 해결책을 적용하고 티켓을 'solved'로 표시하는 주요 단계입니다. 티켓 감사 로그에 상태 변경으로 명시적으로 기록됩니다. | ||
|
중요한 이유
주요 해결 활동으로, 해결까지 걸린 시간을 측정하는 데 중요한 기준입니다. 이 이벤트부터 '인시던트 종료'까지의 시간은 사용자 확인 또는 자동 종료에 걸린 기간을 나타냅니다.
확보 방법
티켓 감사 로그에서 'status' 필드의 새 값이 'solved'가 되는 'Change' 이벤트를 통해 가져옵니다.
기록
'status' 필드가 'solved'로 변경된 'Change' 이벤트를 찾아 식별합니다.
이벤트 유형
explicit
|
|||
|
티켓 재배정
|
최초 배정 후 티켓 담당이 한 상담원이나 그룹에서 다른 상담원이나 그룹으로 변경되는 경우입니다. 티켓 감사 기록에 명시적인 이벤트로 남습니다. | ||
|
중요한 이유
재배정은 인계와 재작업을 분석하는 데 중요합니다. 재배정이 잦으면 최초 라우팅 오류, 복잡한 문제 또는 프로세스 병목을 나타낼 수 있습니다.
확보 방법
티켓 감사 로그에서 'assignee_id' 또는 'group_id' 필드가 처음 입력된 이후 발생한 'Change' 이벤트를 찾아 가져옵니다.
기록
'assignee_id' 또는 'group_id' 필드의 후속 'Change' 이벤트를 찾아 식별합니다.
이벤트 유형
explicit
|
|||
|
티켓을 상담원에게 배정
|
티켓을 특정 상담원에게 배정해 처리를 맡기는 활동입니다. 티켓 감사 기록에 명시적으로 남으며, 담당자가 개별적으로 업무를 맡았음을 나타냅니다. | ||
|
중요한 이유
최초 배정까지 걸린 시간을 측정하는 데 필요한 주요 단계입니다. 인계와 재작업, 최초 문의 해결률을 분석하는 기준이 됩니다.
확보 방법
티켓 감사 로그에서 'assignee_id' 필드가 입력되거나 변경될 때 기록됩니다. 최초 배정은 KPI 계산에 중요한 기준입니다.
기록
티켓 감사 로그에서 'assignee_id' 필드의 'Change' 이벤트를 찾아 식별합니다.
이벤트 유형
explicit
|
|||
|
SLA 목표 미준수
|
최초 응답 시간이나 해결 시간 등 정해진 서비스 수준 협약을 티켓이 지키지 못한 시점을 나타냅니다. SLA 정책 정의와 티켓 업데이트 타임스탬프를 기준으로 계산합니다. | ||
|
중요한 이유
SLA 준수 모니터링에 직접 활용되는 이벤트입니다. 서비스 안정성과 고객 신뢰를 높이려면 미준수가 언제, 왜 발생하는지 파악해야 합니다.
확보 방법
계산을 통해 도출되는 이벤트입니다. 티켓과 연결된 'sla_policy_metrics' 데이터를 분석하고 각 SLA 목표의 'breached_at' 타임스탬프를 사용해 산출할 수 있습니다.
기록
티켓의 SLA 지표 데이터에 있는 'breached_at' 타임스탬프에서 도출합니다.
이벤트 유형
calculated
|
|||
|
공개 답변 전송
|
지원 상담원이 최종 사용자에게 메시지를 보낸 경우입니다. 티켓에 공개 댓글이 추가될 때마다 Zendesk에 명시적인 이벤트로 기록됩니다. | ||
|
중요한 이유
공개 답변을 추적하면 소통 빈도를 파악할 수 있습니다. 사용자 확인이 지연되는 원인을 분석할 때도 주요 타임라인 정보로 활용할 수 있습니다.
확보 방법
티켓 댓글 데이터에서 가져옵니다. 'public' 속성이 true인 댓글을 공개 댓글로 식별합니다.
기록
'public: true'인 새 댓글이 티켓에 추가될 때 기록되는 이벤트입니다.
이벤트 유형
explicit
|
|||
|
내부 메모 추가
|
상담원이 다른 팀원과 공유하기 위해 티켓에 비공개 메모를 추가하는 내부 협업 활동입니다. 댓글이 공개되지 않도록 설정되면 명시적으로 기록됩니다. | ||
|
중요한 이유
내부 메모를 분석하면 협업이 필요한 복잡한 문제를 파악할 수 있습니다. 메모가 지나치게 많다면 지식 부족이나 프로세스 비효율을 나타낼 수 있습니다.
확보 방법
티켓 댓글 데이터에서 가져옵니다. 'public' 속성이 false인 댓글을 내부 메모로 식별합니다.
기록
'public: false'인 새 댓글이 티켓에 추가될 때 기록되는 이벤트입니다.
이벤트 유형
explicit
|
|||
|
사용자 만족도 평가
|
최종 사용자가 지원 서비스에 대한 만족도를 평가하는 시점입니다. 티켓이 해결된 후 Zendesk에 명시적인 이벤트로 기록됩니다. | ||
|
중요한 이유
만족도 평가를 분석하면 상담원 성과와 프로세스 효과에 대한 피드백을 얻고, 프로세스 지표를 고객 경험과 연결할 수 있습니다.
확보 방법
티켓과 연결된 만족도 평가 데이터에서 가져옵니다. 일반적으로 점수('good' 또는 'bad')와 선택적 댓글이 포함됩니다.
기록
티켓에 만족도 평가가 제출될 때 기록되는 이벤트입니다.
이벤트 유형
explicit
|
|||
|
상태가 Pending으로 변경
|
요청자의 답변을 기다리는 동안 처리가 일시 중지되었음을 나타냅니다. 티켓의 'status' 필드가 'pending'으로 변경된 기록을 바탕으로 추정합니다. | ||
|
중요한 이유
사용자 확인 대기 시간을 계산하는 데 중요한 활동입니다. 이 상태가 오래 지속되면 전체 해결 시간이 크게 늘어나고 소통 지연이 드러날 수 있습니다.
확보 방법
티켓 감사 로그에서 'status' 필드의 새 값이 'pending'인 'Change' 이벤트를 찾아 추정합니다.
기록
상태 필드가 'pending'으로 변경된 기록을 바탕으로 추정합니다.
이벤트 유형
inferred
|
|||
|
우선순위 설정
|
인시던트의 우선순위(예: 낮음, 보통, 높음, 긴급)를 지정합니다. 명시적인 변경 이벤트로 기록되며, 티켓의 긴급도와 필요한 응답 시간을 결정합니다. | ||
|
중요한 이유
우선순위를 언제, 어떻게 설정했는지 추적하면 '우선순위 지정 효과 지표' 대시보드를 구성하고 긴급한 문제를 신속히 처리하는 데 도움이 됩니다.
확보 방법
티켓 감사 로그의 'priority' 필드에 대한 'Change' 이벤트에서 가져옵니다. 이후 변경도 추적해 우선순위 변경률 KPI를 측정할 수 있습니다.
기록
티켓 감사 로그에서 'priority' 필드의 'Change' 이벤트를 찾아 식별합니다.
이벤트 유형
explicit
|
|||
|
티켓을 그룹에 배정
|
인시던트를 특정 지원 그룹으로 처음 라우팅하거나 분류하는 단계입니다. 일반적으로 담당 부서를 정하는 첫 단계이며, 티켓 감사 기록에 명시적인 변경 이벤트로 남습니다. | ||
|
중요한 이유
그룹 배정을 추적하면 초기 분류의 효율성을 분석하고, 티켓이 적절한 팀에 전달되기까지의 지연을 파악할 수 있습니다.
확보 방법
티켓 감사 로그에서 'group_id' 필드가 설정되거나 변경될 때 기록됩니다. 티켓 생성 후 처음 발생한 변경이 최초 배정입니다.
기록
티켓 감사 로그에서 'group_id' 필드의 'Change' 이벤트를 찾아 식별합니다.
이벤트 유형
explicit
|
|||
데이터 추출 가이드
시작할 준비가 되셨나요?
이 템플릿으로 데이터 준비 과정을 간소화하고 인시던트 관리 성과를 파악하세요. 지금 프로세스 개선을 시작해 보세요.
인시던트 관리를 개선하고 더 빠르게 해결하세요
MTTR을 35% 단축하고 반복 인시던트를 줄여 만족도를 높이세요.
신용카드 없이 시작할 수 있습니다. 몇 분 만에 개선을 시작하세요.