서비스 요청 관리 데이터 템플릿

Zendesk Support
서비스 요청 관리 데이터 템플릿

서비스 요청 관리 데이터 템플릿

이 템플릿은 Zendesk Support의 서비스 요청 관리 프로세스를 분석하는 데 필요한 데이터를 추출하는 방법을 안내합니다. 수집할 데이터 속성과 추적할 주요 활동, 시스템에서 직접 정보를 추출하는 방법을 확인할 수 있습니다. 이 자료를 활용해 process mining에 필요한 이벤트 로그를 구성하세요.
  • 분석에 권장되는 주요 속성
  • 추적할 주요 서비스 요청 활동
  • Zendesk Support 데이터 추출 안내
이벤트 로그가 처음이신가요? 알아보기 process mining 이벤트 로그 만드는 방법.

서비스 요청 관리 속성

Zendesk Support에서 서비스 요청 관리를 분석할 때 이벤트 로그에 포함할 것을 권장하는 데이터 필드입니다.
5 필수 7 권장 9 선택 사항
이름 설명
서비스 요청 ID
ServiceRequestId
Zendesk에서 각 서비스 요청 티켓을 고유하게 식별하는 ID입니다.
설명

서비스 요청 ID는 Zendesk에서 티켓 ID라고도 하며, 각 케이스의 기본 키로 사용됩니다. 요청이 생성된 시점부터 종료될 때까지 관련 활동, 댓글, 상태 변경을 모두 연결합니다. 이를 통해 개별 요청의 전체 수명 주기를 추적할 수 있습니다.

process mining 분석에서 이 속성은 기본이 됩니다. 케이스를 정의해 프로세스 흐름을 재구성하고, 변형을 식별하며, 케이스별 처리 시간과 같은 지표를 계산할 수 있습니다. 전체 프로세스에서 각 이벤트의 맥락을 파악하려면 데이터 세트의 모든 이벤트에 서비스 요청 ID가 연결되어야 합니다.

중요한 이유

서비스 요청의 전체 여정에서 발생한 모든 이벤트를 연결하는 필수 케이스 식별자입니다. 이를 통해 프로세스 전반을 분석할 수 있습니다.

확보 방법

Zendesk Tickets API의 'id' 필드입니다.

예시
102451024610247
시작 시간
EventTimestamp
활동이 발생한 정확한 날짜와 시간입니다.
설명

이벤트 타임스탬프 또는 시작 시간은 활동이 발생한 정확한 시점을 기록합니다. 예를 들어 상담원이 배정된 시점, 공개 답변이 전송된 시점, 티켓 상태가 'Resolved'로 변경된 시점을 나타냅니다. 이 시간 데이터는 각 Zendesk 티켓의 감사 로그에서 가져옵니다.

시간 기반 분석에 반드시 필요한 속성입니다. 이벤트를 시간순으로 정렬하고, 활동 간 소요 시간과 대기 시간을 계산하며, 전체 케이스 처리 시간을 분석하는 데 사용됩니다. 병목을 찾고 SLA와 같은 시간 기준 목표에 대한 성과를 평가하는 데도 중요합니다.

중요한 이유

이 타임스탬프는 이벤트를 시간순으로 정렬하며, 소요 시간, 성과, 병목 분석에 필수적입니다.

확보 방법

Zendesk Ticket Audits API에서 각 감사 이벤트의 'created_at' 필드를 사용합니다.

예시
2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
활동
ActivityName
서비스 요청에서 발생한 업무 활동 또는 이벤트의 이름입니다.
설명

활동은 서비스 요청 수명 주기의 개별 단계나 이벤트를 나타냅니다. 예를 들어 '서비스 요청 생성', '상담원에게 요청 배정', '서비스 요청 해결' 등이 있습니다. 이러한 활동은 Zendesk 티켓 감사 로그에 기록된 변경 사항에서 도출됩니다. 감사 로그에는 상태, 담당자, 우선순위 필드의 변경과 댓글 추가 등이 기록됩니다.

활동 분석은 process mining의 중심입니다. 프로세스 맵을 시각화하고, 단계 간 병목을 찾고, 재작업 루프를 분석할 수 있습니다. 활동의 순서와 빈도를 파악하면 비효율과 프로세스 개선 기회를 찾을 수 있습니다.

중요한 이유

이 속성은 프로세스의 단계를 정의하며, 프로세스 맵을 시각화하고 흐름, 변형, 적합성을 분석하는 데 사용됩니다.

확보 방법

개념적으로 Zendesk Ticket Audits API에 기록된 이벤트에서 도출합니다. 예를 들어 'status' 필드가 'new'에서 'open'으로 변경되면 '요청 분류'와 같은 활동으로 매핑할 수 있습니다.

예시
서비스 요청 생성상담원 재배정서비스 요청 해결
원천 시스템
SourceSystem
데이터를 추출한 시스템을 나타냅니다.
설명

서비스 요청 데이터의 출처를 나타냅니다. 이 프로세스 보기에서는 값이 항상 'Zendesk Support'로 설정되어 서비스 관리 활동의 기록 시스템을 식별합니다.

여러 시스템을 연동한 환경에서는 데이터 계보를 추적하고 문제를 해결하는 데 중요한 필드입니다. 분석 범위를 의도한 시스템으로 한정하고, 여러 출처의 데이터를 결합할 때 각 데이터의 출처를 구분할 수 있습니다.

중요한 이유

데이터의 원천 시스템을 식별해 데이터 계보를 추적하고 여러 시스템의 데이터를 결합할 때 혼동을 방지합니다.

확보 방법

데이터 추출 및 변환 과정에서 추가하는 고정값('Zendesk Support')입니다.

예시
Zendesk Support
최근 데이터 업데이트
LastDataUpdate
원천 시스템에서 데이터를 마지막으로 새로 고친 시점을 나타내는 타임스탬프입니다.
설명

Zendesk Support에서 데이터를 가장 최근에 추출한 날짜와 시간을 기록합니다. 분석 중인 데이터의 최신성을 파악할 수 있어 사용자가 프로세스 보기의 기준 시점을 확인할 수 있습니다.

지속적인 모니터링과 대시보드 운영에 중요한 정보입니다. 분석가와 업무 담당자는 거의 실시간 데이터인지 이전 기간의 스냅샷인지 확인할 수 있습니다. 데이터의 기준 시점은 분석 결과의 타당성에 영향을 줍니다.

중요한 이유

데이터가 얼마나 최신인지 알려 주어 분석의 기준 시점을 파악할 수 있습니다.

확보 방법

데이터 추출 시 데이터 세트에 생성해 기록하는 메타데이터 필드입니다.

예시
2023-10-27T08:00:00Z
담당 팀
AssignedTeam
서비스 요청을 담당하는 지원팀 또는 그룹입니다.
설명

지원 조직 내에서 서비스 요청을 담당하는 팀 또는 그룹을 나타냅니다. Zendesk에서는 이를 'Groups'라고 합니다. 티켓은 개별 상담원에게 배정되기 전에 그룹에 먼저 배정되는 경우가 많습니다.

담당 팀별 분석은 팀 단위의 성과와 업무량을 파악하는 데 중요합니다. 어떤 팀이 어떤 유형의 요청을 처리하는지, 평균 해결 시간과 SLA 준수율은 어떤지 확인할 수 있습니다. 상담원 및 팀 성과 대시보드의 주요 분석 기준입니다.

중요한 이유

팀별 성과와 업무량 균형을 분석하고 지원 그룹 간 라우팅 효율을 파악할 수 있습니다.

확보 방법

Tickets API 응답의 'group_id'를 Zendesk Groups API와 조인해 가져옵니다.

예시
1단계 지원기술 지원청구
상담원 이름
AgentName
이벤트 발생 시 서비스 요청에 배정된 상담원의 이름입니다.
설명

서비스 요청을 담당하는 지원 상담원을 식별합니다. 티켓 수명 주기 동안 담당 상담원이 여러 번 바뀔 수 있으며, 이 필드에는 각 단계의 담당자가 기록됩니다.

상담원 이름은 성과 분석에 중요합니다. 데이터를 필터링하고 구분해 업무량 분포, 상담원별 해결 시간, 재배정 빈도를 평가할 수 있습니다. 이를 통해 상담원 및 팀 성과 대시보드를 구성하고 전체 프로세스 효율에 대한 개인별 기여도를 파악할 수 있습니다.

중요한 이유

상담원 성과와 업무량 분포를 분석하고 재배정이 해결 시간에 미치는 영향을 파악하는 데 중요합니다.

확보 방법

Tickets API 응답의 'assignee_id'를 Zendesk Users API와 조인해 가져옵니다.

예시
Jane DoeJohn SmithEmily Jones
서비스 유형
ServiceType
서비스 요청의 범주 또는 유형입니다(예: 인시던트, 문의, 문제, 작업).
설명

서비스 유형은 요청의 성격을 분류합니다. Zendesk는 'type' 필드로 지원 요청의 종류를 구분합니다. 이 초기 분류를 바탕으로 티켓을 적절한 팀에 라우팅하고 해당 프로세스를 적용할 수 있습니다.

이 속성은 필터링과 비교 분석에 필요합니다. 요청 유형별 프로세스 흐름을 살펴볼 수 있으며, 유형에 따라 해결 경로와 SLA가 크게 다를 수 있습니다. 상담원 및 팀 성과 대시보드에서 특정 요청 유형을 가장 잘 처리하는 팀이나 상담원을 파악하는 주요 기준입니다.

중요한 이유

요청을 유형별로 분류해 인시던트와 문의처럼 서로 다른 경로를 따르는 프로세스를 따로 분석할 수 있습니다.

확보 방법

Zendesk Tickets API의 'type' 필드입니다.

예시
문의인시던트문제작업
요청 상태
RequestStatus
이벤트 발생 시점의 서비스 요청 상태입니다(예: 신규, 진행 중, 대기 중).
설명

요청 상태는 특정 시점의 티켓 상태를 나타냅니다. Zendesk의 표준 상태에는 신규, 진행 중, 대기 중, 보류, 해결, 종료 등이 있으며, 요청의 수명 주기상 진행 상황을 표시합니다. 이 필드의 변경은 이벤트 로그에 활동을 생성하는 주요 기준입니다.

상태별 소요 시간을 분석하는 것은 병목 분석의 기본입니다. 예를 들어 티켓이 '대기 중' 또는 '보류' 상태에 너무 오래 머무는 지점을 찾을 수 있습니다. 상태 전환을 파악하면 재작업 루프를 발견하는 데도 도움이 됩니다.

중요한 이유

상태를 추적하면 요청의 진행 상황을 파악하고 대기 상태와 실제 처리 상태에 각각 얼마나 시간이 걸리는지 확인할 수 있습니다.

확보 방법

Zendesk Tickets API의 'status' 필드입니다.

예시
신규진행 중대기 중해결종료
요청 우선순위
RequestPriority
서비스 요청에 지정된 우선순위입니다. 낮음, 보통, 높음, 긴급 등으로 표시합니다.
설명

요청 우선순위는 서비스 요청의 긴급도를 나타내는 분류입니다. 우선순위에 따라 목표 해결 시간과 티켓에 적용되는 SLA 정책이 달라지는 경우가 많습니다. 시스템이나 사용자가 처음 설정할 수 있으며, 티켓 수명 주기 동안 상담원이 변경할 수도 있습니다.

이 속성은 데이터 구분과 근본 원인 분석에 중요합니다. 우선순위가 높은 티켓이 낮은 티켓보다 빠르게 해결되는지 분석할 수 있으며, '서비스 요청 에스컬레이션 추이' 및 'SLA 준수' 대시보드의 주요 분석 기준입니다.

중요한 이유

요청을 긴급도별로 구분해 SLA 준수 여부를 분석하고 긴급한 문제를 신속히 처리할 수 있습니다.

확보 방법

Zendesk Tickets API의 'priority' 필드입니다.

예시
낮음보통높음긴급
요청 채널
RequestChannel
서비스 요청을 제출한 채널입니다(예: 이메일, 웹 양식, 전화).
설명

서비스 요청이 접수된 경로를 나타냅니다. Zendesk는 티켓이 이메일, 웹 포털, API 연동, 채팅 등 어떤 채널을 통해 생성되었는지 기록합니다. 이를 통해 고객이 지원을 요청한 방식을 파악할 수 있습니다.

요청 채널은 분석에 유용한 기준입니다. 요청 채널 효율 대시보드에서 채널별 해결 시간, 만족도, 재작업률을 비교할 수 있습니다. 이를 바탕으로 지원 채널을 개선하고 사용자가 더 효율적인 채널을 이용하도록 안내할 수 있습니다.

중요한 이유

고객 지원 채널별 효율과 결과를 분석해 개선이 필요한 부분을 찾을 수 있습니다.

확보 방법

Zendesk Tickets API의 'via' 객체와 'channel' 속성입니다.

예시
웹이메일API채팅
티켓 태그
TicketTags
분류와 라우팅을 위해 서비스 요청에 적용한 태그 목록입니다.
설명

태그는 상담원이 직접 추가하거나 업무 규칙에 따라 자동으로 적용할 수 있는 유연한 레이블입니다. 유형이나 우선순위 같은 표준 필드로 표현하기 어려운 맥락이나 범주를 티켓에 추가할 때 사용합니다.

태그는 process mining 분석에서 다양하게 활용할 수 있습니다. 특정 상황을 필터링하고, 사용자 지정 워크플로를 추적하거나, 근본 원인을 찾는 데 사용할 수 있습니다. 예를 들어 'VIP' 태그로 주요 고객의 프로세스를 분석하거나, 'product_bug' 태그로 결함 보고의 수명 주기를 추적할 수 있습니다.

중요한 이유

데이터를 다양한 기준으로 살펴볼 수 있어 다른 필드에 없는 티켓 속성이나 특정 하위 프로세스를 자세히 분석할 수 있습니다.

확보 방법

Zendesk Tickets API의 'tags' 필드입니다. 문자열 배열입니다.

예시
영업 문의청구 문제기능 요청VIP 고객
SLA 위반 여부
IsSlaBreached
서비스 요청이 SLA 목표를 하나라도 위반했는지 나타내는 표시입니다.
설명

이 속성은 티켓의 SLA 결과를 나타내는 불리언 또는 범주형 표시입니다. '충족', '위반', '진행 중' 등의 상태를 표시할 수 있습니다. 적용된 SLA 정책의 목표 시간과 실제 응답 또는 해결 시간을 비교해 판정합니다.

'SLA 준수 및 위반 분석' 대시보드에 필요한 속성입니다. 이를 사용하면 규정을 준수한 티켓과 준수하지 않은 티켓을 쉽게 집계하고 시각화할 수 있습니다. 위반 티켓의 프로세스 특성을 추가로 분석하면 대기 시간 장기화나 과도한 재할당 등 근본 원인을 찾을 수 있습니다.

중요한 이유

서비스 수준 약속에 대한 성과를 직접 측정하며, 서비스 품질과 고객 만족도를 보여주는 주요 지표입니다.

확보 방법

티켓별 SLA 상태 정보를 제공하는 Zendesk Ticket Metrics API에서 가져옵니다.

예시
충족위반진행 중
SLA 정책 이름
SlaPolicyName
요청에 적용된 서비스 수준 계약(SLA) 정책의 이름입니다.
설명

이 속성은 서비스 요청의 응답 및 해결 목표 시간을 정하는 SLA 정책을 나타냅니다. 정책은 일반적으로 요청의 우선순위와 유형, 고객의 구독 등급 등에 따라 결정됩니다.

적용된 SLA 정책을 알아야 'SLA 준수 및 위반 분석' 대시보드에서 성과를 정확히 평가할 수 있습니다. 정책마다 목표가 다르므로, 이 정보를 바탕으로 각 티켓이 해당 서비스 수준 목표를 충족했는지 공정하게 판단할 수 있습니다.

중요한 이유

요청에 적용된 목표 기준을 확인해 SLA 분석에 필요한 맥락을 제공하고, 규정 준수 보고의 정확도를 높입니다.

확보 방법

Zendesk Ticket Metrics API. SLA 데이터는 티켓의 메트릭에 포함되는 경우가 많습니다.

예시
긴급 - 1시간 이내 응답일반 - 24시간 이내 해결프리미엄 고객 SLA
만족도 평가
SatisfactionRating
티켓이 해결된 후 요청자가 제공한 만족도 점수입니다.
설명

고객이 지원을 받은 경험에 대한 의견을 기록합니다. 일반적으로 티켓이 해결로 표시된 후 설문을 통해 수집하며, '좋음' 또는 '나쁨'과 같은 평가와 의견이 포함될 수 있습니다.

만족도 평가는 주요 결과 지표입니다. 프로세스 패턴과 만족도 점수를 연계하면 어떤 프로세스가 고객 만족 또는 불만족으로 이어지는지 파악할 수 있습니다. 예를 들어 재배정이 잦거나 해결 시간이 긴 경우 만족도 평가가 낮아지는지 분석할 수 있습니다.

중요한 이유

프로세스 실행과 고객 결과를 직접 연결해 고객 만족에 영향을 미치는 프로세스 행동을 파악할 수 있습니다.

확보 방법

Zendesk Tickets API의 'satisfaction_rating.score' 또는 'satisfaction_rating.reason' 필드입니다.

예시
좋음나쁨제공됨
상담원 재할당 횟수
AgentReassignmentCount
요청이 한 상담원에서 다른 상담원으로 재할당된 총횟수입니다.
설명

이 속성은 티켓의 'assignee_id' 필드가 변경될 때마다 횟수를 기록합니다. 티켓 하나의 재할당 횟수가 많다면 최초 배정 오류, 상담원의 지식 부족, 한 명이 처리하기 어려운 복잡한 요청 등 여러 프로세스 문제가 있을 수 있습니다.

프로세스 효율성을 측정하는 주요 지표로, '상담원 재할당률' KPI 분석에 활용됩니다. 재할당 횟수가 많은 사례를 분석하면 배정 규칙 개선, 상담원 교육, 지식 기반 자료 보강 등 티켓을 적합한 담당자에게 더 빠르게 전달할 방법을 찾을 수 있습니다.

중요한 이유

내부 인계 횟수를 파악하고 프로세스의 마찰 지점을 찾습니다. 재할당률이 높으면 지연과 비효율이 발생하는 경우가 많습니다.

확보 방법

티켓별 Zendesk Ticket Audits API의 'assignee_id' 변경 횟수를 세어 계산합니다.

예시
013
요청자 소속 조직
RequestorOrganization
요청자가 소속된 조직 또는 회사입니다.
설명

서비스 요청을 특정 고객 조직과 연결합니다. 서비스 수준 계약과 지원 계약을 조직 단위로 체결하는 B2B 지원 환경에서 특히 유용합니다.

조직별로 데이터를 분석하면 회사 단위의 지원 성과를 파악할 수 있습니다. 티켓이 많이 접수되는 조직, 같은 문제가 반복되는 조직, 만족도 점수가 낮은 조직을 찾을 수 있습니다. 계정 관리와 고객 상태의 전반적인 추이를 파악하는 데 도움이 됩니다.

중요한 이유

회사별로 요청을 묶어 B2B 서비스를 분석할 수 있습니다. 조직 단위의 고객 관계와 SLA를 관리하는 데 유용합니다.

확보 방법

Tickets API 응답의 'organization_id'를 Zendesk Organizations API와 조인해 가져옵니다.

예시
Acme CorporationGlobal Tech Inc.Innovate Solutions
요청자 이름
RequestorName
서비스 요청을 제출한 최종 사용자 또는 고객의 이름입니다.
설명

서비스 요청을 시작한 사람을 식별합니다. 요청을 특정 고객과 연결하면 지원 프로세스를 고객 관점에서 살펴볼 수 있습니다.

프로세스 분석에서 요청자를 기준으로 특정 고객이나 고객군의 패턴을 분석할 수 있습니다. 예를 들어 특정 고객의 해결 시간이 더 오래 걸리거나 재작업률이 높은지 조사해 사용 중인 제품이나 서비스의 문제를 파악할 수 있습니다.

중요한 이유

프로세스를 고객과 연결해 고객별 문제, 반복 요청, 만족도를 분석할 수 있습니다.

확보 방법

Tickets API 응답의 'requester_id'를 Zendesk Users API와 조인해 가져옵니다.

예시
Alice JohnsonBob WilliamsCharlie Brown
재작업 여부
IsRework
서비스 요청이 해결된 후 다시 열렸다면 참으로 표시됩니다.
설명

이 불리언 표시는 재작업이 발생한 사례를 식별합니다. 일반적으로 서비스 요청 상태가 '해결됨'에서 다시 열린 상태로 바뀌면 재작업으로 봅니다. 최초 해결이 충분하지 않아 고객이 같은 문제로 다시 문의한 경우입니다.

'서비스 요청 재작업률' KPI 계산과 '재작업 및 재개 활동 분석' 대시보드에 필요한 속성입니다. 재작업 사례를 구분하면 비효율적인 프로세스 흐름을 따로 분석하고, 요청이 다시 열린 원인을 찾아 최초 문의 해결률을 높일 수 있습니다.

중요한 이유

최종 해결에 이르지 못한 프로세스 사례를 찾아 품질과 효율성 문제를 드러냅니다. 이러한 문제는 고객 만족도에도 직접 영향을 줍니다.

확보 방법

Zendesk Ticket Audits API에서 티켓 상태의 변경 순서를 분석해 계산합니다. 'solved'에서 'open'으로 바뀌면 재작업으로 판단합니다.

예시
truefalse
종료 시간
EndTime
활동이 완료된 정확한 날짜와 시간입니다.
설명

종료 시간은 활동이 완료된 시점을 나타냅니다. Zendesk의 많은 이벤트는 순간적으로 발생하므로 종료 시간과 시작 시간이 같습니다. 하지만 '요청 보류'와 같은 상태 기반 활동의 종료 시간은 티켓이 보류 상태에서 해제된 시점입니다.

이 속성은 개별 활동의 소요 시간을 계산하는 데 필요하며, 병목 분석의 기준이 됩니다. 활동의 시작 시간과 종료 시간을 비교하면 처리 시간을 직접 측정해 시간이 가장 많이 걸리는 단계를 찾을 수 있습니다.

중요한 이유

개별 활동의 소요 시간을 계산할 수 있어 프로세스 병목을 찾고 단계별 효율을 측정하는 데 중요합니다.

확보 방법

개별 이벤트에서는 시작 시간과 같은 경우가 많습니다. 상태 유지 시간의 경우 상태를 변경하는 다음 이벤트의 타임스탬프를 사용합니다.

예시
2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
최초 문의 해결 여부
IsFirstContactResolution
재할당이나 요청자의 추가 답변 없이 최초 배정된 상담원이 요청을 해결했는지 나타내는 표시입니다.
설명

최초 문의 해결률(FCR)은 고객의 문제를 한 번의 상호작용으로 해결했는지 보여주는 주요 지표입니다. 계산된 이 속성은 재할당 없이 최초 배정된 상담원이 티켓을 해결하고, 상담원의 답변이 한 번만 있었을 때 참으로 표시됩니다.

이 속성은 '최초 문의 해결률' KPI 분석에 직접 활용됩니다. FCR 사례의 특성을 분석하면 프로세스 개선의 기준을 마련할 수 있습니다. 반대로 FCR에 실패한 사례를 살펴보면 상담원 교육, 지식 기반 문서, 최초 분류 절차를 개선할 기회를 찾을 수 있습니다.

중요한 이유

한 번의 응대로 문제를 해결하는 역량을 측정합니다. 이는 고객 만족도와 운영 효율성을 높이는 데 큰 영향을 줍니다.

확보 방법

여러 조건을 분석해야 하는 계산 속성입니다. 티켓의 이벤트 로그에서 상담원 재할당 여부와 상담원의 공개 답변 횟수를 확인해야 합니다.

예시
truefalse
필수 권장 선택 사항

서비스 요청 관리 활동

서비스 요청 프로세스를 정확히 파악하려면 이벤트 로그에 기록해야 하는 주요 단계와 이정표입니다.
7 권장 6 선택 사항
활동 설명
SLA 목표 미달
최초 응답 시간이나 해결 시간 등 정해진 SLA 목표를 서비스 요청이 충족하지 못한 시점을 나타냅니다. Zendesk는 목표를 달성하지 못하면 이를 명시적 이벤트로 기록합니다.
중요한 이유

규정 준수 모니터링에 중요한 이벤트이며 SLA 준수율 KPI를 계산하는 주요 입력값입니다. 서비스 약속을 지키지 못한 사례를 구체적으로 보여 줍니다.

확보 방법

Zendesk 티켓 이벤트 또는 감사 로그의 'SLABreach' 이벤트에서 가져옵니다. 이벤트에는 미달한 SLA 지표가 명시됩니다.

기록

티켓 데이터에 명시된 'SLABreach' 이벤트로 식별합니다.

이벤트 유형 explicit
공개 답변 전송
상담원이 요청자에게 보낸 모든 메시지를 나타냅니다. Zendesk 티켓 데이터에서 'public' 속성이 true인 명시적 'Comment' 이벤트로 기록됩니다.
중요한 이유

이 이벤트는 커뮤니케이션 빈도 분석, 상담원 응답 시간 측정, 요청 해결에 필요한 상호작용 횟수 파악에 중요합니다.

확보 방법

티켓 데이터에 명시적으로 기록된 'Comment' 이벤트입니다. 이벤트 세부 정보에 'public: true' 속성이 포함되어 내부 메모와 구분됩니다.

기록

'public' 플래그가 true로 설정된 티켓 'Comment' 이벤트에서 가져옵니다.

이벤트 유형 explicit
상담원에게 요청 배정
서비스 요청이 특정 상담원에게 처음 배정될 때 발생하는 활동입니다. 티켓 감사 로그의 'Change' 이벤트에서 'assignee_id' 필드가 null 또는 그룹 ID에서 특정 사용자 ID로 변경된 경우를 기준으로 추론합니다.
중요한 이유

상담원의 실제 업무가 시작되는 시점입니다. 최초 응답 시간, 최초 배정까지 걸린 시간, 상담원별 업무량 분포를 측정하는 데 중요합니다.

확보 방법

티켓 감사 로그에서 'assignee_id' 필드가 변경된 첫 번째 'Change' 이벤트를 기준으로 추론합니다. 이때 특정 사용자 ID가 설정되어 있어야 합니다.

기록

'assignee_id' 필드에 상담원이 설정된 첫 번째 변경 이벤트를 기준으로 추론합니다.

이벤트 유형 inferred
서비스 요청 생성
요청자가 어떤 채널을 통해 새 티켓을 제출하면 서비스 요청의 처리 과정이 시작됩니다. Zendesk 티켓 감사 로그에 'Create' 이벤트로 기록되므로 프로세스의 시작 시각을 명확히 확인할 수 있습니다.
중요한 이유

이 활동은 모든 서비스 요청의 주요 시작 이벤트입니다. 전체 처리 시간을 계산하고 요청 접수량을 분석하는 데 필요합니다.

확보 방법

Zendesk 티켓 감사 로그에 'Create' 이벤트 유형으로 기록됩니다. 이 이벤트의 타임스탬프가 서비스 요청 티켓의 생성 시각입니다.

기록

티켓 감사 로그의 'Create' 이벤트에서 직접 가져옵니다.

이벤트 유형 explicit
서비스 요청 재개
요청자가 상태가 'solved'인 요청에 답변하면 발생하며, 상태가 자동으로 'open'으로 변경됩니다. 제안된 해결책이 충분하지 않았음을 나타냅니다.
중요한 이유

이 활동은 재작업을 보여 주는 주요 지표입니다. 발생 빈도를 분석하면 해결 품질을 측정하고 고객 불만의 원인을 파악할 수 있습니다.

확보 방법

티켓 감사 로그에서 'status' 필드의 이전 값이 'solved'이고 새 값이 'open'인 'Change' 이벤트를 바탕으로 추론합니다.

기록

상태가 'solved'에서 'open'으로 변경된 경우를 바탕으로 추론합니다.

이벤트 유형 inferred
서비스 요청 종료
서비스 요청이 최종적으로 종료된 상태를 나타냅니다. 티켓은 일정 기간 'solved' 상태를 유지하면 자동으로 'closed' 상태로 전환되며, 이후에는 다시 열 수 없습니다.
중요한 이유

서비스 요청 프로세스가 완전히 끝나는 시점입니다. 전체 케이스 소요 시간을 계산할 때 최종 종료 시점으로 사용합니다.

확보 방법

티켓 감사 로그에서 'status' 필드의 새 값이 'closed'인 'Change' 이벤트를 바탕으로 추론합니다.

기록

감사 로그에서 상태가 'closed'로 변경된 'Change' 이벤트를 바탕으로 추론합니다.

이벤트 유형 inferred
서비스 요청 해결
상담원이 해결책을 제공하고 티켓 상태를 'solved'로 변경한 시점을 나타냅니다. 상담원 관점에서는 요청 처리가 완료된 상태지만, 요청자가 다시 열 수 있습니다.
중요한 이유

상담원의 실제 업무가 끝나는 주요 시점입니다. 이 상태에 도달하는 데 걸린 시간은 해결 효율을 측정하는 주요 지표입니다.

확보 방법

티켓 감사 로그에서 'status' 필드의 새 값이 'solved'인 'Change' 이벤트를 바탕으로 추론합니다.

기록

감사 로그에서 상태가 'solved'로 변경된 'Change' 이벤트를 바탕으로 추론합니다.

이벤트 유형 inferred
SLA 목표 적용
서비스 수준 협약(SLA) 정책이 서비스 요청 티켓에 적용된 시점을 나타냅니다. 티켓 속성이 활성 SLA 정책의 조건과 일치하면 이 이벤트가 명시적으로 기록됩니다.
중요한 이유

SLA 적용 시점을 추적하면 규정 준수 여부를 모니터링하고 위반 가능성을 분석하며 요청 유형별 예상 서비스 일정을 파악할 수 있습니다.

확보 방법

Zendesk 티켓 이벤트 또는 감사 로그의 'SLAPolicyApplied' 이벤트에서 가져옵니다. 이 이벤트에는 적용된 정책이 기록됩니다.

기록

티켓 데이터에 명시적으로 기록된 'SLAPolicyApplied' 이벤트로 확인합니다.

이벤트 유형 explicit
내부 메모 추가
상담원이 서비스 요청에 내부 메모나 댓글을 추가한 상태입니다. 다른 상담원만 볼 수 있으며, 'public' 속성이 false인 'Comment' 이벤트로 기록됩니다.
중요한 이유

내부 메모를 추적하면 상담원이나 팀 간 협업 현황을 파악할 수 있습니다. 협업 과정은 지연의 원인이 될 수도 있고, 문제를 효율적으로 해결하는 열쇠가 될 수도 있습니다.

확보 방법

티켓 데이터에 명시적으로 기록된 'Comment' 이벤트입니다. 이벤트 세부 정보에 'public: false' 속성이 포함되어 내부 메모임을 나타냅니다.

기록

'public' 플래그가 false로 설정된 티켓 'Comment' 이벤트에서 가져옵니다.

이벤트 유형 explicit
상담원 재배정
서비스 요청의 담당자가 한 상담원에서 다른 상담원으로 변경된 것을 나타냅니다. 최초 배정 이후 'assignee_id' 필드에 발생한 후속 'Change' 이벤트를 바탕으로 추론합니다.
중요한 이유

재배정 현황을 추적하면 상담원 재배정률 KPI를 계산할 수 있습니다. 이를 통해 프로세스 비효율, 잘못된 라우팅 또는 지식 격차를 파악할 수 있습니다.

확보 방법

티켓 감사 로그에서 'assignee_id' 필드의 'Change' 이벤트를 바탕으로 추론합니다. 티켓의 최초 배정 이벤트는 제외합니다.

기록

'assignee_id' 필드에서 두 번째 이후에 발생한 'Change' 이벤트를 바탕으로 추론합니다.

이벤트 유형 inferred
요청 보류
서비스 요청 상태가 'on-hold'로 변경될 때 발생합니다. 일반적으로 상담원이 요청자나 제3자의 정보를 기다리는 상황을 나타냅니다. 상태 변경 이벤트를 바탕으로 추론합니다.
중요한 이유

이를 통해 지원팀이 직접 통제하기 어려운 대기 시간을 분리해 측정할 수 있어 상담원 처리 시간을 더 정확하게 파악할 수 있습니다.

확보 방법

티켓 감사 로그에서 'status' 필드의 새 값이 'on-hold'인 'Change' 이벤트를 바탕으로 추론합니다.

기록

감사 로그에서 상태가 'on-hold'로 변경된 'Change' 이벤트를 바탕으로 추론합니다.

이벤트 유형 inferred
요청 에스컬레이션
서비스 요청을 상위 지원 단계, 다른 팀 또는 관리 부서로 공식 이관한 것을 나타냅니다. 일반적으로 티켓의 담당 그룹이 변경되거나 에스컬레이션 추적용 사용자 지정 필드가 변경된 경우를 바탕으로 추론합니다.
중요한 이유

에스컬레이션을 모니터링하면 복잡한 요청, 일선 상담원의 교육 필요성, 상위 단계의 개입이 필요한 시스템 문제를 파악할 수 있습니다.

확보 방법

표준 이벤트는 아닙니다. 'group_id' 필드가 에스컬레이션 그룹으로 변경되거나 에스컬레이션 추적에 사용하는 티켓 사용자 지정 필드가 변경된 경우를 바탕으로 추론해야 합니다.

기록

'group_id' 변경 또는 사용자 지정 'escalation' 필드 변경을 바탕으로 추론합니다.

이벤트 유형 inferred
우선순위 변경
서비스 요청의 우선순위가 '낮음', '보통', '높음' 또는 '긴급'으로 변경되었음을 나타냅니다. 티켓 감사 로그에서 'priority' 필드의 'Change' 이벤트로 기록됩니다.
중요한 이유

우선순위 변경을 분석하면 시간이 지나면서 긴급도가 높아지는 요청을 파악하고, 우선순위가 효과적으로 관리되는지 평가할 수 있습니다.

확보 방법

Zendesk 티켓 감사 로그에서 'priority' 필드의 'Change' 이벤트로 기록되며, 변경 전 값과 변경 후 값을 보여 줍니다.

기록

감사 로그에서 'priority' 필드의 'Change' 이벤트를 바탕으로 추론합니다.

이벤트 유형 inferred
권장 선택 사항

데이터 추출 안내

Zendesk Support에서 데이터 가져오기

시작할 준비가 되셨나요?

지금 서비스 요청 프로세스 최적화를 시작하세요. 이 데이터 템플릿으로 병목을 찾아 Zendesk Support의 효율성을 높일 수 있습니다.

서비스 요청 관리 최적화, 지금 지연을 줄이세요.

느린 처리와 사용자 불편을 끝내세요. 자동화율 70%를 달성하세요.

무료 체험 시작

신용카드 없이 빠르게 설정할 수 있습니다.