고객 서비스 데이터 템플릿

Zendesk Support
고객 서비스 데이터 템플릿

고객 서비스 데이터 템플릿

이 템플릿은 고객 서비스 프로세스 분석에 필요한 데이터를 수집하는 데 도움이 됩니다. 수집해야 할 주요 데이터 속성과 추적할 활동을 안내하고, 데이터를 추출하는 방법도 설명합니다. 이 가이드를 활용해 이벤트 로그를 구성하면 서비스 운영 현황을 파악하고 개선할 수 있습니다.
  • 수집 권장 속성
  • 고객 서비스 프로세스에서 추적할 주요 활동
  • Zendesk Support 데이터 추출 안내
이벤트 로그가 처음이신가요? 알아보기 process mining 이벤트 로그 만드는 방법.

고객 서비스 속성

고객 서비스를 자세히 분석할 수 있도록 이벤트 로그에 포함할 것을 권장하는 데이터 필드입니다.
5 필수 6 권장 7 선택 사항
이름 설명
서비스 요청
ServiceRequest
티켓 또는 케이스라고도 하는 각 고객 서비스 요청의 고유 식별자입니다.
설명

Service Request는 단일 고객 문의나 문제와 관련된 모든 활동을 생성부터 최종 해결까지 연결하는 기본 케이스 식별자입니다. 모든 상호작용, 업데이트, 내부 작업은 이 고유 ID와 연결됩니다.

process mining에서 Service Request별로 이벤트를 분석하면 고객 서비스 여정을 처음부터 끝까지 파악할 수 있습니다. 전체 해결 시간과 같은 주요 지표를 계산하고, 프로세스 이탈을 찾으며, 각 고객 문제의 처리 과정을 이해하는 기반이 됩니다.

중요한 이유

각 고객 서비스 여정의 프로세스 단계를 연결하고 재구성 및 분석할 수 있게 하는 필수 Case ID입니다.

확보 방법

Zendesk Tickets API의 id 필드입니다.

예시
102451287415332
시작 시간
StartTime
활동이나 이벤트가 시작된 시점을 나타내는 타임스탬프입니다.
설명

시작 시간 또는 이벤트 타임스탬프는 특정 활동이 발생한 정확한 날짜와 시간을 기록합니다. 예를 들어 고객 댓글이 추가된 시점, 상담원이 배정된 시점, 티켓 상태가 '해결'로 변경된 시점을 기록합니다.

이 타임스탬프는 이벤트의 시간 순서를 정하므로 process mining의 기본 요소입니다. 활동 간 소요 시간을 계산하고, 처리 주기를 측정하며, SLA 대비 성과를 분석하고, 서비스 프로세스의 시간적 흐름을 파악하는 데 사용됩니다.

중요한 이유

이 타임스탬프는 이벤트 순서를 정하고 소요 시간을 계산하며 서비스 요청 처리 일정을 분석하는 데 필요합니다.

확보 방법

Zendesk Ticket Audits API에서 감사 기록의 각 이벤트에 해당하는 created_at 필드입니다.

예시
2023-04-15T10:00:00Z2023-04-15T10:05:14Z2023-04-16T14:30:00Z
원천 시스템
SourceSystem
데이터를 추출한 기준 시스템입니다.
설명

이 속성은 서비스 요청 데이터의 원천 시스템을 지정합니다. 여기서는 Zendesk Support입니다. 여러 시스템의 데이터를 결합할 때 특히 데이터 거버넌스와 계보를 관리하는 데 도움이 됩니다.

분석 시 데이터가 올바른 원천에 연결되도록 하므로 데이터 무결성을 유지하고 프로세스의 맥락을 이해하는 데 중요합니다. 특히 여러 시스템을 사용하는 환경에서 유용합니다.

중요한 이유

데이터 원천을 식별합니다. 데이터 거버넌스를 관리하고 통합 환경에서 프로세스 데이터를 구분하는 데 중요합니다.

확보 방법

데이터 추출 과정에서 데이터의 원천을 표시하기 위해 추가하는 고정값입니다.

예시
Zendesk Support
최근 데이터 업데이트
LastDataUpdate
원천 시스템에서 데이터를 가장 최근에 새로 고치거나 추출한 시점의 타임스탬프입니다.
설명

이 속성은 Zendesk Support에서 데이터 세트를 마지막으로 업데이트한 시점을 나타냅니다. 분석 중인 데이터가 얼마나 최신인지 파악하는 데 도움이 됩니다.

마지막 업데이트 시간을 알면 분석가와 비즈니스 사용자가 가장 최신 프로세스 정보를 보고 있는지 확인할 수 있습니다. 데이터의 최신성에 대한 기대치를 관리하고 보고 및 모니터링을 수행하는 데도 중요합니다.

중요한 이유

데이터가 얼마나 최신인지 명확히 보여주므로 사용자가 프로세스 분석의 최신성을 파악할 수 있습니다.

확보 방법

데이터 추출 과정에서 생성 및 저장되며 추출 작업의 타임스탬프를 기록하는 메타데이터 필드입니다.

예시
2023-10-27T02:00:00Z
활동명
ActivityName
서비스 요청 처리 과정에서 발생한 특정 이벤트나 작업의 이름입니다.
설명

활동명은 고객 서비스 프로세스의 개별 단계나 주요 시점을 나타냅니다. 예를 들어 '서비스 요청 생성', '상담원에게 요청 배정', '서비스 요청 해결' 등이 있습니다. 각 이벤트에는 타임스탬프가 기록되며, 서비스 요청별 작업 순서를 구성합니다.

이 속성은 프로세스 흐름을 시각화하고 프로세스 변형을 찾으며 이벤트의 빈도와 순서를 분석하는 데 중요합니다. 분석가는 이를 통해 어떤 작업이 수행되는지 파악하고, 자주 나타나는 경로와 병목, 표준 절차에서 벗어난 부분을 확인할 수 있습니다.

중요한 이유

이 속성은 프로세스 단계를 정의해 프로세스 맵을 시각화하고 프로세스 흐름과 변형을 분석할 수 있게 합니다.

확보 방법

변경 사항과 작업을 기록하는 Zendesk 티켓 감사 로그 또는 이벤트 스트림에서 가져옵니다.

예시
서비스 요청 생성상담원에게 요청 배정상담원의 첫 공개 답변 발송서비스 요청 해결
SLA 목표 해결 시간
SlaTargetResolutionTime
SLA 정책에 따라 서비스 요청을 해결해야 하는 목표 시간입니다.
설명

이 속성은 티켓 해결에 적용되는 서비스 수준 계약(SLA)의 목표를 정의합니다. 목표 시간은 요청의 우선순위와 유형, 고객의 서비스 플랜 등에 따라 달라질 수 있습니다.

'SLA 규정 준수 성과' 대시보드를 구성하는 기본 속성입니다. 실제 해결 시간을 비교할 기준으로 사용합니다. 목표 대비 성과를 분석하면 서비스 제공 품질을 수치로 파악하고 고객과의 계약상 의무를 이행하고 있는지 확인할 수 있습니다.

중요한 이유

고객에게 약속한 서비스 기준을 정의하며, 정시 처리 성과와 SLA 규정 준수 여부를 측정하는 기준이 됩니다.

확보 방법

티켓에 적용된 SLA 정책을 바탕으로 산출합니다. Zendesk Ticket Metrics API에서 이 정보를 확인할 수 있습니다.

예시
144002880086400
SLA 위반 여부
IsSlaBreached
서비스 요청의 해결 시간이 SLA 목표를 초과했는지 나타내는 참·거짓 값입니다.
설명

이 계산 속성은 서비스 요청이 정해진 서비스 수준 계약의 해결 시간 목표를 지키지 못했는지 참 또는 거짓으로 표시합니다. 실제 해결 시간과 SLA 목표 시간을 비교해 산출합니다.

이 값을 사용하면 SLA 규정 준수 여부를 간편하게 분석할 수 있습니다. 'SLA 규정 준수 성과' 대시보드와 'SLA 규정 준수율' KPI의 기본 데이터로, 목표를 지킨 요청과 지키지 못한 요청을 빠르게 집계하고 시각화할 수 있습니다.

중요한 이유

각 사례의 SLA 성과를 명확한 참·거짓 값으로 표시하여 규정 준수 모니터링과 보고를 간소화합니다.

확보 방법

데이터 변환 과정에서 총 해결 시간과 SlaTargetResolutionTime을 비교해 계산합니다.

예시
truefalse
배정된 상담원
AssignedAgent
서비스 요청을 처리하도록 배정된 고객 서비스 상담원의 이름 또는 ID입니다.
설명

이 속성은 특정 시점에 활동이나 서비스 요청을 담당하는 상담원을 식별합니다. 요청 처리 중 재배정되면 담당자가 바뀔 수 있습니다.

배정된 상담원별 분석은 상담원별 업무량, 성과, 효율성을 파악하는 데 중요합니다. '상담원 업무량 및 효율성' 대시보드에서 상담원별 처리 시간과 케이스 수를 비교할 수 있습니다. 이를 통해 코칭이 필요한 부분을 찾고 업무량을 균형 있게 배분할 수 있습니다.

중요한 이유

작업을 수행한 상담원을 추적해 개인별 성과, 업무량 분배, 리소스 배분을 분석할 수 있습니다.

확보 방법

Zendesk Tickets API의 assignee_id 필드입니다. 사용자 정보는 Users API에서 가져올 수 있습니다.

예시
김민수이서연SupportBot
서비스 요청 유형
ServiceRequestType
'질문', '장애', '문제', '작업' 등 서비스 요청의 분류입니다.
설명

이 속성은 요청의 성격에 따라 서비스 요청을 분류합니다. 일반적으로 요청 생성 또는 초기 분류 시 설정하며, 적절한 워크플로와 우선순위를 정하는 데 도움이 됩니다.

분석에서는 서비스 요청 유형별로 데이터를 나누는 것이 중요합니다. '서비스 요청 해결 시간 분석' 및 '내부 에스컬레이션 비율 및 원인' 대시보드처럼 유형별 해결 시간, 에스컬레이션 비율, 프로세스 흐름을 비교할 수 있습니다. 이를 통해 특정 유형의 요청이 처리하기 더 어렵거나 비효율적인지 확인할 수 있습니다.

중요한 이유

요청을 유형별로 분류해 성과를 비교하고 분석할 수 있습니다. 특정 프로세스를 개선할 때 중요한 기준입니다.

확보 방법

Zendesk Tickets API의 type 필드입니다.

예시
질문장애문제작업
우선순위
Priority
'낮음', '보통', '높음', '긴급' 등 서비스 요청에 지정된 우선순위입니다.
설명

우선순위는 서비스 요청의 긴급도를 나타내며, 대기열에서의 순서와 목표 해결 시간에 영향을 주는 경우가 많습니다. 상담원이 가장 중요한 문제부터 처리할 수 있도록 돕습니다.

이 속성은 성과와 SLA 분석에 필요합니다. '서비스 요청 해결 시간 분석' 대시보드에서 우선순위별로 데이터를 나누면 우선순위가 높은 요청이 낮은 요청보다 더 빠르게 처리되는지, 비즈니스 요구에 맞게 리소스가 배분되는지 확인할 수 있습니다.

중요한 이유

요청의 긴급도를 나타내며, SLA 규정 준수 분석과 긴급한 문제의 신속한 처리를 위해 중요합니다.

확보 방법

Zendesk Tickets API의 priority 필드입니다.

예시
낮음보통높음긴급
커뮤니케이션 채널
CommunicationChannel
서비스 요청을 접수하거나 커뮤니케이션을 진행한 채널입니다.
설명

이 속성은 이메일, 웹 양식, 채팅, 전화 등 고객과 소통한 방식을 나타냅니다. 고객이 서비스 데스크와 어떤 방식으로 소통하는지 확인할 수 있습니다.

채널 사용 현황을 파악하면 리소스를 계획하고 고객 경험을 개선하는 데 도움이 됩니다. '커뮤니케이션 채널 사용 현황' 대시보드에서 채널별 이용 빈도를 확인하고, 특정 채널이 처리 시간 연장이나 다른 프로세스 경로와 관련이 있는지 분석할 수 있습니다. 이를 바탕으로 서비스 개선이나 자동화에 투자할 영역을 정할 수 있습니다.

중요한 이유

고객과 상담원의 소통 방식을 보여 주므로, 채널별 효율성과 프로세스 및 고객 경험에 미치는 영향을 분석할 수 있습니다.

확보 방법

Zendesk Tickets API의 via.channel 필드입니다.

예시
웹이메일API채팅
만족도 평가
SatisfactionRating
서비스 요청이 해결된 후 고객이 제공한 만족도 점수입니다.
설명

이 속성은 서비스 경험에 대한 고객 의견을 기록하며, 일반적으로 티켓 해결 후 설문을 통해 수집합니다. 평가값은 '좋음', '나쁨' 또는 숫자 점수로 표시할 수 있습니다.

고객 반응을 직접 측정하는 지표이자 주요 결과 지표입니다. '고객 만족도 점수' KPI를 계산하는 데 사용합니다. 만족도 평가를 해결 시간이나 상담원 응대 횟수 같은 프로세스 데이터와 함께 분석하면 어떤 업무 방식이 더 나은 고객 경험으로 이어지는지 파악할 수 있습니다.

중요한 이유

제공된 서비스에 대한 고객 의견을 직접 측정하여 프로세스 성과와 고객 결과를 연결합니다.

확보 방법

Zendesk Tickets API의 satisfaction_rating.score 필드입니다.

예시
좋음나쁨제공됨
상담원 그룹
AgentGroup
서비스 요청이 배정된 지원 그룹 또는 팀입니다.
설명

이 속성은 서비스 요청을 담당하는 상담원 팀을 나타냅니다. 요청은 기술, 제품 영역, 언어 등을 기준으로 특정 그룹에 배정되는 경우가 많습니다.

상담원 그룹별로 분석하면 팀 단위 성과와 업무량 분포, 팀 간 에스컬레이션 양상을 파악할 수 있습니다. 개별 상담원 분석보다 상위 수준의 현황을 보여 주며, 특정 부서나 기능에서 반복되는 문제를 찾는 데 도움이 됩니다.

중요한 이유

팀별 담당 현황을 추적하여 그룹 성과, 팀 간 인계, 지원 단계 또는 전문 분야별 리소스 배분을 분석할 수 있습니다.

확보 방법

Zendesk Tickets API의 group_id 필드입니다. 그룹 세부 정보는 Groups API에서 가져올 수 있습니다.

예시
1차 지원기술 지원청구
재오픈 여부
IsReopened
서비스 요청이 해결 처리된 후 다시 열렸는지 나타내는 참·거짓 값입니다.
설명

이 속성은 서비스 요청이 해결 또는 종료 상태로 처리된 후 다시 열림 상태로 바뀌면 참으로 표시합니다. 최초 해결이 충분하지 않았음을 나타냅니다.

재작업과 최초 문의 해결 실패를 추적하는 데 중요합니다. '서비스 요청 재오픈 추이' 대시보드와 '서비스 요청 재오픈율' KPI에서 추가 조치가 필요한 사례를 쉽게 집계하고 분석할 수 있습니다. 재오픈은 더 근본적인 문제가 있음을 나타내는 경우가 많습니다.

중요한 이유

재작업과 해결 실패를 파악하여 제공된 해결책의 품질과 효과를 측정할 수 있습니다.

확보 방법

데이터 변환 과정에서 티켓 상태가 'resolved' 또는 'closed'에서 'open'으로 바뀌었는지 확인해 계산합니다.

예시
truefalse
정보 요청 횟수
InformationRequestCount
단일 서비스 요청에서 고객에게 정보를 요청한 총 횟수입니다.
설명

이 계산 지표는 각 서비스 요청에서 '고객에게 정보 요청' 활동이 발생한 횟수를 집계합니다. 횟수가 많으면 상담원이 필요한 정보를 처음부터 충분히 수집하지 못했을 가능성이 있습니다.

'반복 정보 요청 분석' 대시보드에서 이 속성을 사용합니다. 요청 횟수를 추적하면 프로세스 비효율과 상담원 교육이 필요한 영역을 찾을 수 있습니다. 정보 요청 횟수를 줄이면 해결 시간을 단축하고 고객 경험을 개선할 수 있습니다.

중요한 이유

고객과 주고받은 커뮤니케이션 횟수를 수치화하여 해결을 지연시키고 고객 경험을 저해하는 비효율을 파악합니다.

확보 방법

각 서비스 요청에서 ActivityName이 'Information Requested From Customer'인 이벤트 수를 집계해 계산합니다.

예시
013
제품·서비스 범주
ProductServiceCategory
고객의 요청과 관련된 제품, 서비스 또는 기능입니다.
설명

이 속성은 서비스 요청을 제품이나 서비스 영역별로 분류해 구체적인 맥락을 제공합니다. 상담원이 직접 설정하거나 요청 내용에 따라 자동으로 지정할 수 있습니다.

이 분류는 '요청 분류 정확도'와 '조사 주기 시간 분석' 대시보드에서 중요하게 활용됩니다. 어떤 제품에서 지원 요청이 많이 발생하는지, 해결하기 어려운 요청은 무엇인지, 최초 분류가 최종 해결 내용과 일치하는지 자세히 분석할 수 있습니다. 분석 결과를 활용해 요청 배정과 상담원 교육을 개선할 수 있습니다.

중요한 이유

요청을 특정 업무 영역, 제품 또는 서비스와 연결하여 문제 영역과 프로세스에 미치는 영향을 집중적으로 분석할 수 있습니다.

확보 방법

일반적으로 Zendesk에서 사용자 지정 티켓 필드로 설정합니다. 정확한 필드명은 Zendesk 구성에 따라 다릅니다.

예시
모바일 앱구독 관리API 연동하드웨어
종료 시간
EndTime
활동이나 이벤트가 완료된 시점을 나타내는 타임스탬프입니다.
설명

종료 시간은 활동이 완료된 시점을 나타냅니다. 여러 이벤트 로그 구조에서는 다음 활동의 시작 시간이 현재 활동의 종료 시간으로 사용될 수 있습니다. '상담원이 문제 조사'와 같은 상태 기반 활동에서는 해당 상태가 끝난 시점을 나타냅니다.

이 속성은 활동별 소요 시간을 정확히 계산하는 데 필요하며, 이는 성과 분석의 기본 요소입니다. 시간이 가장 오래 걸리는 단계를 찾고 병목을 자세히 분석하며 리소스 효율성을 계산하는 기준이 됩니다.

중요한 이유

활동별 소요 시간을 계산할 수 있어 병목을 찾고 성과를 측정하는 데 중요합니다.

확보 방법

일반적으로 해당 Service Request의 이벤트 순서에서 다음 이벤트의 StartTime을 사용해 계산합니다.

예시
2023-04-15T10:05:14Z2023-04-15T11:20:30Z2023-04-16T15:00:00Z
해결 코드
ResolutionCode
요청을 최종 해결하거나 종료한 사유를 나타내는 코드 또는 범주입니다.
설명

해결 코드는 서비스 요청의 처리 결과를 구조화된 정보로 제공합니다. 예를 들면 '상담원이 해결', '중복 요청', '조치 불필요', '알려진 문제' 등이 있습니다. 단순히 '종료' 상태만 표시할 때보다 더 많은 맥락을 확인할 수 있습니다.

이 속성은 근본 원인 분석에 특히 유용합니다. '서비스 요청 재오픈 추이' 대시보드에서 해결 코드별 재오픈 비율을 분석하면 효과가 낮은 해결 방식을 파악할 수 있습니다. 이를 통해 고객이 지원팀에 다시 문의하게 되는 원인을 찾을 수 있습니다.

중요한 이유

서비스 요청의 처리 결과를 파악할 수 있어 근본 원인을 분석하고 요청이 다시 열리는 이유를 이해하는 데 도움이 됩니다.

확보 방법

일반적으로 Zendesk에서 사용자 지정 티켓 필드로 설정합니다. 정확한 필드명은 Zendesk 구성에 따라 다릅니다.

예시
최초 문의 시 해결2차 지원팀으로 에스컬레이션고객 답변 대기제품 버그
필수 권장 선택 사항

고객 서비스 활동

고객 서비스 프로세스를 정확히 파악하기 위해 이벤트 로그에 기록할 주요 단계와 마일스톤입니다.
6 권장 8 선택 사항
활동 설명
고객에게 정보 요청
상담원이 처리를 계속하기 위해 고객에게 추가 정보가 필요해 티켓 상태를 'pending'으로 변경할 때 발생합니다. 이 상태 변경은 외부 응답을 기다리는 중임을 명확히 나타냅니다.
중요한 이유

이 활동은 고객 응답에 따라 처리가 달라지는 구간을 보여주며 내부 SLA 시계를 일시 중지합니다. 한 티켓에서 이 단계가 자주 반복되면 초기 정보 수집이 충분하지 않았다는 뜻일 수 있으며, 해결 시간이 길어질 수 있습니다.

확보 방법

Zendesk Ticket Audits API에 기록되는 명시적인 상태 변경 이벤트입니다. 'status' 필드가 'pending'으로 변경될 때 기록됩니다.

기록

Ticket Audits에서 티켓 상태가 'pending'으로 설정된 'Change' 이벤트를 찾습니다.

이벤트 유형 explicit
상담원에게 요청 배정
서비스 요청을 처리할 특정 상담원에게 배정하는 이벤트입니다. 라우팅 규칙에 따라 자동으로 배정되거나 팀 리더 또는 상담원이 직접 배정할 수 있습니다.
중요한 이유

배정은 책임 소재와 업무량 관리에 중요한 단계입니다. 배정까지 걸리는 시간과 재배정 패턴을 분석하면 초기 분류와 배분 과정의 병목을 찾을 수 있습니다.

확보 방법

Zendesk Ticket Audits API에 명시적으로 기록되는 'Change' 이벤트입니다. 'assignee_id' 필드가 입력되거나 변경될 때마다 기록됩니다.

기록

Ticket Audits 로그에서 'assignee_id' 필드의 변경 사항을 추적합니다.

이벤트 유형 explicit
서비스 요청 생성
이 활동은 고객 서비스 프로세스의 시작을 나타냅니다. 이메일, 웹 양식, 채팅 등 어떤 채널로든 Zendesk에 새 티켓이 생성되는 시점입니다. 티켓이 생성되면 시스템이 고유한 티켓 ID와 타임스탬프를 이벤트로 기록합니다.
중요한 이유

주요 시작 이벤트인 이 활동은 전체 케이스 처리 시간을 계산하고 시간에 따른 요청 유입량을 분석하는 데 필요합니다. 첫 응답까지 걸린 시간과 전체 해결 시간 같은 주요 성과 지표를 측정하는 기준이 됩니다.

확보 방법

Zendesk Ticket Audits API에 명시적으로 기록되는 이벤트입니다. 티켓의 'Create' 이벤트에 해당하며 최초 생성 타임스탬프를 제공합니다.

기록

Ticket Audits 로그의 티켓 생성 이벤트에서 가져옵니다.

이벤트 유형 explicit
서비스 요청 재오픈
티켓 상태가 'solved'일 때 고객이 답변하면 발생하는 활동입니다. Zendesk가 상태를 'open'으로 자동 변경하며, 이는 문제가 완전히 해결되지 않았음을 나타냅니다.
중요한 이유

재오픈은 최초 문의 해결에 실패했거나 해결 품질이 낮았음을 보여주는 중요한 지표입니다. 재오픈 빈도와 원인을 분석하면 상담원 교육과 해결 절차를 개선할 부분을 찾을 수 있습니다.

확보 방법

Ticket Audits API에 명시적으로 기록되는 상태 변경입니다. 'status'가 'solved'에서 'open'으로 바뀔 때 기록됩니다.

기록

상태가 'solved'에서 'open'으로 바뀌는 'Change' 이벤트를 추적합니다.

이벤트 유형 explicit
서비스 요청 종료
서비스 요청이 최종적으로 종료되는 마지막 활동입니다. 일반적으로 티켓을 'solved'로 표시한 뒤 일정 기간 동안 고객의 새 답변이 없으면 자동으로 종료됩니다.
중요한 이유

최종 종료 이벤트로 티켓의 전체 처리 과정을 마무리합니다. 'solved'에서 'closed'까지의 기간은 재오픈이 가능한 시간이며, 'closed' 이벤트는 해결이 최종 확정되었음을 나타냅니다.

확보 방법

Zendesk Ticket Audits API에서 'status' 필드가 'closed'로 설정될 때 명시적으로 기록되는 상태 변경입니다.

기록

Ticket Audits에서 티켓 상태가 'closed'로 설정된 'Change' 이벤트를 찾습니다.

이벤트 유형 explicit
서비스 요청 해결
고객에게 해결책을 제공한 뒤 상담원이 서비스 요청을 'solved'로 표시합니다. 고객이 답변하면 티켓이 다시 열릴 수 있으므로 이 상태는 임시 상태입니다.
중요한 이유

해결 시간과 상담원 효율성을 측정하는 주요 단계입니다. 상담원이 업무가 완료되었다고 판단한 시점을 나타내며, 티켓이 재오픈될 경우 재작업을 분석하는 기준이 됩니다.

확보 방법

Zendesk Ticket Audits API에서 'status' 필드가 'solved'로 설정될 때 명시적으로 기록되는 상태 변경입니다.

기록

Ticket Audits에서 티켓 상태가 'solved'로 설정된 'Change' 이벤트를 찾습니다.

이벤트 유형 explicit
SLA 위반 발생
첫 응답 시간이나 해결 시간 등 사전에 정한 서비스 수준 협약을 서비스 요청이 충족하지 못한 시점을 나타냅니다. 티켓 활동 타임스탬프를 SLA 정책과 비교해 계산합니다.
중요한 이유

SLA 위반은 고객 만족도와 계약상 규정 준수에 직접 영향을 줍니다. 발생 시점과 원인을 분석하면 반복되는 지연, 리소스 부족, 비현실적인 성과 목표를 파악할 수 있습니다.

확보 방법

SLA 위반 타임스탬프('breached_at')를 저장하는 Zendesk Ticket Metrics API에서 가져올 수 있습니다. 또는 티켓 이벤트 타임스탬프를 정해진 SLA 규칙과 비교해 계산할 수 있습니다.

기록

Ticket Metrics API의 'breached_at' 타임스탬프를 사용하거나 해결 시간을 SLA 정책의 기준 시간과 비교해 계산합니다.

이벤트 유형 calculated
고객 응답
일반적으로 티켓이 'pending' 상태일 때 고객이 답변하면 발생하는 이벤트입니다. Zendesk는 티켓 상태를 'pending'에서 'open'으로 자동 변경해 상담원이 처리를 재개할 수 있음을 알립니다.
중요한 이유

이 활동은 대기 시간이 끝나고 프로세스가 다시 진행되는 시점을 나타냅니다. 고객이 응답하는 데 걸리는 시간을 분석하면 상담원의 요청이 명확했는지 파악할 수 있습니다.

확보 방법

최종 사용자가 새 공개 댓글을 작성하면 발생하는 이벤트입니다. 이때 Ticket Audits API에 'pending'에서 'open'으로의 상태 변경이 명시적으로 기록됩니다.

기록

상태가 'pending'에서 'open'으로 바뀌는 'Change' 이벤트를 추적하거나 최종 사용자가 작성한 새 공개 댓글을 찾습니다.

이벤트 유형 explicit
내부 에스컬레이션 발생
서비스 요청을 다른 내부 팀이나 상위 지원 단계로 전달하는 것을 나타냅니다. 일반적으로 티켓의 배정 그룹이 변경된 경우로 추정합니다.
중요한 이유

에스컬레이션을 추적하면 프로세스의 취약점, 일선 지원의 지식 격차, 복잡한 요청 유형을 파악할 수 있습니다. 에스컬레이션 비율이 높으면 교육이나 프로세스 문서화를 강화해야 할 수 있습니다.

확보 방법

Ticket Audits API에서 'group_id' 필드가 변경된 'Change' 이벤트를 바탕으로 추정합니다. 그룹이 바뀌면 팀 간에 업무가 전달된 것입니다.

기록

Ticket Audits 로그에서 'group_id' 필드의 변경 사항을 모니터링합니다.

이벤트 유형 inferred
만족도 설문 발송
고객 만족도(CSAT) 설문을 고객에게 자동 발송하는 시점을 나타냅니다. 일반적으로 티켓을 'solved'로 표시한 뒤 잠시 후 발송됩니다.
중요한 이유

이 활동으로 고객 피드백 수집이 시작됩니다. 설문이 언제 발송되는지, 실제로 발송되는지 파악하면 만족도 점수를 맥락에 맞게 해석하고 피드백 프로그램의 효과를 측정할 수 있습니다.

확보 방법

자동화 로그나 티켓에 추가된 특정 태그를 바탕으로 추정할 수 있습니다. Ticket Audits API의 'satisfaction_rating' 섹션에도 설문을 제안한 시점이 기록됩니다.

기록

'csat_sent'와 같은 태그를 찾거나 만족도 평가를 제안한 시점의 타임스탬프를 사용합니다.

이벤트 유형 inferred
만족도 평가 접수
고객이 만족도 설문에 응답해 'Good' 또는 'Bad'와 같은 평가를 제출하면 발생하는 이벤트입니다. 평가와 관련 의견은 티켓에 기록됩니다.
중요한 이유

고객의 직접적인 피드백은 서비스 품질과 고객 반응을 측정하는 데 매우 유용합니다. 프로세스 흐름과 함께 평가를 분석하면 특정 활동이나 상담원이 결과에 미치는 영향을 확인할 수 있습니다.

확보 방법

고객의 점수와 의견이 'satisfaction_rating' 필드에 입력될 때 Ticket Audits API에 'Change' 이벤트로 기록됩니다.

기록

Ticket Audit 로그에서 'satisfaction_rating' 필드의 변경 사항을 필터링합니다.

이벤트 유형 explicit
상담원의 첫 공개 답변 발송
자동 접수 확인과 달리 상담원이 고객에게 처음으로 공개 댓글을 보내는 활동입니다. 상담원이 고객 문제를 처음으로 직접 처리하기 시작한 시점을 나타내는 중요한 이벤트입니다.
중요한 이유

서비스 응답성을 나타내는 중요한 지표인 'First Reply Time' SLA를 측정하는 주요 단계입니다. 자동 안내와 상담원이 직접 조사 및 지원을 시작하는 시점을 구분합니다.

확보 방법

Ticket Comments 스트림에서 작성자가 자동화 시스템 사용자가 아닌 실제 상담원인 첫 공개 댓글을 찾아 확인합니다.

기록

티켓 댓글을 살펴보고 상담원이 작성한 공개 댓글만 필터링한 뒤 타임스탬프가 가장 이른 댓글을 선택합니다.

이벤트 유형 inferred
요청 분류 및 우선순위 지정
상담원이나 자동화가 유형, 범주, 우선순위 등의 티켓 필드를 설정하거나 업데이트할 때 발생하는 활동입니다. 티켓 이력에 변경 이벤트로 기록됩니다.
중요한 이유

요청을 적절히 분류하고 우선순위를 지정해야 효율적으로 전달하고 리소스를 배분할 수 있습니다. 이 활동을 분석하면 초기 분류의 정확도와 해결 시간에 미치는 영향을 파악할 수 있습니다.

확보 방법

Zendesk Ticket Audits API의 'Change' 이벤트에서 가져옵니다. 'priority', 'type' 또는 분류와 관련된 사용자 지정 필드의 첫 업데이트를 찾아 확인할 수 있습니다.

기록

생성 후 주요 분류 필드에 발생한 첫 'Change' 이벤트를 Ticket Audit 로그에서 필터링합니다.

이벤트 유형 explicit
초기 접수 확인 발송
고객의 요청을 접수했다는 사실을 알리는 자동 첫 응답입니다. 일반적으로 Zendesk 트리거가 티켓 생성 직후 템플릿 이메일 알림을 발송합니다.
중요한 이유

이 활동을 추적하면 초기 응답 속도를 측정하고 고객의 기대치를 관리할 수 있습니다. 요청 생성부터 접수 확인까지 걸린 시간은 고객 만족도를 나타내는 주요 지표입니다.

확보 방법

티켓의 첫 공개 댓글 작성자가 자동화 사용자이거나 티켓 생성 후 몇 초 안에 댓글이 등록된 경우 이를 바탕으로 추정합니다. Ticket Comments 스트림을 분석해 확인할 수 있습니다.

기록

티켓 생성 직후 자동화 또는 트리거가 작성한 첫 공개 댓글을 찾습니다.

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

데이터 추출 가이드

Zendesk Support에서 데이터 가져오기

시작할 준비가 되셨나요?

이 템플릿으로 데이터를 준비해 오늘부터 고객 서비스 프로세스 개선을 시작하세요. Zendesk Support 운영 데이터를 분석해 유용한 인사이트를 얻고 업무 효율을 높일 수 있습니다.

고객 서비스 병목을 해소하고 CSAT를 높이세요

반복 문의를 줄이세요. FCR 80%를 달성하고 고객 만족도를 높이세요.

무료 체험 시작

신용카드가 필요하지 않습니다