고객 서비스 데이터 템플릿

Freshdesk
고객 서비스 데이터 템플릿

고객 서비스 데이터 템플릿

이 템플릿은 효과적인 고객 서비스 분석에 필요한 주요 데이터 속성과 프로세스 활동을 안내합니다. 데이터를 효율적으로 수집할 수 있도록 실용적인 추출 방법도 제공합니다. 이 자료를 활용해 데이터 수집 절차를 간소화하고 process mining을 준비하세요.
  • 수집 권장 속성
  • 추적할 주요 활동
  • 데이터 추출 안내
이벤트 로그가 처음이신가요? 알아보기 process mining 이벤트 로그 만드는 방법.

고객 서비스 속성

고객 서비스를 폭넓게 분석하고 유용한 인사이트를 얻으려면 이벤트 로그에 다음 데이터 필드를 포함하는 것이 좋습니다.
3 필수 4 권장 12 선택 사항
이름 설명
서비스 요청
ServiceRequest
고객 문의나 문제 하나를 식별하는 고유 ID입니다. 일반적으로 티켓 또는 케이스라고 합니다.
설명

서비스 요청은 하나의 고객 상호작용과 관련된 모든 활동을 연결하는 기본 케이스 식별자입니다. 고객이 새로 문의하거나 문제 또는 요청을 접수하면 고유한 서비스 요청 ID가 생성됩니다. 이 ID는 티켓 생성부터 배정, 해결, 종료까지 전체 과정에서 동일하게 유지됩니다.

process mining에서는 각 고객 케이스의 전체 여정을 재구성하는 데 이 속성이 기본이 됩니다. 관련 이벤트를 하나의 서비스 요청 ID로 묶으면 분석 담당자가 프로세스 흐름을 시각화하고 처리 시간을 측정하며 개별 케이스에 영향을 주는 편차나 병목을 찾을 수 있습니다.

중요한 이유

관련 이벤트를 하나의 프로세스 인스턴스로 연결하는 필수 Case ID입니다. 이를 통해 각 고객 서비스 여정을 전체적으로 파악할 수 있습니다.

확보 방법

Freshdesk의 기본 티켓 ID입니다. 일반적으로 'Tickets' API 엔드포인트의 'id' 필드에서 확인할 수 있습니다.

예시
SR-2023-10-4831SR-2023-11-0192SR-2023-11-5210
이벤트 시각
EventTime
특정 활동이나 이벤트가 발생한 시점을 나타내는 타임스탬프입니다.
설명

이벤트 시각 또는 타임스탬프는 활동이 발생한 정확한 날짜와 시간을 기록합니다. 이벤트를 시간순으로 정렬하고 프로세스의 여러 단계 사이에 걸린 시간을 계산하는 데 필요합니다. 기록된 모든 활동에는 해당 타임스탬프가 있어야 합니다.

분석에서는 이 속성을 사용해 각 서비스 요청의 타임라인을 구성합니다. 해결 시간, 첫 응답 시간, 병목 구간의 지속 시간 등 시간 관련 KPI를 계산하는 기준입니다. 프로세스 성과를 파악하고 지연을 찾으려면 정확한 타임스탬프가 필요합니다.

중요한 이유

이 타임스탬프는 이벤트를 시간순으로 정렬하고 처리 시간, SLA 준수 여부 등 지속 시간 기반 지표를 계산하는 데 필요합니다.

확보 방법

Freshdesk API에서 티켓 이벤트, 답변 또는 상태 변경과 연결된 'created_at' 또는 'updated_at' 필드에 해당합니다.

예시
2023-10-25T10:00:00Z2023-10-25T10:05:14Z2023-10-26T14:30:00Z
활동
Activity
고객 서비스 프로세스에서 발생한 특정 업무 이벤트나 단계의 이름입니다.
설명

활동 속성은 서비스 요청의 생애 주기에서 발생하는 개별 작업이나 상태 변경을 나타냅니다. '티켓 생성', '티켓 배정', '첫 응답 전송', '티켓 해결'과 같은 주요 비즈니스 이벤트를 기록하며, 이러한 활동은 프로세스 맵의 노드가 됩니다.

활동의 순서와 빈도를 분석하는 것은 process mining의 핵심입니다. 이를 통해 프로세스 흐름을 시각화하고 일반적인 경로와 드문 경로를 파악하며 표준 운영 절차에서 벗어난 부분을 찾을 수 있습니다. 활동을 이해하면 비효율, '티켓 재개'와 같은 재작업 반복, 규정 준수 문제를 파악하는 데 도움이 됩니다.

중요한 이유

이 속성은 프로세스 맵의 단계를 정의하며, 시작부터 끝까지 프로세스 흐름을 시각화하고 분석할 수 있게 합니다.

확보 방법

Freshdesk의 이벤트 유형에서 도출합니다. 'Tickets' API 엔드포인트의 상태 변경과 'Conversations' 엔드포인트의 메모나 답변 같은 특정 이벤트를 조합할 수 있습니다.

예시
티켓 생성첫 응답 발송상태를 보류로 변경티켓 해결티켓 종료
담당 상담원
AssignedAgent
이벤트 발생 시점에 티켓을 담당하는 고객 서비스 상담원의 이름 또는 ID입니다.
설명

이 속성은 서비스 요청을 처리하도록 배정된 상담원을 식별합니다. 티켓의 생애주기 동안 재배정이나 에스컬레이션으로 담당 상담원이 바뀔 수 있습니다.

담당 상담원별 데이터 분석은 성과 관리 대시보드에 중요합니다. 평균 해결 시간, 티켓 수, 재개율 등 상담원별 KPI를 측정할 수 있습니다. 이를 통해 성과가 높은 상담원을 찾고 교육이 필요한 부분을 파악하며 상담원 간 이관이 전체 해결 시간에 미치는 영향을 분석할 수 있습니다.

중요한 이유

상담원별 성과를 분석해 우수 상담원, 교육 기회, 재배정의 영향을 파악할 수 있습니다.

확보 방법

Freshdesk 'Tickets' 객체의 'responder_id' 필드에 해당하며, 상담원 세부 정보와 연결할 수 있습니다.

예시
Alice JohnsonRobert SmithMaria Garcia
상태
Status
서비스 요청의 현재 또는 과거 상태입니다. 예: '접수', '보류', '해결', '종료'.
설명

상태 속성은 특정 시점의 서비스 요청 상태를 나타냅니다. 상태 변경은 프로세스의 주요 단계를 보여주는 경우가 많습니다. 예를 들어 고객의 답변을 기다릴 때 '접수'에서 '보류'로 바뀌거나, 고객이 답변하면 '보류'에서 '접수'로 바뀔 수 있습니다.

상태 변경을 추적하면 티켓의 전체 처리 과정을 파악할 수 있습니다. 티켓이 특정 상태에 머무는 시간을 확인해 병목을 찾는 데도 도움이 됩니다. 예를 들어 '보류' 상태가 오래 지속되면 고객에게서 정보를 받는 데 지연이 발생했을 수 있습니다.

중요한 이유

상태 변경을 추적하면 티켓의 전체 처리 과정을 파악하고, '보류' 또는 '대기'와 같은 특정 상태에 머무는 시간을 확인할 수 있습니다.

확보 방법

Freshdesk 'Tickets' 객체의 'status' 필드에 해당합니다. 과거 상태는 활동 로그를 바탕으로 추론해야 합니다.

예시
접수보류해결종료
서비스 요청 유형
ServiceRequestType
'Question', 'Incident', 'Problem', 'Feature Request' 등 서비스 요청의 분류입니다.
설명

서비스 요청 유형은 고객 문의의 성격을 정의하는 중요한 분류 필드입니다. 일반적으로 티켓 생성 시 또는 초기 분류 단계에서 설정하며, 요청을 적절한 팀이나 상담원에게 전달하는 데 사용합니다.

분석에서는 이 속성으로 프로세스를 세분화해 요청 유형별 처리 방식을 파악할 수 있습니다. '인시던트는 문의보다 해결 시간이 오래 걸리나요?', '어떤 요청 유형의 티켓이 가장 자주 재개되나요?'와 같은 질문에 답할 수 있습니다. 유형별 병목을 찾고 이에 맞춰 워크플로를 최적화하는 데 유용합니다.

중요한 이유

인시던트와 문의처럼 고객 문제 유형별로 프로세스를 나누어 성과와 워크플로를 비교할 수 있습니다.

확보 방법

Freshdesk 'Tickets' 객체의 'type' 필드일 가능성이 높습니다.

예시
문의인시던트문제기능 요청
우선순위
Priority
서비스 요청에 지정된 우선순위입니다. 예: '낮음', '보통', '높음', '긴급'.
설명

우선순위 속성은 서비스 요청의 긴급도를 나타내며, 목표 응답 시간과 해결 시간을 정하는 기준이 되는 경우가 많습니다. 규칙에 따라 자동으로 설정하거나, 상담원이 분류 과정에서 직접 지정할 수 있습니다.

이 속성은 SLA 준수 여부와 리소스 배분을 분석하는 데 중요합니다. 우선순위별로 프로세스 맵을 필터링하면 높은 우선순위의 티켓이 낮은 우선순위의 티켓보다 실제로 더 빠르게 처리되는지 확인할 수 있습니다. 우선순위 변경이라는 재작업이 자주 발생하는지, 프로세스에 어떤 영향을 미치는지도 파악할 수 있습니다.

중요한 이유

SLA 분석과 리소스가 높은 우선순위의 문제를 낮은 우선순위의 문제보다 빠르게 처리하도록 적절히 배분되는지 확인하는 데 중요합니다.

확보 방법

Freshdesk 'Tickets' 객체의 'priority' 필드에 해당합니다.

예시
낮음보통높음긴급
SLA 목표 해결 시간
SlaTargetResolutionTime
서비스 요청을 해결하기로 계약상 합의했거나 목표로 정한 시간입니다.
설명

이 속성은 서비스 수준 계약(SLA)에 따라 서비스 요청을 해결해야 하는 목표 시간을 정의합니다. 목표 시간은 티켓의 우선순위나 유형에 따라 달라질 수 있습니다.

SLA 준수 여부를 계산할 때 필요한 기준입니다. 실제 해결 시간과 목표 시간을 비교해 '준수' 또는 '위반' 여부를 판단할 수 있습니다. 요청 유형, 팀, 상담원별 SLA 성과 분석은 서비스 관리의 주요 업무입니다.

중요한 이유

SLA 준수 여부를 측정하는 기준을 제공하며, 고객 서비스 조직의 주요 성과 지표로 활용됩니다.

확보 방법

Freshdesk 'Tickets' 객체의 'fr_due_by'(최초 응답 기한) 또는 'due_by'(해결 기한)와 같은 필드에 있을 수 있습니다. 또는 SLA 정책 규칙을 바탕으로 계산해야 할 수도 있습니다.

예시
2023-10-25T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
SLA 위반 여부
IsSlaBreached
서비스 요청의 해결 시간이 SLA 목표 시간을 초과했는지 나타내는 참/거짓 값입니다.
설명

이 계산 속성은 각 서비스 요청의 SLA 준수 여부를 명확하게 표시합니다. 실제 'ResolutionTime'과 'SlaTargetResolutionTime'을 비교해 계산하며, 실제 시간이 목표 시간보다 길면 참으로 설정됩니다.

이 속성을 사용하면 SLA 준수 여부를 간편하게 분석하고 대시보드에 표시할 수 있습니다. SLA를 위반한 티켓을 쉽게 집계하고 필터링해 위반 규모를 빠르게 파악할 수 있으며, 해당 티켓의 프로세스 패턴을 살펴 근본 원인을 찾을 수 있습니다. SLA 준수 현황 대시보드와 KPI에도 직접 활용됩니다.

중요한 이유

목표 시간을 지키지 못한 각 사례를 명확히 표시해 SLA 준수 여부를 쉽게 분석하고 위반 원인을 파악할 수 있습니다.

확보 방법

계산 필드입니다. 실제 해결 시각과 Freshdesk의 'SlaTargetResolutionTime' 또는 'due_by' 필드를 비교해 계산합니다.

예시
truefalse
고객명
CustomerName
서비스 요청을 접수한 고객의 이름 또는 ID입니다.
설명

이 속성은 서비스 요청과 관련된 고객을 식별합니다. 고객 관점에서 프로세스를 분석하고 특정 고객의 모든 상호작용을 시간순으로 추적할 수 있습니다.

고객별 분석을 통해 티켓을 가장 많이 제출하는 고객이나 재오픈을 자주 겪는 고객을 파악할 수 있습니다. 이를 바탕으로 고객 성공 활동을 계획하고, 서비스 경험이 좋지 않아 이탈 위험이 있는 고객을 찾아낼 수 있습니다. 여러 서비스 요청에 걸친 고객 여정을 처음부터 끝까지 파악하는 데도 중요합니다.

중요한 이유

고객 관점에서 프로세스를 살펴보고, 요청이 잦거나 같은 문제를 반복해서 겪는 고객을 파악할 수 있습니다.

확보 방법

'Tickets' 객체의 'requester_id'를 통해 연결됩니다. 이 값은 Freshdesk의 'Contacts' 또는 'Users' 객체를 참조합니다.

예시
홍길동김영희글로벌 테크 주식회사.
담당 그룹
AssignedGroup
서비스 요청을 담당하는 팀 또는 부서입니다.
설명

담당 그룹은 특정 서비스 요청을 처리하는 상담원 팀을 나타냅니다. 티켓은 유형이나 복잡도에 따라 '기술 지원' 또는 '결제 부서'와 같은 전문 그룹으로 배정되는 경우가 많습니다.

이 속성을 활용하면 부서 간 인계와 팀별 성과를 분석할 수 있습니다. 각 그룹이 처리하는 티켓 수와 해결 시간이 긴 그룹, 그룹 간 티켓 이관 빈도를 파악할 수 있습니다. 이러한 정보는 팀 구조와 워크플로를 개선하는 데 도움이 됩니다.

중요한 이유

팀 또는 부서별 성과를 분석하고, 인계 현황과 그룹별 병목을 파악할 수 있습니다.

확보 방법

Freshdesk 'Tickets' 객체의 'group_id' 필드에 해당합니다.

예시
1차 지원2차 기술 지원결제고객 성공
만족도 평가
SatisfactionRating
티켓 해결 후 고객이 제출한 만족도 점수입니다.
설명

만족도 평가는 주요 결과 지표로, 일반적으로 티켓 해결 후 발송하는 설문을 통해 수집합니다. 숫자 점수나 '만족', '보통', '불만족'과 같은 등급으로 표시됩니다.

이 속성을 사용하면 프로세스 패턴과 고객 결과의 연관성을 분석할 수 있습니다. 만족도 점수가 낮은 프로세스 변형을 살펴보면 고객 경험에 부정적인 영향을 미치는 행동이나 지연을 찾을 수 있습니다. 이를 통해 프로세스 효율과 고객 만족도의 관계를 직접 확인할 수 있습니다.

중요한 이유

프로세스 실행 결과를 고객 성과와 연결해, 어떤 프로세스 행동이 고객 만족도를 높이거나 낮추는지 파악할 수 있습니다.

확보 방법

이 데이터는 Freshdesk의 만족도 평가 기능에 포함되며, 'Surveys' 또는 'Satisfaction Ratings' API 엔드포인트에서 가져올 수 있습니다.

예시
5314
문의 채널
CommunicationChannel
서비스 요청이 접수된 채널입니다. 예: '이메일', '전화', '채팅', '웹 포털'.
설명

이 속성은 고객 문의가 접수된 경로 또는 채널을 나타냅니다. 채널에 따라 프로세스 흐름과 해결 시간이 다를 수 있습니다. 예를 들어 채팅으로 접수된 요청은 이메일로 제출된 요청보다 예상 해결 시간이 짧을 수 있습니다.

문의 채널별로 프로세스를 분석하면 리소스 배분을 최적화하고 채널별 효율을 파악할 수 있습니다. 해결이 빠르거나 고객 만족도가 높은 채널을 확인해 어떤 채널을 활성화하거나 투자할지 결정하는 데 참고할 수 있습니다.

중요한 이유

이메일, 전화, 채팅 등 고객 문의 채널별로 프로세스 성과와 효율을 분석할 수 있습니다.

확보 방법

Freshdesk 'Tickets' 객체의 'source' 필드에 해당합니다.

예시
이메일전화웹 포털채팅
상담원 이관 횟수
AgentTransferCount
서비스 요청이 한 상담원에서 다른 상담원으로 재배정된 총횟수입니다.
설명

이 케이스 수준 지표는 티켓의 담당 상담원이 바뀐 횟수를 셉니다. 각 서비스 요청에서 '티켓 재배정' 활동이 발생한 횟수로 계산합니다.

잦은 이관은 '핑퐁'이라고도 하며, 인계할 때마다 맥락이 끊겨 처리 지연과 고객 불만으로 이어질 수 있습니다. 이관 횟수를 분석하면 최초 라우팅 문제, 상담원 역량 격차, 프로세스 복잡성 등을 파악할 수 있습니다. 불필요한 이관을 줄여 효율과 고객 만족도를 높이는 것이 일반적인 목표입니다.

중요한 이유

내부 인계 빈도를 측정합니다. 인계는 지연과 고객 불만의 주요 원인이 될 수 있으므로, 분석 결과를 활용해 1차 해결률을 높일 수 있습니다.

확보 방법

계산 필드입니다. 고유한 각 Service Request에서 발생한 'Ticket Reassigned' 활동 수입니다.

예시
0132
원천 시스템
SourceSystem
데이터를 추출한 시스템입니다. 여기서는 'Freshdesk'를 의미합니다.
설명

이 속성은 프로세스 데이터가 발생한 원천 애플리케이션을 식별합니다. 이 분석에서는 값이 'Freshdesk'처럼 고정되어 모든 이벤트가 Freshdesk 고객 서비스 플랫폼에서 발생했음을 나타냅니다.

단순해 보일 수 있지만 데이터 거버넌스와 여러 시스템의 데이터를 결합하는 상황에서 중요한 속성입니다. 데이터의 출처와 맥락을 명확히 해 분석 담당자가 검토 중인 데이터의 원천을 알 수 있게 합니다. 데이터 무결성을 유지하고 분석 결과에 대한 신뢰를 쌓는 데 필요합니다.

중요한 이유

데이터 출처에 관한 정보를 제공하므로 데이터 거버넌스와 여러 원천 시스템의 데이터를 결합할 때 중요합니다.

확보 방법

데이터 원천을 식별하기 위해 데이터 변환 과정에서 추가하는 고정값 'Freshdesk'입니다.

예시
Freshdesk
재오픈 여부
IsReopened
해결된 서비스 요청이 다시 열린 적이 있는지 나타내는 참/거짓 값입니다.
설명

이 케이스 수준 속성은 서비스 요청의 처리 과정 중 '티켓 재오픈' 활동이 한 번이라도 발생하면 참으로 설정됩니다. 재작업이 필요한 케이스를 간편하게 식별하고 분석할 수 있습니다.

재오픈 티켓 비율이 높으면 최초 해결이 효과적이지 않았거나 충분하지 않아 비효율과 고객 불만이 발생했을 가능성이 있습니다. 재오픈 티켓을 필터링하면 재오픈의 일반적인 원인, 비율이 높은 상담원이나 팀, 재오픈이 잦은 티켓 유형 등 근본 원인을 조사할 수 있습니다.

중요한 이유

재작업이 필요한 케이스를 찾아냅니다. 이는 해결 품질과 프로세스 비효율을 보여주는 주요 지표입니다. 해당 케이스를 분석하면 최초 접촉 해결률을 높이는 데 도움이 됩니다.

확보 방법

계산 필드입니다. 해당 케이스에 Activity = '티켓 재개'인 이벤트가 있으면 Service Request의 값을 true로 설정합니다.

예시
truefalse
제품
Product
고객의 요청과 관련된 제품 또는 서비스입니다.
설명

이 속성은 서비스 요청의 대상이 되는 제품 또는 서비스 라인을 지정합니다. 티켓 분류와 라우팅, 보고를 위해 Freshdesk에서 사용자 지정 필드로 설정하는 경우가 많습니다.

제품별로 프로세스를 필터링하면 제품별 문제를 파악할 수 있습니다. 특정 제품에서 지원 티켓이 유난히 많이 발생하거나 신제품 출시 후 문의가 급증하는 상황을 확인할 수 있습니다. 이러한 분석 결과는 제품 개발 및 관리 팀에 유용한 피드백이 됩니다.

중요한 이유

제품 영역별로 프로세스를 필터링해 지원 요청이 가장 많이 발생하거나 해결 시간이 가장 긴 제품을 파악할 수 있습니다.

확보 방법

일반적으로 사용자 지정 필드입니다. 정확한 위치는 Freshdesk 설정에 따라 다르며, 'Tickets' API 응답의 'custom_fields' 항목에 있을 수 있습니다.

예시
알파 플랫폼베타 모바일 앱감마 구독 서비스
최종 데이터 업데이트
LastDataUpdate
원천 시스템에서 데이터를 마지막으로 새로 고친 시점을 나타내는 타임스탬프입니다.
설명

이 속성은 Freshdesk에서 데이터 세트를 마지막으로 추출하거나 업데이트한 날짜와 시간을 기록합니다. 분석 중인 데이터의 최신 상태를 투명하게 보여주므로 시의적절하고 적절한 업무 결정을 내리는 데 중요합니다.

분석 담당자는 이 정보를 통해 데이터가 포함하는 기간을 파악하고 현재 이용할 수 있는 최신 정보로 작업 중인지 확인합니다. process mining 대시보드나 보고서에 필요한 주요 메타데이터로, 이해관계자가 데이터의 최신성을 알 수 있게 합니다.

중요한 이유

데이터의 최신성을 나타내므로 최신 정보를 바탕으로 분석하고 의사결정할 수 있습니다.

확보 방법

데이터 추출 과정에서 생성되는 메타데이터 필드로, 데이터를 가져온 시점의 타임스탬프를 기록합니다.

예시
2023-12-01T08:00:00Z
최초 응답 시간
FirstResponseTime
티켓 생성부터 상담원이 고객에게 처음 응답할 때까지 걸린 시간입니다.
설명

최초 응답 시간은 고객이 서비스 상담원에게 자동 응답이 아닌 첫 답변을 받기까지 걸린 시간을 측정합니다. '최초 응답 전송' 활동 시각에서 '티켓 생성' 활동 시각을 빼서 계산합니다.

이 KPI는 서비스 응답성을 보여주는 주요 지표이며 고객 만족도에 큰 영향을 미칩니다. 최초 응답이 빠르면 고객은 자신의 문제가 접수되어 처리 중임을 알 수 있습니다. 이 지표를 분석하면 최초 응답 SLA를 준수하고 고객에게 신속하게 응대하는지 확인할 수 있습니다.

중요한 이유

서비스 응답성을 측정합니다. 고객 만족도에 큰 영향을 미치며 선제적인 서비스 제공 목표와도 직접 관련됩니다.

확보 방법

계산 필드입니다. '티켓 생성' 이벤트와 '최초 응답 전송' 이벤트의 시각 차이로 계산합니다.

예시
3000009000001800000
필수 권장 선택 사항

고객 서비스 활동

프로세스를 정확히 파악하고 병목을 찾으려면 다음 주요 단계와 중요 시점을 이벤트 로그에 기록하세요.
5 권장 8 선택 사항
활동 설명
첫 응답 발송
티켓 생성 후 상담원이 고객에게 처음으로 공개 답변을 보낸 시점을 나타냅니다. Freshdesk는 SLA 추적을 위해 'First Response Time'을 측정하며 이 이벤트를 명시적으로 기록합니다.
중요한 이유

고객 응답성과 SLA 준수 여부를 측정하는 주요 기준점입니다. 이 활동까지 걸린 시간을 분석하면 고객과의 첫 소통이 지연되는 지점을 찾을 수 있습니다.

확보 방법

Freshdesk가 SLA 측정을 위해 추적하는 특정 이벤트입니다. 상담원이 처음으로 공개 댓글을 작성한 시각에 해당합니다.

기록

티켓 대화 내역에서 상담원이 처음으로 보낸 공개 답변을 기준으로 확인합니다.

이벤트 유형 explicit
티켓 배정
티켓을 담당할 특정 상담원이나 그룹에 배정하는 활동입니다. 담당 상담원 또는 그룹 필드에 값이 입력되거나 변경될 때 티켓 기록에 명시적으로 남습니다.
중요한 이유

배정 내역을 추적하면 상담원별 업무량을 분석하고 라우팅의 비효율을 찾아 배정까지 걸리는 시간 KPI를 측정할 수 있습니다. 업무가 어떻게 분배되는지, 업무 시작 전에 어디서 지연되는지 파악하는 데 도움이 됩니다.

확보 방법

'티켓 활동' 로그에서 수집합니다. '담당자' 또는 '그룹' 필드의 변경 사항이 타임스탬프와 함께 기록됩니다.

기록

상담원 또는 그룹의 'Assigned to' 필드가 업데이트될 때 기록되는 이벤트입니다.

이벤트 유형 explicit
티켓 생성
고객 서비스 과정의 첫 이벤트로, 고객 요청이 Freshdesk에 공식적으로 기록되는 시점을 나타냅니다. 이메일, 포털, 전화 또는 API 연동을 통해 새 티켓이 생성되면 이 활동이 명시적으로 기록됩니다.
중요한 이유

이 활동은 모든 케이스의 시작점입니다. 전체 해결 시간을 계산하고 채널이나 유형별 티켓 수 추세를 분석하는 데 필요합니다.

확보 방법

Freshdesk의 '티켓 활동' 로그에 명시적으로 기록되는 이벤트입니다. 새 티켓 레코드가 생성되면 자동으로 생성됩니다.

기록

티켓 생성 시 활동 내역에 직접 기록됩니다.

이벤트 유형 explicit
티켓 종료
티켓을 최종적으로 종료하는 마지막 활동입니다. 고객이 추가 답변을 하지 않은 채 티켓이 일정 기간 'Resolved' 상태로 유지되면 시스템이 자동으로 종료하는 경우가 많습니다.
중요한 이유

이 활동은 서비스 요청 과정이 완전히 끝난 시점을 나타냅니다. 전체 처리 주기를 정확히 계산할 수 있는 최종 기준점입니다.

확보 방법

'티켓 활동' 로그에서 수집합니다. 이 로그에는 최종 상태가 '종료됨'으로 변경된 기록이 남으며, 시스템 자동화로 변경되는 경우가 많습니다.

기록

티켓의 'Status' 필드가 'Closed'로 업데이트될 때 기록되는 이벤트입니다.

이벤트 유형 explicit
티켓 해결
상담원이 해결책을 제공하고 티켓 상태를 'Resolved'로 변경한 주요 시점을 나타냅니다. 티켓 기록에 상태 변경으로 명시적으로 남습니다.
중요한 이유

이 활동은 티켓에 대한 실질적인 업무가 끝난 시점을 나타내며 해결 시간 측정의 기준이 됩니다. 상담원 성과와 전체 프로세스 효율을 분석하는 데 중요한 이벤트입니다.

확보 방법

'티켓 활동' 로그에서 수집합니다. 타임스탬프와 함께 '해결됨'으로 변경된 상태가 기록됩니다.

기록

티켓의 'Status' 필드가 'Resolved'로 업데이트될 때 기록되는 이벤트입니다.

이벤트 유형 explicit
SLA 위반
티켓 응답 또는 해결에 걸린 시간이 정해진 SLA 목표를 초과할 때 발생하는 계산 이벤트입니다. Freshdesk는 SLA 상태를 추적하고 티켓을 'violated'로 표시합니다. 이 정보를 바탕으로 해당 활동을 도출할 수 있습니다.
중요한 이유

이 활동은 서비스 수준 약속이 지켜지지 않은 시점과 위치를 정확히 파악해 SLA 준수 여부를 분석하는 데 도움이 됩니다. 지연의 구조적 원인을 찾는 데 중요합니다.

확보 방법

티켓의 'SLA' 상태를 확인해 추론하거나 계산하는 이벤트입니다. 티켓의 SLA 상태가 'Violated'로 변경될 때 활동을 생성하거나, 응답 및 해결 타임스탬프를 SLA 목표와 비교해 도출할 수 있습니다.

기록

'Time to Resolve'가 'SLA Target Resolution Time'을 초과하는 경우 티켓 데이터에서 도출합니다.

이벤트 유형 calculated
고객 응답
고객이 새 답변이나 메시지를 보낸 것을 나타냅니다. 티켓 대화 내역에 명시적으로 기록되는 이벤트이며, 일반적으로 티켓 상태를 'Pending'에서 'Open'으로 변경합니다.
중요한 이유

이 활동을 통해 고객과의 반복적인 소통 양상을 파악하고 고객 응답 시간을 측정할 수 있습니다. 일시 중지된 SLA 타이머도 다시 시작되어 규정 준수 지표에 영향을 줍니다.

확보 방법

티켓 대화 내역에 새 항목으로 기록됩니다. 이 이벤트는 고객 연락처 레코드와 연결됩니다.

기록

고객 연락처가 티켓에 새 공개 메모를 추가한 경우입니다.

이벤트 유형 explicit
내부 메모 추가
상담원이 다른 상담원과의 내부 협업을 위해 티켓에 비공개 메모를 추가합니다. 티켓 활동 내역에 명시적으로 기록되며 상담원에게만 표시됩니다.
중요한 이유

내부 메모를 추적하면 협업 양상을 분석하고 내부 논의가 많이 필요한 문제를 찾을 수 있습니다. 해결 전에 내부 메모가 자주 작성된다면 문제가 복잡하거나 지식이 부족하다는 신호일 수 있습니다.

확보 방법

티켓 대화 내역에 'Private Note'로 기록되며, 고객에게 공개되는 답변과 구분됩니다.

기록

상담원이 'Private'로 표시된 메모를 추가할 때 기록되는 이벤트입니다.

이벤트 유형 explicit
만족도 설문 발송
일반적으로 티켓 해결 후 자동화 규칙에 따라 고객 만족도 설문을 발송하는 활동입니다. 자동화 작업이 티켓 기록에 남는 경우 이 이벤트를 확인할 수 있습니다.
중요한 이유

고객 피드백 수집의 시작을 나타냅니다. 설문 응답과 프로세스 유형을 연결하면 프로세스 성과가 고객 만족도에 미치는 영향을 자세히 파악할 수 있습니다.

확보 방법

일반적으로 'Automation Rule'이 실행되어 발송됩니다. 티켓 활동 로그에 개별 이벤트로 표시되는지는 Freshdesk의 자동화 기록 설정에 따라 다릅니다.

기록

티켓 해결 후 자동화 규칙이 실행될 때 기록되는 이벤트입니다.

이벤트 유형 explicit
상태를 보류로 변경
상담원이 고객의 정보를 기다리며 티켓 상태를 'Pending'으로 변경할 때 발생합니다. 이 이벤트는 티켓 활동 내역에 상태 변경으로 명시적으로 기록됩니다.
중요한 이유

외부 응답을 기다리느라 프로세스가 중단된 기간을 보여줍니다. 이 상태에 머문 시간을 분석하면 고객 측 지연을 정량화하고 SLA 준수 여부를 검토할 수 있습니다. 이 상태에서는 SLA 타이머가 일시 중지되는 경우가 많습니다.

확보 방법

'티켓 활동' 로그에서 수집합니다. 이 로그에는 '보류 중'으로의 전환을 포함한 모든 상태 변경이 기록됩니다.

기록

티켓의 'Status' 필드가 'Pending'으로 업데이트될 때 기록되는 이벤트입니다.

이벤트 유형 explicit
티켓 우선순위 변경
상담원이나 자동화 규칙이 티켓 우선순위를 'Low'에서 'High'로 변경하는 등의 경우에 발생합니다. 티켓 활동 로그에 명시적인 업데이트로 기록됩니다.
중요한 이유

우선순위 변경은 에스컬레이션이나 문제의 긴급성 재평가를 나타낼 수 있습니다. 변경 내역을 분석하면 에스컬레이션의 원인과 해결 시간에 미치는 영향을 파악할 수 있습니다.

확보 방법

'티켓 활동' 로그에서 수집합니다. 이 로그에는 '우선순위' 필드를 포함한 티켓 속성의 모든 변경 사항이 기록됩니다.

기록

'Priority' 필드 값이 업데이트될 때 기록되는 이벤트입니다.

이벤트 유형 explicit
티켓 재개
'Resolved' 상태인 티켓에 고객이 답변하면 발생하며, 티켓 상태가 자동으로 다시 'Open'으로 변경됩니다. 시스템에 명시적으로 기록되는 이벤트입니다.
중요한 이유

재개율이 높다면 최초 해결책이 효과적이지 않아 재작업과 고객 불만이 발생하고 있을 수 있습니다. 이 활동을 분석하면 'Ticket Re-opening Analysis'를 수행하고 최초 응대 해결률을 높이는 데 도움이 됩니다.

확보 방법

고객의 답변으로 상태가 '해결됨'에서 '열림'으로 자동 변경될 때 이 이벤트를 수집합니다. 상태 변경은 '티켓 활동' 로그에 기록됩니다.

기록

고객의 상호작용으로 티켓 상태가 'Resolved'에서 'Open'으로 변경된 경우입니다.

이벤트 유형 explicit
티켓 재배정
최초 배정 후 티켓을 한 상담원이나 그룹에서 다른 상담원이나 그룹으로 옮길 때 발생합니다. 티켓 활동 로그에 담당자 변경으로 명시적으로 기록됩니다.
중요한 이유

재배정이 잦거나 상담원 간 이관율이 높다면 최초 라우팅이 잘못되었거나 지식이 부서별로 분산되어 있을 수 있습니다. 이 분석을 통해 최초 응대에서 해결률을 높일 기회를 찾을 수 있습니다.

확보 방법

최초 배정 이후 '티켓 활동' 로그에서 '담당자' 또는 '그룹' 필드의 변경 사항을 추적합니다.

기록

최초 배정 후 'Assigned to' 필드가 다시 업데이트된 경우입니다.

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

데이터 추출 가이드

Freshdesk에서 데이터 추출하기

시작할 준비가 되셨나요?

프로세스를 명확히 파악하는 것부터 고객 서비스 운영 개선을 시작하세요. 이 템플릿을 활용하면 데이터 기반 최적화를 위한 첫걸음을 뗄 수 있습니다.

지금 Freshdesk 고객 서비스를 최적화하세요

최초 문의 해결률 80%를 달성해 고객 만족도를 높이세요.

무료 체험 시작하기

신용카드 없이 몇 분 만에 설정할 수 있습니다