고객 서비스 데이터 템플릿
고객 서비스 데이터 템플릿
- 수집 권장 속성
- 추적할 주요 활동
- 데이터 추출 안내
고객 서비스 속성
| 이름 | 설명 | ||
|---|---|---|---|
|
서비스 요청
ServiceRequest
|
각 고객 서비스 요청, 케이스 또는 티켓을 식별하는 고유 ID입니다. | ||
|
설명
서비스 요청은 단일 고객 문제와 관련된 모든 활동 및 이벤트를 생성부터 종료까지 연결하는 기본 케이스 식별자입니다. 고객과의 상호작용이 처음부터 끝날 때까지 이어지는 흐름을 추적하는 기준이 됩니다. process mining에서는 이 속성을 바탕으로 프로세스 흐름을 재구성합니다. 고유한 서비스 요청 값 하나가 프로세스 인스턴스 하나를 나타내므로 케이스별 처리 시간, 경로, 편차를 분석할 수 있습니다. 최초 문의부터 최종 해결 및 종료까지 모든 단계가 동일한 고객 문의에 연결되도록 합니다.
중요한 이유
각 고객 서비스 상호작용의 전체 생애 주기를 분석할 수 있도록 모든 프로세스 단계를 연결하는 필수 케이스 ID입니다.
확보 방법
일반적으로 ServiceNow CSM의 'sn_customerservice_case' 테이블에 있는 'number' 필드입니다.
예시
CS0010001CS0010045CS0010112
|
|||
|
이벤트 시간
EventTime
|
특정 활동이나 이벤트가 발생한 시점을 나타내는 정확한 타임스탬프입니다. | ||
|
설명
이벤트 시간은 활동이 수행된 날짜와 시간을 기록합니다. 이벤트를 시간순으로 정렬하고 프로세스의 각 단계 사이에 걸린 시간을 계산하는 데 필요한 속성입니다. process mining 분석에서는 처리 시간, 대기 시간, 작업 소요 시간을 비롯한 모든 시간 기반 지표를 계산하는 데 사용합니다. 활동 전에 지연이 길게 발생하는 구간을 찾아 병목을 파악하고 Service Level Agreement(SLA) 기준에 따른 성과를 측정할 수 있습니다. 신뢰할 수 있는 분석을 위해서는 타임스탬프가 정확하고 일관되어야 합니다.
중요한 이유
이 타임스탬프는 이벤트 순서를 정확히 정하고 처리 시간과 병목 등 모든 성과 지표를 계산하는 데 필요합니다.
확보 방법
일반적으로 ServiceNow 감사 및 이력 테이블(예: 'sys_audit')의 'sys_created_on' 필드에 해당합니다.
예시
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:05:11Z
|
|||
|
활동 이름
ActivityName
|
서비스 요청 생애 주기에서 발생한 특정 이벤트 또는 작업의 이름입니다. | ||
|
설명
활동 이름은 '서비스 요청 생성', '상담원에게 요청 배정', '해결 방안 제안'과 같이 고객 서비스 프로세스의 단계를 나타냅니다. 시스템 로그나 테이블 업데이트에서 활동을 추출해 서비스 요청별 이벤트를 시간순으로 구성합니다. 이 속성은 프로세스 맵을 시각화하고 병목을 찾으며 업무 흐름을 파악하는 데 중요합니다. 활동의 순서와 빈도를 분석하면 일반적인 프로세스 경로와 편차, 재작업 또는 비효율이 발생하는 영역을 찾을 수 있습니다. 활동을 얼마나 세분화해 정의하는지에 따라 프로세스 모델에서 얻을 수 있는 인사이트의 깊이가 달라집니다.
중요한 이유
프로세스 맵의 기본 구성 요소로, 순서와 소요 시간을 분석할 구체적인 단계와 작업을 정의합니다.
확보 방법
시스템 감사 테이블(예: 'sys_audit')에서 가져오거나 'sn_customerservice_case' 테이블의 상태 변경 및 주요 필드 업데이트를 추적해 도출하는 개념적 속성입니다.
예시
서비스 요청 생성상담원에게 요청 배정고객에게 정보 요청서비스 요청 해결
|
|||
|
SLA 위반 여부
IsSlaBreached
|
서비스 요청이 정해진 서비스 수준 계약(SLA) 목표를 초과했는지 나타내는 불리언 플래그입니다. | ||
|
설명
이 계산된 속성은 서비스 요청이 합의된 시간 내에 해결되었는지 나타냅니다. 일반적으로 해결 시간이 SLA 목표를 초과하면 'True', 그렇지 않으면 'False'로 표시됩니다. 각 케이스의 SLA 성과를 예 또는 아니요로 명확하게 구분할 수 있습니다. 이 속성은 'SLA 준수 및 위반 추이' 대시보드와 'SLA 준수율' KPI에 필요합니다. 위반된 케이스를 바로 필터링하고 집계할 수 있어 어떤 요청 유형, 우선순위 또는 팀에서 SLA 위반이 많이 발생하는지 쉽게 파악할 수 있습니다.
중요한 이유
케이스가 기한을 지켰는지 명확하게 확인할 수 있어 SLA 규정 준수 측정과 보고의 기초가 됩니다.
확보 방법
'task_sla' 테이블의 'made_sla' 필드를 기준으로 계산하거나, 실제 해결 시간과 계획된 해결 시간을 비교해 산출합니다.
예시
truefalse
|
|||
|
배정 그룹
AssignmentGroup
|
서비스 요청을 담당하는 팀 또는 부서입니다. | ||
|
설명
배정 그룹은 서비스 요청이 할당된 대기열 또는 팀을 나타냅니다. 문제 유형에 따라 1차 지원 데스크, 전문 기술 팀, 청구 부서 등으로 요청이 전달될 수 있습니다. 이 속성은 부서 간 인계를 분석하고 팀 단위의 병목을 찾는 데 중요합니다. 기능별 조직 사이에서 업무가 어떻게 흐르는지 시각화하고, 업무가 과중하거나 추가 교육이 필요한 그룹을 파악할 수 있습니다. '상담원 인계 및 재배정' 및 '프로세스 흐름' 대시보드 분석에도 활용됩니다.
중요한 이유
업무 담당 팀을 식별해 팀 성과와 업무량, 부서 간 인계를 분석할 수 있습니다.
확보 방법
'sn_customerservice_case' 테이블의 'assignment_group' 필드에 해당합니다.
예시
서비스 데스크청구 문의2차 기술 지원
|
|||
|
배정된 상담원
AssignedAgent
|
현재 서비스 요청을 처리하도록 배정된 서비스 상담원입니다. | ||
|
설명
이 속성은 특정 시점에 서비스 요청을 담당하는 사용자를 나타냅니다. 케이스가 상담원이나 전문가 사이에서 이관되면서 담당자가 바뀌는 경우가 많습니다. 배정된 상담원을 분석하면 업무량 분배, 상담원 성과, 인계 상황을 파악할 수 있습니다. 어떤 상담원이 복잡한 케이스를 주로 처리하는지, 케이스가 얼마나 자주 재배정되는지, 특정 상담원이 긴 해결 시간이나 높은 고객 만족도와 연관되는지 확인할 수 있습니다. '상담원 인계 및 재배정' 대시보드에 필요한 속성입니다.
중요한 이유
상담원별 담당 업무를 추적해 업무량과 성과, 재배정 빈도를 분석할 수 있습니다. 재배정이 잦으면 프로세스에 마찰이 있음을 시사할 수 있습니다.
확보 방법
'sn_customerservice_case' 테이블의 'assigned_to' 필드에 해당합니다.
예시
Beth AnglinDavid LooAbel Tuter
|
|||
|
범주
Category
|
'청구' 또는 '기술 문제'와 같이 서비스 요청을 대표하는 분류입니다. | ||
|
설명
범주는 고객 문의나 문제의 성격에 따라 서비스 요청을 상위 유형으로 분류합니다. 일반적으로 요청을 생성할 때 분류하며, 적절한 배정 그룹으로 전달하는 데 활용합니다. 이 속성은 프로세스 분석을 유형별로 나누는 데 필요합니다. 범주를 기준으로 필터링하면 요청 유형별 프로세스 흐름을 비교할 수 있습니다. 예를 들어 '청구' 문제의 해결 절차는 '기술 문제'와 크게 다를 수 있습니다. 대부분의 대시보드에서 데이터를 구분해 보는 데 사용하는 주요 속성입니다.
중요한 이유
요청 유형별로 분석을 나누어 특정 범주에서 지연, 에스컬레이션 또는 SLA 미준수가 더 자주 발생하는지 확인할 수 있습니다.
확보 방법
'sn_customerservice_case' 테이블의 'category' 필드에 해당합니다.
예시
문의 / 도움 요청주문제품 문제청구
|
|||
|
상태
State
|
생애 주기에서 서비스 요청이 현재 어떤 상태인지 나타냅니다. | ||
|
설명
상태 속성은 '신규', '진행 중', '정보 대기', '해결됨', '종료됨'과 같이 특정 시점의 서비스 요청 처리 상태를 나타냅니다. 이 필드의 변경 사항을 프로세스 모델의 활동 정의에 사용하는 경우가 많습니다. 상태를 분석하면 케이스가 프로세스의 어느 단계에 있는지 개괄적으로 파악할 수 있습니다. 지연의 주요 원인일 수 있는 '정보 대기' 상태에 케이스가 얼마나 오래 머무는지 확인할 수 있습니다. 또한 '해결부터 종료까지 걸린 시간'과 같은 주요 KPI의 시작점과 종료점을 정의하는 데도 도움이 됩니다.
중요한 이유
요청의 현재 상태를 보여주므로 '보류' 또는 '정보 대기'처럼 생산적인 업무가 진행되지 않는 상태에 머문 시간을 파악할 수 있습니다.
확보 방법
'sn_customerservice_case' 테이블의 'state' 필드에 해당합니다.
예시
신규진행 중사용자 정보 대기해결됨종료됨
|
|||
|
우선순위
Priority
|
서비스 요청의 긴급도에 영향을 미치는 우선순위입니다. | ||
|
설명
우선순위는 서비스 요청의 중요도와 처리 시급성을 나타냅니다. 일반적으로 요청이 고객에게 미치는 영향과 긴급도를 함께 고려해 결정합니다. 값은 보통 '긴급'부터 '낮음'까지입니다. process mining에서는 우선순위를 기준으로 데이터를 필터링하고 비교할 수 있습니다. 우선순위가 높은 요청이 낮은 요청보다 실제로 더 빨리 처리되는지, 특정 우선순위에서 SLA 미준수가 더 자주 발생하는지 분석할 수 있습니다. '서비스 요청 전체 처리 시간' 대시보드에 필요한 속성입니다.
중요한 이유
긴급도에 따라 서비스 요청을 구분해 긴급한 문제가 일반 문제보다 빠르게 처리되는지 확인할 수 있습니다.
확보 방법
'sn_customerservice_case' 테이블의 'priority' 필드에 해당합니다.
예시
1 - 긴급2 - 높음3 - 보통4 - 낮음
|
|||
|
고객
Customer
|
서비스 요청을 접수한 고객 또는 회사의 이름이나 식별자입니다. | ||
|
설명
이 속성은 서비스 요청의 대상인 개인 또는 조직을 식별하고 각 케이스의 고객 정보를 제공합니다. 고객 속성을 사용하면 고객 관점에서 서비스 프로세스를 분석할 수 있습니다. 특정 고객이 더 많은 문제를 겪거나 더 오래 기다리는지 확인하고, 고객 세그먼트나 가치와 같은 다른 데이터와 결합해 프로세스 개선의 우선순위를 정할 수 있습니다. 예를 들어 가치가 높은 고객이 더 빠른 서비스를 받는지 확인할 수 있습니다.
중요한 이유
프로세스를 특정 고객과 연결해 주요 고객사나 고객 세그먼트별 서비스 수준과 문제 발생 빈도를 분석할 수 있습니다.
확보 방법
사용자 또는 회사 테이블을 참조하는 'sn_customerservice_case' 테이블의 'caller_id', 'opened_for' 또는 'account' 필드일 수 있습니다.
예시
John SmithACME CorporationGlobal Tech Inc.
|
|||
|
원본 시스템
SourceSystem
|
데이터를 추출한 시스템입니다. | ||
|
설명
이 속성은 데이터의 출처를 나타내며, 여러 시스템의 정보를 통합하는 환경에서 특히 중요합니다. 이 프로세스 보기에서는 값이 항상 'ServiceNow CSM'으로 설정됩니다. 분석 시 데이터 거버넌스와 문제 해결에 도움이 됩니다. 원본 시스템이 여러 개인 경우 특정 시스템에서 프로세스가 어떻게 운영되는지 확인하거나 시스템별 프로세스 차이를 비교할 수 있습니다.
중요한 이유
데이터 출처를 명확히 해 여러 시스템을 사용하는 환경에서 이해를 돕고 데이터 거버넌스를 지원합니다.
확보 방법
데이터 변환 과정에서 데이터셋의 출처를 표시하기 위해 추가하는 고정 값입니다.
예시
ServiceNow CSM
|
|||
|
재개 횟수
ReopenCount
|
해결된 서비스 요청을 고객이 다시 연 횟수입니다. | ||
|
설명
이 카운터는 케이스 상태가 '해결됨' 또는 '종료됨'에서 '진행 중' 또는 '열림'으로 돌아간 횟수를 추적합니다. 케이스가 다시 열렸다면 처음 제시한 해결 방안이 효과가 없거나 충분하지 않았을 수 있습니다. 이 속성은 재작업과 최초 해결 품질을 보여주는 강력한 지표입니다. 재개 횟수가 많으면 상담원이 티켓을 너무 일찍 종료했거나 고객의 근본적인 문제를 충분히 해결하지 못하는 등 해결 절차에 문제가 있음을 나타냅니다. 제안된 해결 방안의 효과를 파악하는 데도 사용됩니다.
중요한 이유
해결 실패와 재작업을 나타냅니다. 케이스가 자주 재개되면 해결 절차의 품질이 낮고 고객 불만이 커질 수 있습니다.
확보 방법
'sn_customerservice_case' 테이블 또는 관련 테이블의 'reopen_count' 필드에 기록하는 경우가 많습니다.
예시
012
|
|||
|
재배정 횟수
ReassignmentCount
|
서비스 요청이 다른 상담원이나 그룹으로 재배정된 총횟수입니다. | ||
|
설명
'assigned_to' 또는 'assignment_group' 필드가 바뀔 때마다 증가하는 카운터입니다. 케이스가 내부적으로 이관된 횟수를 간단히 보여줍니다. 재배정 횟수는 프로세스의 마찰을 직접 보여주는 지표이며, '상담원 인계 및 재배정' 대시보드와 '요청당 평균 상담원 인계 횟수' KPI에 사용됩니다. 재배정 횟수가 많으면 최초 전달이 적절하지 않았거나 상담원의 기술이 부족하거나 케이스를 분류하기 어려운 문제일 수 있습니다. 이러한 요인은 모두 해결 시간을 늘립니다.
중요한 이유
인계 횟수를 세어 프로세스의 비효율을 직접 측정합니다. 횟수가 많으면 해결 시간이 길어지고 고객 불만이 커지는 경우가 많습니다.
확보 방법
'sn_customerservice_case' 테이블이 확장하는 'task' 테이블의 표준 지표 필드인 'reassignment_count'입니다.
예시
0135
|
|||
|
재작업 여부
IsRework
|
케이스 재개 또는 조사 반복과 같은 상당한 재작업이 발생했는지 나타내는 불리언 플래그입니다. | ||
|
설명
이 계산된 속성은 비효율적이거나 반복적인 패턴을 보이는 케이스를 표시합니다. '서비스 요청 재개' 이벤트가 발생하거나, '상담원 조사 시작' 후 '해결책 제안'으로 이어지는 주요 활동 순서가 같은 케이스에서 여러 번 발생하면 플래그가 설정될 수 있습니다. 이 플래그를 사용하면 문제가 있는 케이스를 빠르게 찾고 프로세스 전반의 재작업 수준을 측정할 수 있습니다. '재작업 및 반복 집중 구간' 대시보드와 '재작업률' KPI를 지원하므로, 분석가는 반복 패턴을 일일이 찾지 않고도 비효율의 원인에 집중할 수 있습니다.
중요한 이유
반복되는 루프나 재개 이벤트가 있는 케이스를 표시해 프로세스 비효율을 측정하고 재작업을 쉽게 파악할 수 있습니다.
확보 방법
계산된 속성입니다. 데이터 변환 과정에서 'ReopenCount'가 0보다 크거나 활동이 반복되는 등의 재작업 패턴을 감지하는 비즈니스 로직을 적용해 산출합니다.
예시
truefalse
|
|||
|
접수 채널
Channel
|
서비스 요청을 접수한 커뮤니케이션 채널입니다. | ||
|
설명
접수 채널은 고객이 요청을 제출한 방법을 나타냅니다. 예를 들어 '이메일', '전화', '웹 포털', '채팅' 등이 있습니다. 채널마다 프로세스 특성과 고객 기대가 크게 다를 수 있습니다. 채널별로 프로세스를 분석하면 각 커뮤니케이션 방식의 효과를 평가할 수 있습니다. 예를 들어 '전화'로 접수한 요청의 최초 문의 해결률이 더 높은지, '이메일' 요청의 처리 시간이 더 긴지 확인할 수 있습니다. '커뮤니케이션 채널 효과' 대시보드 분석에 활용됩니다.
중요한 이유
전화, 이메일, 웹 포털 등 고객 응대 채널별 효율과 결과를 파악할 수 있습니다.
확보 방법
일반적으로 'sn_customerservice_case' 테이블의 'contact_type' 필드에 해당합니다.
예시
전화이메일셀프서비스채팅
|
|||
|
최근 데이터 업데이트
LastDataUpdate
|
원본 시스템에서 데이터를 마지막으로 추출하거나 새로 고친 시점을 나타내는 타임스탬프입니다. | ||
|
설명
이 속성은 가장 최근에 데이터를 가져온 날짜와 시간을 기록합니다. 분석 대상 데이터의 최신성을 알려주므로 사용자는 거의 실시간 정보인지 과거 시점의 스냅샷인지 확인할 수 있습니다. 분석 중에는 데이터셋의 시간 범위를 파악하는 데 중요한 메타데이터입니다. 예를 들어 데이터가 지난 한 시간 또는 전날 기준으로 최신인지 확인해 대시보드와 KPI를 올바르게 해석할 수 있습니다.
중요한 이유
데이터의 최신성을 나타내며, process mining 인사이트의 관련성과 시의성을 판단하는 데 중요합니다.
확보 방법
데이터 추출, 변환, 적재(ETL) 과정에서 생성해 추가하는 타임스탬프입니다.
예시
2023-11-20T08:00:00Z
|
|||
|
최초 접촉 해결 여부
IsFirstContactResolution
|
요청이 담당 상담원에게 처음 배정된 뒤 이관이나 에스컬레이션 없이 해결되었는지 나타내는 불리언 플래그입니다. | ||
|
설명
이 계산된 속성은 최초 응대 중 또는 케이스를 처음 처리한 상담원이 서비스 요청을 해결했는지 확인합니다. 일반적으로 재배정 횟수('ReassignmentCount')가 0이고, '내부 에스컬레이션 발생' 활동이 없으며, 고객에게 추가 정보를 요청하지 않았는지 확인합니다. 이 속성은 고객 서비스의 주요 지표를 직접 측정하며 '최초 접촉 해결률' 대시보드와 KPI를 지원합니다. FCR 성과를 쉽게 측정하고, 채널이나 요청 범주 등 최초 접촉 해결에 영향을 주거나 방해하는 요인을 분석할 수 있습니다.
중요한 이유
최초 응대의 효율성을 직접 측정합니다. FCR이 높으면 운영 효율성과 고객 만족도도 높은 경향이 있습니다.
확보 방법
계산된 속성입니다. 'ReassignmentCount'가 0이고 에스컬레이션 활동이 없는 등의 규칙을 데이터 변환 과정에 적용해 산출합니다.
예시
truefalse
|
|||
|
해결 코드
ResolutionCode
|
서비스 요청의 최종 결과 또는 해결 방법을 나타내는 코드입니다. | ||
|
설명
해결 코드는 케이스를 해결할 때 상담원이 선택하는 구조화된 값입니다. '사용자 해결', '알려진 오류', '중복', '조치 불필요'와 같이 해결 방법을 구체적으로 나타냅니다. 이 속성은 근본 원인 분석에 유용합니다. 해결 코드별 빈도를 분석하면 반복되는 문제, 지식 격차, 제품 문제를 파악할 수 있습니다. 이 정보를 바탕으로 특정 유형의 서비스 요청을 줄이는 개선을 추진할 수 있습니다.
중요한 이유
서비스 요청의 결과를 파악해 근본 원인을 분석하고 반복되는 문제를 찾을 수 있습니다.
확보 방법
'sn_customerservice_case' 테이블의 'close_code' 또는 사용자 지정 해결 코드 필드에 해당합니다.
예시
해결됨(임시 방안)해결됨(영구 해결)미해결(고객 응답 없음)요청자가 종료 또는 해결
|
|||
고객 서비스 활동
| 활동 | 설명 | ||
|---|---|---|---|
|
내부 에스컬레이션 발생
|
서비스 요청 해결을 위해 상위 지원 조직이나 관리 부서로 공식 이관하는 것을 나타냅니다. 배정 그룹이 상위 지원 팀으로 바뀌거나 관련 플래그가 설정되는 시점으로 추정할 수 있습니다. | ||
|
중요한 이유
에스컬레이션을 추적하면 프로세스의 취약점, 일선 지원 조직의 지식 격차, 복잡한 케이스 유형을 파악할 수 있습니다. 이는 프로세스의 마찰과 고객 불만을 보여주는 주요 지표입니다.
확보 방법
감사 로그에서 'assignment_group'이 알려진 에스컬레이션 팀으로 바뀌거나 케이스 레코드의 'escalation' 필드가 변경되는지 확인해 추정할 수 있습니다.
기록
'escalation' 필드가 바뀌거나 'assignment_group'이 상위 지원 조직으로 변경되는지 확인합니다.
이벤트 유형
inferred
|
|||
|
상담원에게 요청 배정
|
서비스 요청을 조사하고 해결할 특정 상담원에게 배정할 때 발생하는 활동입니다. 사례 레코드의 assigned_to 필드 변경을 확인해 기록합니다. | ||
|
중요한 이유
최초 응답 시간과 상담원별 업무량을 측정하는 데 중요한 단계입니다. 이 필드의 재배정을 추적하면 프로세스 비효율과 상담원 가용성의 잠재적 병목을 파악할 수 있습니다.
확보 방법
sn_customerservice_case 테이블의 감사 이력(sys_audit)을 바탕으로 추정하며, assigned_to 필드에 값이 입력되거나 변경된 시점을 추적합니다.
기록
사례 감사 로그에서 'assigned_to' 필드의 값 변경을 감지합니다.
이벤트 유형
inferred
|
|||
|
서비스 요청 생성
|
새 사례가 시스템에 정식으로 등록되면 고객 서비스 프로세스가 시작됩니다. sn_customerservice_case 테이블에 새 레코드가 삽입될 때 이 이벤트를 명시적으로 기록합니다. | ||
|
중요한 이유
모든 사례의 시작점인 이 활동은 전체 처리 시간을 계산하고 요청 접수량을 분석하는 데 필요합니다. 이후 프로세스와 SLA 타이머를 시작하는 기준이 됩니다.
확보 방법
이 이벤트는 sn_customerservice_case 테이블에 레코드가 생성된 것을 나타냅니다. 타임스탬프는 sys_created_on 필드에서 가져옵니다.
기록
sn_customerservice_case 테이블의 레코드 생성 타임스탬프(sys_created_on)입니다.
이벤트 유형
explicit
|
|||
|
서비스 요청 종료
|
서비스 요청 레코드를 공식적으로 종료하는 마지막 활동입니다. 해결 후 확인 기간을 거쳐 종료하는 경우가 많습니다. 케이스 상태가 '종료됨'으로 바뀌고 closed_at 타임스탬프가 설정될 때 기록됩니다. | ||
|
중요한 이유
프로세스의 최종 종료 지점으로, 케이스 전체 생애 주기를 계산하는 데 필요합니다. '해결됨'부터 '종료됨'까지 걸린 시간을 분석하면 행정 업무로 인한 추가 작업이나 지연을 확인할 수 있습니다.
확보 방법
sn_customerservice_case 테이블의 state 필드가 '종료됨'으로 설정된 감사 이력을 기준으로 추정합니다. 같은 시점에 closed_at 필드가 입력됩니다.
기록
'종료됨'으로 바뀌는 'state' 변경을 감지하고 해당 타임스탬프를 사용합니다.
이벤트 유형
inferred
|
|||
|
서비스 요청 해결
|
서비스 상담원이 업무를 마치고 문제가 해결된 것으로 처리했음을 나타내는 주요 단계입니다. 케이스 상태가 '해결됨'으로 바뀌고 resolved_at 타임스탬프가 입력될 때 기록됩니다. | ||
|
중요한 이유
이 활동은 실제 해결 절차가 끝나는 시점으로, 해결 소요 시간과 SLA 준수 여부를 계산하는 데 필요합니다. 여러 효율성 KPI의 주요 종료 지점으로 사용됩니다.
확보 방법
sn_customerservice_case 테이블의 state 필드가 '해결됨'으로 설정된 감사 이력을 기준으로 추정합니다. 일반적으로 같은 시점에 resolved_at 필드도 입력됩니다.
기록
'해결됨'으로 바뀌는 'state' 변경을 감지하고 해당 타임스탬프를 사용합니다.
이벤트 유형
inferred
|
|||
|
SLA 미준수
|
해결 소요 시간 등 정해진 Service Level Agreement를 서비스 요청이 충족하지 못한 시점을 나타냅니다. 해결 시간과 SLA 예정 종료 시간을 비교해 산출하는 이벤트입니다. | ||
|
중요한 이유
SLA 미준수 여부를 파악하는 일은 규정 준수 모니터링과 성과 관리에 필수적입니다. 이 이벤트를 통해 어떤 프로세스 단계나 케이스 유형이 SLA 위반에 가장 크게 영향을 주는지 확인할 수 있습니다.
확보 방법
해당 케이스와 관련된 task_sla 테이블 레코드를 분석해 산출합니다. has_breached 필드가 true이거나 actual_elapsed_time이 planned_duration을 초과하면 SLA 미준수로 판단합니다.
기록
연결된 task_sla 레코드의 'has_breached' 플래그를 확인합니다.
이벤트 유형
calculated
|
|||
|
고객 설문 발송
|
케이스 해결 후 고객 만족도 설문을 발송하는 것을 나타냅니다. 일반적으로 설문 인스턴스 레코드가 생성되어 케이스와 연결될 때 기록됩니다. | ||
|
중요한 이유
이 활동을 통해 프로세스 실행 양상과 고객 피드백을 연관 지어 분석할 수 있습니다. 피드백 절차의 효과를 분석하려면 설문 발송 시점과 발송 여부를 파악해야 합니다.
확보 방법
이는 설문 전용 테이블(예: asmt_assessment_instance)에 기록되는 명시적 이벤트이며, 해당 테이블에는 원본 케이스 레코드에 대한 참조가 포함됩니다.
기록
케이스와 연결된 'asmt_assessment_instance' 테이블에 레코드가 생성됩니다.
이벤트 유형
explicit
|
|||
|
고객 정보 수신
|
고객이 요청받은 정보를 제공해 상담원이 업무를 재개할 수 있는 시점을 나타냅니다. 케이스 상태가 '사용자 정보 대기'에서 진행 상태로 바뀌는 시점으로 추정합니다. | ||
|
중요한 이유
이 이벤트는 고객 대기 시간을 끝내고 고객 응답 시간을 정확하게 측정할 수 있게 합니다. 지연이 가장 긴 케이스 유형이나 고객을 파악하는 데 도움이 됩니다.
확보 방법
sn_customerservice_case 테이블의 감사 이력에서 상태가 '정보 대기'에서 '처리 중'과 같은 진행 상태로 바뀌는 시점을 기준으로 추정합니다.
기록
'state' 필드가 '고객 응답 대기' 값에서 진행 상태 값으로 바뀌는지 확인합니다.
이벤트 유형
inferred
|
|||
|
고객에게 정보 요청
|
상담원이 요청 처리를 위해 고객에게 추가 정보가 필요해 케이스를 대기 상태로 전환할 때 발생합니다. 상태가 '사용자 정보 대기' 또는 '보류'와 같은 값으로 바뀌는 시점으로 추정합니다. | ||
|
중요한 이유
'고객 정보 대기 시간' 분석에 중요한 활동입니다. 외부 요인으로 발생한 지연을 따로 구분해 내부 처리 시간과 분리할 수 있습니다.
확보 방법
sn_customerservice_case 테이블의 감사 이력에서 state 필드가 고객의 입력을 기다리는 상태를 나타내는 값(예: '정보 대기')으로 바뀌는 시점을 기준으로 추정합니다.
기록
'state' 필드가 지정된 '고객 응답 대기' 값으로 바뀌는지 확인합니다.
이벤트 유형
inferred
|
|||
|
배정 그룹 변경
|
사례 담당이 한 팀에서 다른 팀으로 이전되었음을 나타냅니다. 사례 레코드의 assignment_group 필드 변경을 모니터링해 이 이벤트를 추정합니다. | ||
|
중요한 이유
배정 그룹 변경을 추적하면 부서 간 인계를 분석하고 반복되는 라우팅 문제를 찾을 수 있습니다. 이 활동이 자주 발생하면 담당 범위나 프로세스 정의가 불명확하다는 뜻일 수 있습니다.
확보 방법
sn_customerservice_case 테이블의 감사 이력(sys_audit)을 바탕으로 추정하며, assignment_group 필드가 변경된 시점을 추적합니다.
기록
사례 감사 로그에서 'assignment_group' 필드의 값 변경을 감지합니다.
이벤트 유형
inferred
|
|||
|
상담원 조사 시작
|
상담원이 서비스 요청을 실제로 처리하기 시작했음을 나타내는 활동입니다. 일반적으로 케이스 상태가 '신규' 또는 '배정됨'에서 '처리 중'으로 바뀌는 시점으로 추정합니다. | ||
|
중요한 이유
이 이벤트를 통해 대기 시간과 실제 처리 시간을 구분할 수 있습니다. 배정부터 조사 시작까지 걸린 시간을 분석하면 상담원이 새 케이스를 처리하기 시작하기까지 지연되는 상황을 파악할 수 있습니다.
확보 방법
케이스의 상태 필드가 '처리 중'과 같은 진행 상태로 바뀌는 시점을 기준으로 추정합니다. 구체적인 상태 값은 설정에 따라 다를 수 있으므로 확인해야 합니다.
기록
'state' 필드가 대기 상태에서 진행 상태로 바뀌는지 확인합니다(예: '신규'에서 '처리 중'으로 변경).
이벤트 유형
inferred
|
|||
|
서비스 요청 재개
|
해결된 서비스 요청의 문제가 다시 발생하거나 해결 방안이 효과가 없어 요청이 진행 상태로 돌아갈 때 발생합니다. 상태가 '해결됨'에서 '처리 중'으로 바뀌는지 확인해 추정합니다. | ||
|
중요한 이유
재개된 케이스는 해결 품질을 직접 보여주며 재작업의 주요 원인입니다. 최초 문의 해결률과 고객 만족도를 높이려면 이 이벤트를 분석해야 합니다.
확보 방법
sn_customerservice_case 테이블의 감사 이력에서 state 필드가 '해결됨'에서 진행 상태로 바뀌는 순서를 찾아 추정합니다.
기록
'해결됨'에서 '진행 중'과 같은 활성 값으로 바뀌는 'state' 변경을 감지합니다.
이벤트 유형
inferred
|
|||
|
요청 분류 및 우선순위 지정
|
서비스 요청을 분류하고 긴급도와 라우팅을 결정할 우선순위를 지정하는 초기 분류 단계입니다. 사례 레코드의 감사 로그에서 category, subcategory 또는 priority 필드의 변경을 확인해 추정합니다. | ||
|
중요한 이유
이 활동을 분석하면 사례 분류 지연을 찾아내고 요청이 올바르게 전달되어 긴급도에 맞게 처리되는지 확인할 수 있습니다. 최초 배정까지 걸리는 시간과 전체 해결 효율에도 영향을 줍니다.
확보 방법
sn_customerservice_case 테이블의 감사 이력(sys_audit)을 바탕으로 추정합니다. 특히 category 및 priority 필드의 최초 입력 또는 업데이트를 추적합니다.
기록
'category' 또는 'priority' 필드에 최초 값이 설정되거나 값이 변경된 시점을 감지합니다.
이벤트 유형
inferred
|
|||
|
해결 방안 제안
|
상담원이 해결 방안을 찾아 고객에게 전달하고 확인을 요청하는 시점을 나타냅니다. 상태가 '승인 대기'와 같은 값으로 바뀌거나 특정 업무 메모가 입력되는 시점으로 추정할 수 있습니다. | ||
|
중요한 이유
이 단계는 조사 단계와 고객 확인 및 해결 단계를 구분합니다. 고객 확인을 기다리는 시간을 분석하면 케이스 마무리 절차를 간소화할 방법을 찾을 수 있습니다.
확보 방법
sn_customerservice_case 테이블의 감사 로그에서 상태가 해결 방안 제안을 나타내는 값(예: '해결 방안 제안')으로 바뀌는 시점을 기준으로 추정합니다. 구현 방식에 따라 다를 수 있습니다.
기록
'state' 필드가 '해결 방안 제안' 또는 '승인 대기'와 같은 값으로 바뀌는지 확인합니다.
이벤트 유형
inferred
|
|||
데이터 추출 가이드
시작할 준비가 되셨나요?
이 템플릿으로 데이터를 효과적으로 준비해 고객 서비스 운영의 개선점을 파악하고 최적화하세요. 지금 더 효율적이고 고객 중심적인 프로세스를 만들어 보세요.
고객 서비스 효율성을 높이세요
고객 만족도를 높이고 최초 접촉 해결률 80%를 달성하세요.
신용카드가 필요하지 않습니다. 몇 분이면 시작할 수 있습니다.