고객 서비스 데이터 템플릿
고객 서비스 데이터 템플릿
- 수집 권장 속성
- 추적할 주요 활동
- Microsoft Dynamics 365 고객 서비스 데이터 추출 안내
고객 서비스 속성
| 이름 | 설명 | ||
|---|---|---|---|
|
서비스 요청
ServiceRequest
|
사례 또는 티켓이라고도 하는 고객 서비스 요청의 고유 식별자입니다. | ||
|
설명
서비스 요청은 기본 식별자로, 하나의 고객 문의나 문제와 관련된 모든 활동을 연결합니다. process mining에서 사례 ID로 사용되어 생성부터 종료까지 각 고객 상호작용을 일관된 관점에서 확인할 수 있습니다. 서비스 요청별로 분석하면 전체 처리 과정을 추적하고 해결 시간을 측정하며 유사한 사례의 패턴을 찾을 수 있습니다.
중요한 이유
관련된 모든 이벤트를 하나의 프로세스 인스턴스로 연결하는 사례 ID입니다. 이를 통해 프로세스 전체를 분석할 수 있습니다.
확보 방법
Microsoft Dynamics 365 Customer Service의 Case(incident) 엔터티에서 사용하는 기본 키입니다.
예시
CAS-01024-F3B4V6SR-2023-00589TKT-4815162342
|
|||
|
마지막 데이터 업데이트
LastDataUpdate
|
원본 시스템에서 데이터를 마지막으로 새로 고치거나 추출한 시점의 타임스탬프입니다. | ||
|
설명
이 속성은 Microsoft Dynamics 365에서 데이터를 마지막으로 가져온 시점을 나타냅니다. 분석에 사용하는 데이터의 최신성을 확인하고 보고 및 모니터링에 활용합니다. 대시보드와 분석 결과를 해석할 때 데이터의 시점을 알 수 있습니다.
중요한 이유
데이터가 얼마나 최신인지 알려주므로 프로세스 분석을 바탕으로 시의적절하고 정확한 업무 결정을 내리는 데 도움이 됩니다.
확보 방법
데이터 추출 시 데이터 세트에 생성해 기록하는 값입니다.
예시
2023-10-27T08:00:00Z
|
|||
|
시작 시간
EventTime
|
활동이 발생한 시점을 나타내는 타임스탬프입니다. | ||
|
설명
이 속성은 특정 활동이 발생한 정확한 날짜와 시간을 기록합니다. 이벤트 순서를 올바르게 정하고 처리 시간, 소요 시간, 활동 간 대기 시간 등 시간 기반 분석을 수행하는 데 필요합니다. 정확하고 일관된 타임스탬프는 process mining 분석의 신뢰성을 좌우합니다.
중요한 이유
이 타임스탬프를 기준으로 이벤트를 시간순으로 정렬하고 모든 소요 시간 기반 계산을 수행할 수 있습니다. 이는 성과 분석과 병목 파악에 중요합니다.
확보 방법
이는 Case(incident) 엔터티 또는 관련 활동 엔터티(예: Email, Task, Phone Call)의 'createdon'이나 'modifiedon'과 같은 필드에 해당합니다.
예시
2023-04-15T10:00:00Z2023-05-20T14:35:10Z2023-06-01T09:12:45Z
|
|||
|
원본 시스템
SourceSystem
|
데이터를 추출한 원본 시스템을 식별합니다. | ||
|
설명
이 속성은 이벤트 데이터의 출처를 나타냅니다. 이 프로세스에서는 원본 시스템이 Microsoft Dynamics 365 Customer Service로 표시됩니다. 여러 시스템을 사용하는 환경에서는 데이터 출처를 구분하고 데이터 계보를 확인하는 데 중요합니다.
중요한 이유
데이터 계보를 명확히 파악할 수 있어 데이터 거버넌스와 데이터 불일치 문제 해결에 도움이 됩니다. 여러 시스템의 데이터를 결합해 분석할 때 특히 유용합니다.
확보 방법
일반적으로 데이터 추출 및 변환 과정에서 데이터 세트의 출처를 표시하기 위해 추가하는 고정값입니다.
예시
Microsoft Dynamics 365 고객 서비스
|
|||
|
활동
ActivityName
|
특정 시점에 서비스 요청에서 발생한 구체적인 업무 이벤트의 이름입니다. | ||
|
설명
이 속성은 '사례 생성', '상담원의 문제 조사', '사례 해결'과 같이 고객 서비스 프로세스의 단일 단계나 상태 변경을 나타냅니다. 이러한 활동을 바탕으로 프로세스 맵을 구성하고 프로세스 흐름을 시각화하고 분석할 수 있습니다. 각 활동에 타임스탬프를 연결하면 프로세스 순서를 정의하는 이벤트가 됩니다.
중요한 이유
활동은 프로세스의 단계를 나타냅니다. 활동의 순서와 빈도를 분석하면 프로세스 흐름을 이해하고 이탈을 찾아 병목을 파악할 수 있습니다.
확보 방법
일반적으로 상태 변경(statuscode)이나 Tasks, Emails, Phone Calls와 같은 관련 엔터티의 특정 이벤트를 표준 활동 이름에 매핑해 도출합니다.
예시
사례 생성상담원의 문제 조사고객에게 해결책 제안사례 종료
|
|||
|
SLA 목표 해결 시간
SlaTargetResolutionTime
|
서비스 요청 해결을 위해 계약상 합의한 목표 시간입니다. | ||
|
설명
이 속성은 유효한 서비스 수준 계약(SLA)에 따라 서비스 요청을 해결해야 하는 목표 시간을 지정합니다. 실제 성과를 측정하는 기준으로 사용됩니다. SLA 준수 모니터링 대시보드와 SLA 준수율 KPI를 계산하는 데 필요하며, 서비스 약속을 지키지 못하는 프로세스를 파악할 수 있습니다.
중요한 이유
서비스 약속에 대한 성과를 측정하는 주요 기준으로, SLA 준수 여부와 위반을 직접 분석할 수 있습니다.
확보 방법
이 값은 Dynamics 365의 SLA 설정에 따라 결정되며, SLA KPI Instance를 통해 사례와 연결됩니다.
예시
2592008640014400
|
|||
|
고객 이름
CustomerName
|
서비스 요청과 연결된 고객 또는 계정의 이름입니다. | ||
|
설명
이 속성은 서비스 요청을 시작한 고객을 식별합니다. 고객 관점에서 프로세스를 분석해 요청이 많은 고객, 해결 시간이 긴 고객, 복잡한 문제를 겪는 고객을 파악할 수 있습니다. 고객 관계를 관리하고 고객별 서비스 제공 방식을 개선하는 데 필요합니다.
중요한 이유
고객별 분석을 통해 패턴을 찾고 주요 계정에 대한 서비스를 개선하며 고객 여정을 파악할 수 있습니다.
확보 방법
Case(incident) 엔터티의 'Customer'(customerid) 조회 필드입니다. Account 또는 Contact 레코드를 참조할 수 있습니다.
예시
글로벌 테크 주식회사.제인 도이노베이트 솔루션즈
|
|||
|
상담원 이름
AgentName
|
활동을 담당한 고객 서비스 상담원 또는 사용자의 이름입니다. | ||
|
설명
이 속성은 큐에서 항목을 선택하거나 사례를 해결하는 등 활동을 수행한 상담원이나 시스템 사용자를 식별합니다. 상담원 성과와 업무량 배분, 리소스 할당을 분석하는 데 중요합니다. 상담원별 활동을 추적하면 우수한 성과를 내는 직원, 교육 필요성, 업무량 불균형을 파악할 수 있습니다.
중요한 이유
개인과 팀의 성과를 분석하고 업무량을 균형 있게 배분하며, 서비스 품질 향상을 위한 코칭 기회를 찾을 수 있습니다.
확보 방법
Case(incident) 엔터티의 'Owner'(ownerid) 필드에 해당하며, System User(systemuser) 엔터티와 연결됩니다.
예시
앨리스 스미스밥 존슨시스템
|
|||
|
상태 사유
StatusReason
|
서비스 요청의 현재 상태를 구체적으로 설명하는 사유입니다. | ||
|
설명
사례의 상태가 '활성' 또는 '해결됨'처럼 넓은 범주로 표시되는 반면, 상태 사유는 '정보 제공 완료'나 '문제 해결'처럼 구체적인 맥락을 제공합니다. 이 속성은 사례가 처리되는 과정과 이유를 세부적으로 파악하는 데 중요합니다. 예를 들어 성공적으로 해결된 사례와 고객이 취소한 사례를 구분할 수 있어 결과를 정확하게 분석할 수 있습니다.
중요한 이유
사례의 결과와 상태 변경 사유를 세부적으로 파악해 해결 경로와 근본 원인을 더 정확하게 분석할 수 있습니다.
확보 방법
Case(incident) 엔터티의 'Status Reason'(statuscode) 필드에 해당합니다.
예시
진행 중보류 중문제 해결정보 제공 완료
|
|||
|
서비스 요청 유형
ServiceRequestType
|
서비스 요청의 주요 범주 또는 분류입니다. | ||
|
설명
이 속성은 '청구 문의', '기술 지원', '제품 피드백' 등 요청의 성격에 따라 서비스 요청을 분류합니다. 요청 유형별로 프로세스를 나누어 분석하면 각 유형의 처리 방식을 파악할 수 있습니다. 유형별 분석을 통해 해결 시간이 길거나 에스컬레이션율이 높고, 다른 경로로 처리되는 범주를 찾을 수 있습니다.
중요한 이유
유형별로 프로세스를 나누어 분석하면 병목과 리소스 수요, 개선 기회를 파악하고 더 나은 라우팅 및 처리 방식을 마련할 수 있습니다.
확보 방법
이 정보는 Case(incident) 엔터티의 'Subject'(subjectid) 필드나 사용자 지정 범주 필드에 저장되는 경우가 많습니다.
예시
청구 문의기술 지원제품 피드백계정 관리
|
|||
|
우선순위
Priority
|
서비스 요청의 긴급도를 나타내는 우선순위입니다. | ||
|
설명
이 속성은 서비스 요청의 긴급도를 정의하며, 일반적으로 낮음, 보통, 높음, 긴급으로 구분합니다. 우선순위에 따라 사례 처리 순서가 정해지고 SLA 목표가 달라지는 경우가 많습니다. 우선순위가 프로세스 흐름과 리소스 할당, 해결 시간에 미치는 영향을 분석하면 긴급한 문제를 신속하게 처리할 수 있습니다.
중요한 이유
우선순위가 높은 요청을 더 빠르게 처리해 목표를 달성하는지, 우선순위가 전체 프로세스 성과에 어떤 영향을 미치는지 파악할 수 있습니다.
확보 방법
Case(incident) 엔터티의 'Priority'(prioritycode) 필드에 해당합니다.
예시
낮음보통높음
|
|||
|
채널
Channel
|
서비스 요청이 접수된 커뮤니케이션 채널입니다. | ||
|
설명
이 속성은 전화, 이메일, 웹 포털, 채팅 등 고객 상호작용이 시작된 경로를 나타냅니다. 채널마다 프로세스 흐름과 고객 기대, 해결 난이도가 다를 수 있습니다. 채널별로 프로세스를 분석하면 해당 채널의 워크플로와 리소스 배분을 개선할 수 있습니다.
중요한 이유
고객 문의 채널에 따라 프로세스 효율과 해결 시간, 고객 만족도가 어떻게 달라지는지 파악할 수 있습니다.
확보 방법
Case(incident) 엔터티의 'Case Origin'(caseorigincode) 필드에 해당합니다.
예시
전화이메일웹채팅
|
|||
|
CSAT 점수
CustomerSatisfactionScore
|
케이스 해결 후 고객이 제공한 만족도 점수입니다. | ||
|
설명
이 속성에는 고객 만족도(CSAT) 설문에서 받은 숫자 또는 범주형 평가가 저장됩니다. 일반적으로 서비스 요청을 종료한 후 수집합니다. 서비스 품질에 대한 고객의 인식을 직접 측정하는 값입니다. 이 데이터는 고객 만족도 추이 대시보드와 해결 후 평균 CSAT 점수 KPI를 구성하고, 프로세스 성과와 고객 경험을 연결하는 데 중요합니다.
중요한 이유
고객 만족도를 직접 측정하여 프로세스 운영 방식과 고객 반응의 관계를 파악하고 개선을 추진할 수 있습니다.
확보 방법
일반적으로 Customer Voice와 같은 관련 설문 엔터티에서 가져와 Case(incident) 엔터티에 연결합니다.
예시
5341
|
|||
|
SLA 위반 여부
IsSlaBreached
|
서비스 요청이 SLA 목표 시간을 초과했는지 나타내는 계산 플래그입니다. | ||
|
설명
이 불리언 플래그는 서비스 요청의 실제 해결 시간과 'SLA 목표 해결 시간'을 비교해 결정합니다. 실제 시간이 목표 시간을 초과하면 true로 설정됩니다. 이 속성은 SLA 준수 모니터링 대시보드와 SLA 준수율 KPI를 구성하는 데 사용되며, 각 케이스의 SLA 성과를 명확한 참·거짓 값으로 보여줍니다.
중요한 이유
각 케이스의 SLA 준수 여부를 명확히 표시하므로 위반 원인을 쉽게 필터링하고 집계해 분석할 수 있습니다.
확보 방법
'ServiceRequestCycleTime'과 'SlaTargetResolutionTime'을 비교해 계산합니다.
예시
truefalse
|
|||
|
관련 제품
ProductInvolved
|
고객의 서비스 요청과 관련된 제품입니다. | ||
|
설명
이 속성은 고객 문제가 발생한 특정 제품이나 서비스를 식별합니다. 제품별로 서비스 프로세스를 구분하면 특정 제품에서 지원 요청이 더 많이 발생하는지, 문제가 더 복잡한지, 전문 상담원 역량이 필요한지 확인할 수 있습니다. 분석 결과는 제품 개선과 리소스 계획에 활용할 수 있습니다.
중요한 이유
제품별 프로세스를 분석해 반복되는 제품 문제를 파악하고, 지원 문서를 개선하며, 전문 인력을 효율적으로 배정할 수 있습니다.
확보 방법
Case(incident) 엔터티의 'Product'(productid) 조회 필드에 해당합니다.
예시
Alpha-100 프린터Zeta CRM 소프트웨어Omega 데이터 요금제
|
|||
|
담당 팀
OwnerTeam
|
현재 서비스 요청을 담당하는 팀입니다. | ||
|
설명
이 속성은 서비스 요청을 담당하는 팀을 식별합니다. 요청은 개별 상담원이나 팀(대기열)이 담당할 수 있습니다. 팀별 분석은 팀 단위 성과와 지원 단계 또는 전문 분야별 업무량 분포를 파악하고, 팀 간 프로세스 차이를 확인하는 데 중요합니다.
중요한 이유
팀 단위로 성과를 분석하여 지원 단계와 전문 그룹을 효과적으로 관리할 수 있습니다.
확보 방법
Case(incident) 엔터티의 'Owner'(ownerid) 필드에서 가져옵니다. 소유자가 System User가 아닌 Team 레코드인 경우에 해당합니다.
예시
1차 지원팀청구 부서기술 전문가
|
|||
|
에스컬레이션 여부
IsEscalated
|
서비스 요청이 상위 단계로 이관되었는지 나타내는 플래그입니다. | ||
|
설명
이 불리언 속성은 서비스 요청이 상위 단계로 이관되었는지 나타냅니다. 1차 지원팀에서 문제를 해결하지 못해 상위 지원팀이나 전문가의 개입이 필요한 경우 이관이 발생합니다. 이 플래그를 추적하면 내부 이관 경로 대시보드와 내부 이관율 KPI를 구성하고, 이관의 근본 원인과 초기 지원 단계의 취약점을 파악할 수 있습니다.
중요한 이유
이관 빈도를 직접 측정해 최초 접촉 해결의 문제를 드러내고, 프로세스 개선이나 상담원 역량 강화가 필요한 영역을 파악합니다.
확보 방법
Case(incident) 엔터티의 'Is Escalated'(isescalated) 필드에 해당합니다.
예시
truefalse
|
|||
|
재작업 여부
IsRework
|
케이스에 재작업 활동이 있었는지 나타내는 계산 플래그입니다. | ||
|
설명
이 불리언 플래그는 '고객에게 정보 요청' 활동이 여러 번 발생하거나 해결 후 '케이스 재활성화' 활동이 발생하는 등 재작업이 반복된 케이스를 식별합니다. 비효율이나 최초 해결 실패를 나타내는 활동 순서가 있는지 분석해 계산합니다. 재작업 및 반복 문의 분석 대시보드에 활용되는 속성입니다.
중요한 이유
프로세스 비효율을 수치화하고 구분하여, 반복 작업과 불필요한 업무의 근본 원인에 집중할 수 있습니다.
확보 방법
process mining 분석을 사용해 특정 활동 순서(예: 해결 -> 재활성화)나 케이스 내 반복 활동을 감지하여 계산합니다.
예시
truefalse
|
|||
|
지식 문서 ID
KnowledgeArticleId
|
서비스 요청에 연결된 지식 베이스 문서의 식별자입니다. | ||
|
설명
이 속성에는 서비스 요청을 해결하는 과정에서 사용하거나 연결한 지식 문서의 ID가 저장됩니다. 상담원이 고객 문제를 해결할 때 지식 베이스를 얼마나 효과적으로 활용하는지 직접 확인할 수 있습니다. 이 데이터는 지식 문서 활용 대시보드와 관련 KPI를 구성하고, 지식 베이스의 유용성과 완성도를 평가하는 데 중요합니다.
중요한 이유
지식 베이스 사용 현황을 추적해 상담원이 제공된 리소스를 활용하여 문제를 더 빠르고 일관되게 해결하는지 파악합니다.
확보 방법
Case(incident) 엔터티와 Knowledge Article(knowledgearticle) 엔터티 간의 관계에서 확인할 수 있습니다.
예시
KA-01337KA-02048
|
|||
|
최초 접촉 해결 여부
IsFirstContactResolution
|
최초 접촉에서 요청이 해결되었는지 나타내는 플래그입니다. | ||
|
설명
이 계산 속성은 고객의 후속 문의나 상담원 재배정이 필요한 지연 없이 해결된 서비스 요청을 식별합니다. 정확한 판정 기준을 정하기는 복잡할 수 있지만, 일반적으로 처리 시간이 짧고 최초 응대 후 케이스 재개나 고객 문의 활동이 없는지 확인합니다. 최초 접촉 해결률 KPI의 기준이 됩니다.
중요한 이유
문제를 신속하고 완전하게 해결하는 역량을 보여주므로 서비스 효율성과 고객 만족도를 측정하는 중요한 지표입니다.
확보 방법
각 케이스의 이벤트 로그에서 활동 순서와 시점을 기준으로 계산합니다.
예시
truefalse
|
|||
고객 서비스 활동
| 활동 | 설명 | ||
|---|---|---|---|
|
SLA 타이머 시작
|
사례의 서비스 수준 계약(SLA) 타이머가 활성화되어 '최초 응답 기한'이나 '해결 기한'과 같은 서비스 지표를 측정하기 시작했음을 나타냅니다. Dynamics 365 SLA 엔진에서 명시적으로 관리하는 이벤트입니다. | ||
|
중요한 이유
이 활동은 SLA 준수 여부를 모니터링하고 서비스 약속의 측정이 시작되는 시점을 파악하는 데 중요합니다. 서비스 목표 달성 여부를 직접 분석할 수 있습니다.
확보 방법
'Incident' 엔터티와 연결된 'SLA KPI Instance' 엔터티에 기록됩니다. 해당 SLA KPI Instance 레코드의 'createdon' 타임스탬프가 시작 시점을 나타냅니다.
기록
사례와 연결된 'SLA KPI Instance' 레코드의 생성 타임스탬프를 사용합니다.
이벤트 유형
explicit
|
|||
|
사례 배정
|
사례를 처리할 특정 큐나 사용자에게 배정하는 활동입니다. 시스템은 사례 소유자 변경을 명시적으로 기록하며, 감사 로그에서 확인할 수 있습니다. | ||
|
중요한 이유
배정 내역을 추적하면 업무량 배분을 분석하고 배정 과정의 지연을 찾아 라우팅 효율을 파악할 수 있습니다. 사례가 적합한 팀이나 담당자에게 얼마나 빠르게 전달되는지 확인하는 데도 도움이 됩니다.
확보 방법
'Incident' 엔터티의 'ownerid' 필드 변경을 추적해 기록합니다. 변경 타임스탬프는 감사 내역 로그에서 확인할 수 있습니다.
기록
감사 로그에서 'ownerid' 필드의 타임스탬프가 포함된 변경 내역을 추출합니다.
이벤트 유형
explicit
|
|||
|
사례 생성
|
이 활동은 시스템에 새 사례 레코드가 생성되는 시점으로, 고객 서비스 프로세스의 시작을 나타냅니다. 'Incident' 엔터티 레코드를 처음 저장할 때 타임스탬프와 함께 명시적으로 기록됩니다. | ||
|
중요한 이유
주요 시작 이벤트인 이 활동은 사례의 전체 처리 기간을 계산하고 사례량 추이를 파악하는 데 필요합니다. 이후 모든 프로세스 분석의 기준점이 됩니다.
확보 방법
새 레코드마다 'Incident'(사례) 엔터티의 'createdon' 타임스탬프에서 이 이벤트를 가져옵니다.
기록
Incident 레코드의 'createdon' 타임스탬프를 사용합니다.
이벤트 유형
explicit
|
|||
|
사례 에스컬레이션
|
사례를 상위 지원 단계나 다른 팀으로 공식 이관하는 활동입니다. 지정된 에스컬레이션 큐나 사용자에게 사례를 재배정하는 명시적인 사용자 작업일 수 있습니다. | ||
|
중요한 이유
'내부 에스컬레이션율' KPI를 모니터링하고 1차 지원에서 해결하지 못한 문제의 근본 원인을 찾는 데 중요합니다. 프로세스의 취약점과 교육이 필요한 부분을 파악할 수 있습니다.
확보 방법
'ownerid' 필드가 지정된 에스컬레이션 큐나 팀으로 변경된 기록을 근거로 추정합니다. 사례를 에스컬레이션 상태로 표시하는 사용자 지정 작업을 통해서도 확인할 수 있습니다.
기록
'ownerid'가 지정된 에스컬레이션 큐로 변경된 타임스탬프를 확인합니다.
이벤트 유형
inferred
|
|||
|
사례 종료
|
사례 레코드를 최종적으로 관리 종료하는 단계입니다. 해결과 동시에 진행되거나 나중에 처리될 수 있습니다. 사례 상태가 '종료됨'으로 변경된 기록으로 확인합니다. | ||
|
중요한 이유
시스템에서 프로세스가 완전히 끝나는 시점을 나타냅니다. '해결됨'에서 '종료됨'까지 걸린 시간을 보면 관리 업무 부담이나 레코드 최종 확정 지연을 파악할 수 있습니다.
확보 방법
'Incident' 엔터티의 'statecode' 필드가 '취소됨'(2) 또는 사용자 지정 종료 상태로 변경된 기록으로 확인합니다. 타임스탬프는 감사 내역에서 확인할 수 있습니다.
기록
'statecode'가 최종 종료 상태(예: 취소됨/종료됨)로 변경된 타임스탬프를 추적합니다.
이벤트 유형
explicit
|
|||
|
사례 해결
|
상담원이 고객 문제를 해결했다고 판단한 시점을 나타내는 주요 단계입니다. Dynamics 365에서 명시적으로 수행하는 작업으로, 사례와 연결된 'Case Resolution' 활동 레코드가 생성됩니다. | ||
|
중요한 이유
주요 성공 종료 이벤트인 이 활동은 해결 시간과 성공률을 계산하는 데 필요합니다. 거의 모든 고객 서비스 KPI에 포함되는 항목입니다.
확보 방법
'Resolution'(Case Resolution) 활동 레코드가 생성될 때 발생하는 이벤트입니다. 해당 레코드의 'actualend' 타임스탬프가 해결 시점을 나타냅니다.
기록
연결된 'Resolution' 활동 레코드의 'actualend' 또는 'createdon' 타임스탬프를 사용합니다.
이벤트 유형
explicit
|
|||
|
고객에게 정보 요청
|
상담원이 처리를 계속하기 위해 고객에게 추가 정보를 요청하는 시점입니다. 사례 상태가 '대기'로 변경되거나 사례 타임라인에서 발신 이메일이 전송된 기록으로 추정할 수 있습니다. | ||
|
중요한 이유
고객으로 인한 지연을 측정하고 '고객 정보 대기 시간' KPI를 파악하는 데 중요합니다. 외부 응답을 기다리는 데 걸린 프로세스 시간을 분리해 확인할 수 있습니다.
확보 방법
'Incident' 엔터티의 'statuscode' 필드가 '보류 중'으로 변경되고 사유가 '고객 대기'로 지정된 경우 등을 근거로 추정할 수 있습니다. 상태 변경 타임스탬프를 사용합니다.
기록
지정된 '고객 응답 대기' 상태로 변경된 statuscode의 타임스탬프를 추적합니다.
이벤트 유형
inferred
|
|||
|
고객에게 해결책 제안
|
상담원이 해결책을 마련해 고객에게 전달했음을 나타냅니다. 사례 타임라인에서 발신 이메일이 전송되었거나 상태가 '고객 확인 대기'로 변경된 기록을 근거로 추정하는 경우가 많습니다. | ||
|
중요한 이유
이 단계는 조사에서 해결로 넘어가는 시점을 나타냅니다. 해결책을 제안한 시점부터 고객이 확인할 때까지 걸린 시간을 분석하면 고객 응답 지연이나 제안한 해결책의 문제를 파악할 수 있습니다.
확보 방법
사례와 연결된 발신 'Email' 활동 레코드의 타임스탬프나 해결 전 단계로의 statuscode 변경을 근거로 추정할 수 있습니다.
기록
발신 이메일 활동의 타임스탬프나 상태가 '해결책 제안'으로 변경된 시점을 사용합니다.
이벤트 유형
inferred
|
|||
|
만족도 설문 발송
|
고객 만족도 설문을 발송한 시점을 나타냅니다. 일반적으로 사례 해결 후 자동으로 발송되며, 발신 이메일이나 Customer Voice 설문 활동으로 기록됩니다. | ||
|
중요한 이유
이 활동은 운영 프로세스와 고객 경험 성과를 연결합니다. 사례가 거친 프로세스 경로와 함께 만족도 점수를 분석할 수 있습니다.
확보 방법
설문 링크가 포함된 발신 'Email' 활동 레코드나 사례와 연결된 'Customer Voice survey invite' 활동 레코드의 생성을 근거로 추정합니다.
기록
설문 관련 활동 레코드의 생성 타임스탬프를 사용합니다.
이벤트 유형
inferred
|
|||
|
사례 분류 변경
|
상담원이 사례를 처음 생성한 후 범주나 제목을 수정할 때 발생하는 이벤트입니다. 시스템의 감사 기능으로 변경 내역을 명시적으로 추적합니다. | ||
|
중요한 이유
'서비스 요청 재분류율' KPI를 측정하려면 재분류 내역을 추적해야 합니다. 재분류가 잦으면 초기 분류에 문제가 있어 잘못된 라우팅과 지연이 발생할 수 있습니다.
확보 방법
'Incident' 엔터티의 감사 내역에서 'subjectid' 필드나 사용자 지정 분류 필드의 변경을 추적해 가져옵니다.
기록
감사 로그에서 'subjectid' 필드의 타임스탬프가 포함된 변경 내역을 추출합니다.
이벤트 유형
explicit
|
|||
|
사례 재활성화
|
해결된 사례가 자동 또는 수동으로 다시 열릴 때 발생합니다. 대개 고객이 답변을 보내거나 문제가 해결되지 않았다고 알린 경우입니다. 시스템에서 사례 상태를 '해결됨'에서 '활성'으로 변경하는 표준 동작입니다. | ||
|
중요한 이유
이 활동은 재작업을 파악하고 '최초 문의 해결률'을 분석하는 데 중요합니다. 재활성화가 잦으면 처음 제시한 해결책이 불완전하거나 효과적이지 않을 수 있습니다.
확보 방법
'Incident' 엔터티의 'statecode' 필드가 '해결됨'(1)에서 '활성'(0)으로 변경된 기록으로 확인합니다. 변경 타임스탬프는 감사 내역에 저장됩니다.
기록
감사 로그에서 'statecode'가 해결됨에서 활성으로 변경된 타임스탬프를 추적합니다.
이벤트 유형
explicit
|
|||
|
상담원의 문제 조사
|
상담원이 고객 문제를 파악하고 원인을 진단하는 활동입니다. 사례에 Knowledge Article을 연결한 기록을 근거로 조사가 이루어진 것으로 추정하는 활동입니다. | ||
|
중요한 이유
이 활동을 추적하면 지식 리소스의 활용도와 해결 시간에 미치는 영향을 측정할 수 있습니다. 상담원이 제공된 도구를 활용해 문제를 효율적으로 해결하는지 파악할 수 있습니다.
확보 방법
Knowledge Article과 사례를 연결하는 'IncidentKnowledgeBaseRecord' 엔터티 레코드가 생성된 시점으로 추정합니다. 해당 레코드의 생성 타임스탬프를 사용합니다.
기록
Knowledge Article이 Incident와 연결된 타임스탬프를 사용합니다.
이벤트 유형
inferred
|
|||
|
상담원이 큐 항목 선택
|
상담원이 공유 큐에서 사례를 직접 가져와 처리를 시작할 때 발생하는 이벤트입니다. 시스템이 사례를 큐에 배정하는 것과는 별개로, 사용자가 직접 수행하는 작업입니다. | ||
|
중요한 이유
이 활동을 통해 상담원이 업무를 시작하기 전 사례가 큐에서 대기한 시간을 측정할 수 있습니다. 큐의 병목을 찾고 상담원의 선제적인 대응 여부를 파악하는 데 유용합니다.
확보 방법
사례와 연결된 'QueueItem' 엔터티의 'workedbyid' 필드를 사용자가 업데이트하거나, 사례 소유자가 큐에서 사용자로 변경될 때 추적합니다.
기록
'QueueItem'의 'workedbyid' 필드에 값이 입력된 시점을 확인합니다.
이벤트 유형
explicit
|
|||
데이터 추출 가이드
시작할 준비가 되셨나요?
이 데이터 템플릿으로 process mining을 시작하고 고객 서비스 운영의 효율을 높이세요. 지금 워크플로를 최적화해 고객 경험을 개선할 수 있습니다.
고객 서비스 개선: 최초 문의 해결률을 높이고 비용을 절감하세요
병목을 찾아 최초 문의 해결률을 80%까지 높이고 고객 만족도를 개선하세요.
신용카드가 필요하지 않습니다. 몇 분이면 설정할 수 있습니다.