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

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

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

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

서비스 요청 관리 속성

서비스 요청 관리 프로세스를 충분히 분석하려면 이벤트 로그에 다음 데이터 필드를 포함하는 것이 좋습니다.
5 필수 5 권장 9 선택 사항
이름 설명
서비스 요청 ID
ServiceRequestId
각 서비스 요청을 고유하게 식별하는 값입니다.
설명

Service Request ID는 Freshservice에 등록된 각 서비스 요청에 부여되는 고유 번호 또는 코드입니다. 요청이 생성된 시점부터 종료될 때까지 전체 이력을 추적하는 기본 키로 사용됩니다.

process mining에서는 이 ID가 Case ID 역할을 하므로 중요합니다. 상태 변경, 담당자 배정, 메모 등 관련 이벤트가 모두 이 식별자를 기준으로 연결됩니다. 각 Service Request ID의 처리 과정을 분석하면 프로세스 전체를 처음부터 끝까지 시각화하고, 자주 나타나는 경로를 파악하며, 개별 케이스에 영향을 주는 이탈이나 병목을 찾아낼 수 있습니다.

중요한 이유

관련 이벤트를 모두 연결하는 필수 Case ID로, 단일 서비스 요청의 전체 처리 과정을 추적할 수 있습니다.

확보 방법

Freshservice의 티켓 객체에 있는 기본 필드입니다. UI에서 확인할 수 있으며 Freshservice API로도 조회할 수 있습니다.

예시
SR-12943SR-13501SR-14011
이벤트 시간
EventTime
활동이 발생한 정확한 시각입니다.
설명

이벤트 시간은 서비스 요청의 특정 활동이 기록된 날짜와 시각을 나타냅니다. 이벤트 순서를 올바르게 정하고 이벤트 간 소요 시간을 계산하는 데 필요한 기본 정보입니다.

process mining에서는 케이스별 활동 순서를 정하는 데 사용되며, 시간 기반 분석의 기준이 됩니다. 처리 시간, 활동 간 대기 시간, 서비스 수준 계약(SLA) 준수 여부를 계산할 때 활용합니다. 병목을 찾고 프로세스 성과를 파악하려면 정확한 타임스탬프가 필요합니다.

중요한 이유

이 타임스탬프를 기준으로 이벤트를 시간순으로 정렬합니다. 처리 시간과 병목 분석을 비롯한 모든 성과 분석의 바탕이 됩니다.

확보 방법

Freshservice에서 활동 또는 감사 로그 항목이 생성된 시각에 해당합니다.

예시
2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:20:05Z
활동명
ActivityName
서비스 요청 처리 중 특정 시점에 발생한 이벤트 또는 작업의 이름입니다.
설명

활동명은 서비스 요청의 처리 과정에서 발생한 특정 단계나 이벤트를 나타냅니다. 시스템 감사 로그, 상태 변경 또는 사용자가 수행한 작업에서 추출하며, 예를 들면 '담당자에게 요청 배정', '메모 추가', '서비스 요청 해결' 등이 있습니다.

이 속성은 서비스 요청의 흐름을 시각적으로 보여 주는 프로세스 맵을 구성하는 데 중요합니다. 활동의 순서와 빈도를 분석하면 실제 처리 방식을 파악하고, 단계 사이의 병목을 찾고, 활동별 소요 시간을 측정하며, 규정을 따르지 않거나 비효율적인 프로세스 변형을 확인할 수 있습니다.

중요한 이유

프로세스 맵에 표시되는 단계를 정의하여 서비스 요청 워크플로를 시각화하고 분석할 수 있습니다.

확보 방법

Freshservice 티켓에 연결된 'activities' 또는 'audits'에서 생성됩니다. 시스템 이벤트를 업무에 적합한 활동명으로 매핑하는 변환 로직이 필요한 경우가 많습니다.

예시
서비스 요청 생성상담원에게 요청 배정서비스 요청 해결서비스 요청 종료
소스 시스템
SourceSystem
데이터를 추출한 시스템을 식별합니다.
설명

이 속성은 프로세스 데이터의 출처를 나타내며, 여기서는 Freshservice를 의미합니다. 여러 시스템의 데이터를 통합해 프로세스 전체를 살펴보는 환경에서 특히 유용합니다.

단일 시스템만 분석할 때는 중복 정보처럼 보일 수 있지만, 향후 확장과 데이터 거버넌스를 고려해 포함하는 것이 좋습니다. 데이터 출처를 명확히 하고 데이터 통합 파이프라인을 관리하는 데 도움이 됩니다.

중요한 이유

데이터 출처와 추적 가능성을 보장합니다. 여러 시스템의 데이터를 결합하거나 데이터 거버넌스를 관리할 때 중요합니다.

확보 방법

일반적으로 데이터 추출 및 변환(ETL) 과정에서 고정값으로 추가합니다.

예시
FreshserviceFreshservice-API-v2
최종 데이터 업데이트
LastDataUpdate
소스 시스템에서 데이터를 마지막으로 새로 고친 시각을 나타내는 타임스탬프입니다.
설명

이 속성은 Freshservice에서 데이터 세트를 마지막으로 추출하거나 업데이트한 날짜와 시각을 기록합니다. 분석 대상 데이터가 얼마나 최신인지 파악하는 데 도움이 됩니다.

프로세스를 분석할 때 데이터의 최신 여부를 아는 것은 중요합니다. 이 타임스탬프를 통해 최신 정보를 보고 있는지 확인할 수 있어, 시의적절한 운영 의사결정을 내리고 분석 결과를 신뢰하는 데 도움이 됩니다.

중요한 이유

데이터의 최신 시점을 알려 주므로, 최신 정보를 바탕으로 분석하고 의사결정을 내릴 수 있습니다.

확보 방법

데이터 추출 및 변환(ETL) 과정에서 생성되어 데이터 세트에 기록됩니다.

예시
2024-05-21T02:00:00Z2024-05-20T02:00:00Z
배정된 담당자
AssignedAgent
현재 서비스 요청을 담당하는 상담원의 이름입니다.
설명

이 속성은 특정 시점에 서비스 요청 처리를 맡은 지원 담당자를 식별합니다. 요청 처리 중 담당자가 변경될 수 있습니다.

배정된 담당자를 분석하면 담당자별 성과와 업무량 분포를 파악할 수 있습니다. 담당자별 평균 해결 시간, 진행 중인 요청 수, 재배정률 등의 KPI를 계산할 수 있습니다. 이를 통해 성과가 높은 담당자, 추가 교육이 필요한 담당자, 업무량 배분의 불균형을 확인할 수 있습니다.

중요한 이유

담당자의 업무량과 성과를 분석하고, 재배정이 해결 시간에 미치는 영향을 파악할 수 있습니다.

확보 방법

Freshservice 티켓 객체의 'agent' 또는 'responder' 필드에서 확인할 수 있습니다.

예시
Alice JohnsonRobert Smith미배정
배정된 팀
AssignedTeam
서비스 요청 처리를 맡은 지원팀 또는 그룹입니다.
설명

이 속성은 서비스 요청을 담당하는 기능별 그룹이나 팀을 나타냅니다. 예를 들면 'IT 지원 2단계' 또는 '하드웨어 구매'가 있습니다. 개별 담당자가 요청을 맡기 전에 팀에 먼저 배정될 수 있습니다.

배정된 팀별로 분석하면 팀 단위의 성과와 업무량을 파악하고, 특정 기능 영역의 병목을 찾을 수 있습니다. 지원 조직 내 각 팀의 요청 처리 효율을 평가하고 리소스 배분을 최적화하는 데 중요합니다.

중요한 이유

팀 또는 그룹 단위로 성과와 업무량을 분석할 수 있어 리소스 관리와 기능별 병목 파악에 도움이 됩니다.

확보 방법

Freshservice 티켓 객체의 'group' 필드에서 확인할 수 있습니다.

예시
서비스 데스크네트워크 운영애플리케이션 지원
상태
Status
서비스 요청의 처리 과정에서 현재 상태를 나타냅니다.
설명

상태 필드는 특정 시점의 서비스 요청 상태를 나타냅니다. 예를 들면 '열림', '대기', '해결됨', '종료'가 있습니다. 상태 변경은 process mining에서 활동을 추출하는 주요 원천입니다.

상태를 분석하면 프로세스 흐름을 이해하고 요청이 각 상태에 머문 시간을 파악할 수 있습니다. 예를 들어 '대기' 상태가 오래 지속되면 요청자 정보나 외부 업체의 답변을 기다리는 병목일 수 있습니다. 각 프로세스 단계의 시작과 종료 지점을 정의하는 데도 중요한 속성입니다.

중요한 이유

각 이벤트의 맥락을 파악하고 '열림'이나 '대기' 등 상태별 체류 시간을 측정해 지연을 찾을 수 있습니다.

확보 방법

Freshservice 티켓 객체의 'status' 필드에서 확인할 수 있습니다.

예시
열림대기해결됨종료
서비스 유형
ServiceType
요청한 서비스의 구체적인 유형 또는 범주입니다.
설명

서비스 유형은 필요한 서비스의 종류에 따라 요청을 분류합니다. 예를 들면 '신규 하드웨어 요청', '소프트웨어 접근 권한', '비밀번호 재설정'이 있습니다. 사용자가 선택한 서비스 카탈로그 항목과 연결되는 경우가 많습니다.

이 속성을 사용하면 서비스 유형별로 요청을 나누어 프로세스와 성과를 비교할 수 있습니다. '서비스 유형별 평균 활동 수'와 같은 KPI를 계산해 어떤 서비스가 더 복잡하거나 리소스를 많이 사용하는지 파악할 수 있습니다. 분석 결과를 바탕으로 특정 서비스 유형의 프로세스를 간소화하거나 자동화할 수 있습니다.

중요한 이유

요청 범주별 프로세스 흐름과 복잡도를 비교해 표준화하거나 자동화할 영역을 찾을 수 있습니다.

확보 방법

설정에 따라 Freshservice 티켓 객체의 'category', 'item' 또는 사용자 지정 필드에 해당합니다.

예시
신규 직원 온보딩소프트웨어 라이선스 요청VPN 접근 권한
우선순위
Priority
서비스 요청의 우선순위입니다. 낮음, 보통, 높음, 긴급 등으로 표시합니다.
설명

우선순위는 서비스 요청의 중요도와 긴급도를 나타내며, 목표 해결 시간과 배정 리소스에 영향을 주는 경우가 많습니다. 규칙에 따라 자동으로 설정하거나 담당자가 직접 지정할 수 있습니다.

process mining에서 우선순위는 중요한 분석 기준입니다. 우선순위가 높은 요청과 낮은 요청을 구분해 프로세스 흐름과 성과를 비교할 수 있습니다. SLA 준수 여부를 분석하고, 초기 분류 단계에서 우선순위가 적절하고 신속하게 지정되는지 파악하는 데 필요합니다.

중요한 이유

SLA 준수 여부를 분석하고 요청의 업무상 영향에 따라 적절히 분류하고 처리하는지 파악하는 데 중요합니다.

확보 방법

Freshservice 티켓 객체의 'priority' 필드에서 확인할 수 있습니다.

예시
낮음보통높음긴급
SLA 기한
SlaDueDate
SLA에 따라 서비스 요청을 해결해야 하는 시각입니다.
설명

이 속성은 적용된 SLA 정책에 정의된 서비스 요청 해결 기한을 나타냅니다. 요청 생성 시각, 우선순위, SLA에 정의된 업무 시간을 기준으로 계산됩니다.

실시간 성과 모니터링과 사후 SLA 준수 분석에 필요한 데이터입니다. 실제 해결 시각을 SlaDueDate와 비교해 SLA를 '준수'했는지 '위반'했는지 판단할 수 있습니다. SLA 준수율 KPI를 계산하는 기준이 됩니다.

중요한 이유

해결 목표 기한으로, 서비스 요청이 SLA를 준수했는지 위반했는지 계산하는 기준입니다.

확보 방법

Freshservice에서 계산되는 필드로, 티켓의 'Due by' 항목에서 확인할 수 있으며 API로도 조회할 수 있습니다.

예시
2023-10-28T17:00:00Z2023-11-01T09:00:00Z
SLA 위반 여부
IsSlaBreached
서비스 요청이 해결 SLA 목표 시간을 초과했는지 나타내는 불리언 값입니다.
설명

이 계산 속성은 서비스 요청이 SLA 기한이 지난 뒤 종료되었는지 참 또는 거짓으로 표시합니다. 'Service Request Closed' 또는 'Service Request Resolved' 타임스탬프를 'SlaDueDate'와 비교해 계산합니다.

이 속성을 사용하면 SLA 준수 대시보드에서 데이터를 간편하게 분석하고 시각화할 수 있습니다. 요청을 쉽게 필터링하고 집계해 전체 SLA 준수율 KPI를 계산할 수 있습니다. 이 값으로 구분하면 SLA를 위반한 요청과 기한 내 해결된 요청의 프로세스 특성을 빠르게 비교할 수 있습니다.

중요한 이유

목표를 충족하지 못한 요청을 명확한 값으로 표시해 필터링과 집계를 간소화하고 SLA 준수 여부를 분석할 수 있습니다.

확보 방법

데이터 변환 과정에서 최종 해결 타임스탬프와 'SlaDueDate' 필드를 비교해 계산합니다.

예시
truefalse
SLA 정책명
SlaPolicyName
요청에 적용된 서비스 수준 계약(SLA) 정책의 이름입니다.
설명

이 속성은 서비스 요청의 목표 응답 시간과 해결 시간을 정하는 SLA 정책을 식별합니다. 정책은 일반적으로 우선순위, 서비스 유형, 요청자 그룹 등의 기준에 따라 적용됩니다.

적용된 SLA 정책을 파악하는 것은 SLA 준수 및 위반 분석 대시보드에 중요합니다. 정의된 목표에 대한 성과를 정확히 측정하고, 어떤 정책에서 위반이 자주 발생하는지 분석할 수 있습니다. 이를 바탕으로 프로세스 성과를 검토하거나 SLA 목표의 실현 가능성을 재평가할 수 있습니다.

중요한 이유

요청에 적용되는 서비스 목표를 식별하므로 SLA 준수 현황을 정확하게 보고하는 데 필요합니다.

확보 방법

티켓에 연결된 SLA 데이터에 포함된 정보입니다. SLA 관련 API 엔드포인트나 필드를 별도로 조회해야 할 수 있습니다.

예시
높은 우선순위 장애, 4시간일반 요청, 3일VIP 지원, 1시간
요청자
Requestor
서비스 요청을 제출한 사용자입니다.
설명

이 속성은 서비스 요청을 시작한 사람, 대개 직원을 식별합니다. 서비스 데스크 이용자와 필요한 서비스를 파악하는 데 도움이 됩니다.

프로세스 흐름을 분석할 때 요청자 자체가 주요 기준은 아닐 수 있지만, 요청자나 소속 부서별로 살펴보면 반복되는 양상을 찾을 수 있습니다. 예를 들어 특정 부서에서 정보가 누락된 요청을 자주 제출한다면 해당 부서를 대상으로 교육할 필요가 있음을 알 수 있습니다. 고객 경험을 분석할 때도 중요한 속성입니다.

중요한 이유

요청을 시작한 사용자에 대한 맥락을 제공해 개인, 부서 또는 위치별 요청 양상을 분석할 수 있습니다.

확보 방법

Freshservice 티켓 객체의 'requester' 필드에서 확인할 수 있습니다.

예시
John DoeJane Smith서비스 계정
요청자 부서
RequestorDepartment
요청자가 소속된 부서입니다.
설명

이 속성은 서비스 요청을 제출한 사용자의 소속 부서를 나타냅니다. 예를 들면 '영업', '재무', '인사'가 있습니다. 일반적으로 시스템의 사용자 프로필에서 가져옵니다.

부서별 프로세스 성과 분석은 흔히 요구됩니다. 특정 부서의 해결 시간이 더 길거나 고유한 프로세스 요구사항이 있는지 확인할 수 있습니다. 분석 결과는 리소스 배분, 교육 계획 또는 부서별 서비스 제공 방식을 마련하는 데 활용할 수 있습니다.

중요한 이유

사업 부문별로 프로세스를 구분해 부서별 문제나 성과 차이를 찾을 수 있습니다.

확보 방법

요청자의 프로필에 연결된 정보입니다. Freshservice의 기본 'department' 필드 또는 사용자 지정 필드에 저장될 수 있습니다.

예시
재무마케팅정보기술
재배정 횟수
ReassignmentCount
서비스 요청이 다른 담당자나 팀에 재배정된 총횟수입니다.
설명

이 계산 속성은 서비스 요청별로 'Request Reassigned' 또는 유사한 활동이 발생한 횟수를 셉니다. 재배정 횟수가 많으면 초기 분류 문제, 잘못된 기술 기반 라우팅 또는 업무량 불균형을 나타낼 수 있습니다.

이 속성은 '담당자 성과 및 업무량 분포' 대시보드와 '요청당 평균 담당자 재배정 횟수' KPI에 직접 활용됩니다. 이 지표를 분석하면 티켓이 여러 담당자에게 계속 전달되는 원인이 되는 프로세스의 취약점을 찾을 수 있습니다. 잦은 전달은 해결 시간을 늘리고 담당자와 요청자 모두의 불편을 초래합니다.

중요한 이유

라우팅 비효율과 프로세스 마찰을 측정합니다. 횟수가 많으면 초기 분류나 담당자 업무량에 문제가 있어 처리가 지연될 수 있습니다.

확보 방법

데이터 변환 과정에서 각 'ServiceRequestId'의 특정 배정 변경 활동을 세어 계산합니다.

예시
013
재작업 여부
IsRework
요청 처리에 재작업 활동이 있었는지 나타내는 불리언 값입니다.
설명

이 계산값은 서비스 요청에서 재작업을 나타내는 특정 활동이 발생하면 참으로 설정됩니다. 예를 들면 해결 후 요청 재개('Service Request Reopened'), 여러 차례 재배정, 사용자에게 정보 재요청('Information Requested from Requestor') 등이 있습니다.

이 속성을 사용하면 프로세스 비효율을 간편하게 분석할 수 있습니다. 재작업이 발생한 케이스를 필터링하고 해당 프로세스 맵과 처리 시간을 재작업이 없는 케이스와 비교할 수 있습니다. 이를 통해 '서비스 요청 재작업 분석' 대시보드를 지원하고, 비효율적인 인계나 최초 정보 누락의 영향을 정량화할 수 있습니다.

중요한 이유

비효율적인 반복이나 중복 단계가 있는 케이스를 표시하고 분석해 품질 저하에 따른 비용을 정량화할 수 있습니다.

확보 방법

데이터 변환 과정에서 각 'ServiceRequestId'의 활동 순서에 업무 규칙을 적용해 계산합니다.

예시
truefalse
접수 채널
Channel
서비스 요청을 접수한 방법 또는 채널입니다.
설명

접수 채널은 셀프서비스 포털, 이메일, 전화, 채팅 등 서비스 요청이 생성된 경로를 나타냅니다. 이 정보로 사용자의 선호도와 채널별 효율을 파악할 수 있습니다.

채널별 프로세스를 분석하면 유용한 정보를 얻을 수 있습니다. 예를 들어 포털로 접수한 요청은 정보가 더 충실해 이메일 요청보다 빨리 해결될 수 있습니다. 이메일 요청은 추가 확인을 위해 여러 차례 연락해야 할 수 있습니다. 이러한 분석을 통해 효율적인 채널의 이용을 늘릴 수 있습니다.

중요한 이유

접수 채널이 프로세스 효율, 해결 시간 또는 재작업량에 영향을 주는지 분석할 수 있습니다.

확보 방법

Freshservice 티켓 객체의 'source' 필드에서 확인할 수 있습니다.

예시
이메일포털전화채팅
종료 시각
EndTime
활동이 완료된 정확한 시각입니다.
설명

종료 시각은 활동이 완료된 시점을 나타냅니다. Freshservice의 많은 이벤트는 시작 시각과 종료 시각이 같아 특정 시점에 발생한 이벤트로 기록됩니다. 다만 상태 기반 활동의 종료 시각은 다음 상태로 변경된 시각입니다.

이 속성은 활동별 소요 시간과 활동 사이의 대기 시간을 계산하는 데 필요합니다. 종료 시각에서 시작 시각을 빼면 특정 작업의 처리 시간을 구할 수 있습니다. 시간이 가장 오래 걸리는 활동과 최적화 우선순위가 높은 활동을 찾는 데 중요합니다.

중요한 이유

활동별 소요 시간을 계산해 병목을 찾고 각 단계의 처리 시간을 측정할 수 있습니다.

확보 방법

Freshservice 로그에 직접 기록되는 필드는 아닙니다. 서비스 요청별 이벤트 순서에서 다음 이벤트의 타임스탬프를 가져와 계산해야 합니다.

예시
2023-10-26T10:05:15Z2023-10-26T14:00:20Z2023-10-28T09:30:00Z
필수 권장 선택 사항

서비스 요청 관리 활동

서비스 요청 워크플로를 정확히 파악하고 분석하려면 이벤트 로그에 다음 주요 프로세스 단계와 마일스톤을 기록하세요.
6 권장 9 선택 사항
활동 설명
SLA 목표 초과
서비스 요청 해결 시간이 정해진 서비스 수준 계약(SLA) 목표를 초과할 때 발생하는 계산 이벤트입니다. 시스템에 직접 기록되는 이벤트가 아니라 해결 시간과 SLA 기한을 비교해 산출합니다.
중요한 이유

서비스 약속 대비 성과를 직접 측정하는 주요 KPI입니다. 목표를 지키지 못할 위험이 큰 요청 유형이나 우선순위를 파악하는 데 도움이 됩니다.

확보 방법

'Resolved' 타임스탬프와 'SLA Due By' 타임스탬프를 비교해 계산합니다. 해결 시간이 더 늦으면 이 이벤트가 발생합니다.

기록

해결 타임스탬프와 SLA 기한 타임스탬프를 비교합니다. resolved_at > sla_due_by이면 이 이벤트를 생성합니다.

이벤트 유형 calculated
상담원에게 요청 배정
서비스 요청을 처리할 특정 상담원에게 배정한 시점을 나타냅니다. 주요 이정표이며 티켓의 'Assigned Agent' 또는 'Owner' 필드 변경을 추적해 추정합니다.
중요한 이유

이 활동은 상담원 업무량을 분석하고 배정 과정의 병목을 찾는 데 중요합니다. 요청 생성부터 배정까지 걸리는 시간은 주요 성과 지표입니다.

확보 방법

티켓 활동 로그나 필드 감사 추적에서 'Agent' 또는 'Assignee' 필드의 변경을 확인해 추정합니다.

기록

'Assigned Agent' 필드에 값이 입력되거나 값이 변경된 시점의 타임스탬프를 기록합니다.

이벤트 유형 inferred
서비스 요청 생성
Freshservice에 새 요청이 공식적으로 등록되면 서비스 요청 수명 주기가 시작됩니다. 서비스 카탈로그, 이메일 또는 다른 채널을 통해 새 티켓 레코드가 생성될 때 이 이벤트가 명시적으로 기록되고 고유한 서비스 요청 ID가 부여됩니다.
중요한 이유

이 이벤트는 프로세스의 주요 시작 이벤트입니다. 이 활동부터 다른 활동까지 걸리는 시간을 분석하면 전체 처리 시간을 측정하고 초기 처리 지연을 파악할 수 있습니다.

확보 방법

이 이벤트는 Freshservice에 명시적으로 기록됩니다. 티켓의 활동 로그나 감사 추적에서 확인할 수 있으며, 일반적으로 티켓 생성 타임스탬프에 해당합니다.

기록

Freshservice 티켓 데이터에서 티켓 생성 타임스탬프를 사용합니다.

이벤트 유형 explicit
서비스 요청 종료
서비스 요청 수명 주기의 마지막 활동입니다. 일반적으로 티켓이 다시 열리지 않은 채 'Resolved' 상태로 일정 시간이 지나면 자동으로 종료됩니다.
중요한 이유

이 이벤트는 프로세스 인스턴스가 완전히 끝났음을 나타냅니다. 'Resolved'에서 'Closed'까지의 시간은 요청자가 해결 결과를 확인할 수 있는 기간입니다.

확보 방법

티켓 상태 변경 이력을 바탕으로 추정합니다. 상태가 'Closed'로 변경된 시점의 타임스탬프에 해당합니다.

기록

티켓 상태가 'Closed'로 변경된 시점의 타임스탬프를 기록합니다.

이벤트 유형 inferred
서비스 요청 해결
상담원이 해결책을 제공하고 업무가 완료되었다고 판단한 시점을 나타내는 주요 이정표입니다. 티켓 상태가 'Resolved'로 변경된 경우로 추정합니다.
중요한 이유

이 활동은 실제 처리 단계가 끝났음을 나타냅니다. 이 시점까지 걸린 시간은 상담원과 프로세스의 효율성을 측정하는 주요 지표이며 SLA 계산의 기준이 됩니다.

확보 방법

티켓 상태 변경 이력을 바탕으로 추정합니다. 상태가 처음 'Resolved'로 설정된 시점의 타임스탬프에 해당합니다.

기록

티켓 상태가 처음 'Resolved'로 변경된 시점의 타임스탬프를 기록합니다.

이벤트 유형 inferred
외부 공급업체 참여
티켓 해결을 위해 외부 공급업체나 제3자에게 업무를 인계한 시점을 나타냅니다. 상태가 'Pending Vendor' 또는 'Awaiting Third Party'와 같은 값으로 변경된 경우로 추정합니다.
중요한 이유

공급업체 참여로 인해 처리가 크게 지연될 수 있습니다. 이 활동을 추적하면 공급업체 성과와 전체 서비스 요청 처리 시간에 미치는 영향을 측정할 수 있습니다.

확보 방법

티켓 상태 변경 이력을 바탕으로 추정합니다. 외부 공급업체에 대한 의존도를 추적하도록 설정된 상태를 확인합니다.

기록

티켓 상태 필드가 제3자의 응답을 기다리는 상태로 변경된 시점을 확인합니다.

이벤트 유형 inferred
내부 검토 수행
제안된 해결책이나 요청 처리를 진행하기 전에 내부 검토 또는 승인이 필요한 경우를 나타냅니다. 상태가 'Pending Approval' 또는 'Internal Review'와 같은 값으로 변경된 경우로 추정합니다.
중요한 이유

내부 검토는 특히 복잡하거나 영향이 큰 서비스 요청에서 병목의 원인이 될 수 있습니다. 소요 시간을 측정하면 승인 워크플로를 간소화할 수 있습니다.

확보 방법

티켓 상태 변경 이력을 바탕으로 추정합니다. 워크플로에서 'Pending Internal Approval'과 같은 특정 상태를 사용해야 합니다.

기록

티켓 상태 필드가 내부 검토 또는 승인을 나타내는 값으로 변경된 시점을 확인합니다.

이벤트 유형 inferred
메모 추가
상담원이나 요청자가 서비스 요청에 공개 또는 비공개 메모를 추가한 경우를 나타냅니다. 티켓의 대화 기록이나 활동 로그에 명시적으로 기록되는 이벤트입니다.
중요한 이유

메모의 빈도와 시점을 분석하면 커뮤니케이션 패턴, 협업 효율성, 프로세스에서 혼선이 발생하는 지점을 파악할 수 있습니다.

확보 방법

Freshservice 티켓의 대화 기록에 명시적으로 기록됩니다. 각 메모에는 타임스탬프와 작성자가 포함됩니다.

기록

티켓의 대화 기록이나 댓글 로그에서 각 항목을 추출합니다.

이벤트 유형 explicit
서비스 요청 재개
요청자가 'Resolved'로 표시된 뒤에도 문제가 계속된다고 알려 티켓이 다시 열린 상태로 돌아간 경우입니다. 상태가 'Resolved'에서 'Open' 또는 'In Progress'로 변경된 경우로 추정합니다.
중요한 이유

요청이 다시 열리는 경우는 최초 해결률이 낮거나 고객이 만족하지 못한다는 강한 신호입니다. 해결 품질을 높이려면 이러한 재작업 흐름을 추적해야 합니다.

확보 방법

활동 로그의 티켓 상태 변경 이력을 바탕으로 추정합니다. 'Resolved'에서 'Open'으로 직접 전환된 경우입니다.

기록

상태가 해결됨에서 열림으로 변경된 시점을 확인합니다.

이벤트 유형 inferred
요청 분류
새로 생성된 서비스 요청을 처음 검토하고 분류하는 단계입니다. 일반적으로 우선순위가 처음 설정되거나 요청이 그룹에 배정된 시점으로 추정합니다. 이는 요청을 검토해 대기열에 넣었음을 나타냅니다.
중요한 이유

분류 과정을 추적하면 초기 대응팀의 효율성을 측정할 수 있습니다. 이 단계의 지연은 전체 해결 시간과 SLA 준수에 큰 영향을 줄 수 있습니다.

확보 방법

활동 로그를 바탕으로 추정합니다. 요청 생성 후 처음 발생한 '우선순위 설정' 또는 '그룹 배정' 이벤트의 타임스탬프로 확인할 수 있습니다.

기록

우선순위 필드가 변경된 시점과 배정 그룹 필드가 변경된 시점 중 더 이른 타임스탬프를 확인합니다.

이벤트 유형 inferred
요청 우선순위 지정
서비스 요청에 낮음, 보통, 높음 등의 우선순위가 지정되는 활동입니다. 티켓 이력에서 'Priority' 필드의 변경을 감지해 추정합니다.
중요한 이유

우선순위 지정은 리소스 배분과 SLA 목표 달성에 중요합니다. 이 활동을 분석하면 요청을 적절한 시점에 올바르게 평가하는지 확인할 수 있습니다.

확보 방법

Freshservice 티켓의 필드 변경 이력을 바탕으로 추정합니다. 'Priority' 필드의 업데이트를 찾아 변경 타임스탬프를 기록합니다.

기록

'Priority' 필드가 null 또는 이전 값에서 변경된 것을 감지하고 타임스탬프를 기록합니다.

이벤트 유형 inferred
요청 재배정
최초 배정 후 담당 상담원이나 그룹이 변경된 경우를 기록합니다. 이후 'Assigned Agent' 또는 'Assigned Group' 필드가 업데이트된 것을 감지해 추정합니다.
중요한 이유

재배정이 잦으면 초기 분류, 상담원 역량 배정 또는 업무량 균형에 문제가 있을 수 있습니다. 이 활동은 상담원 재배정 횟수 KPI와 재작업 분석에 중요합니다.

확보 방법

티켓의 필드 변경 이력을 바탕으로 추정합니다. 최초 값이 설정된 후 'Assigned Agent' 또는 'Assigned Group' 필드가 업데이트될 때마다 이 이벤트를 기록합니다.

기록

최초 배정 후 'Assigned Agent' 또는 'Assigned Group' 필드가 변경되었는지 확인합니다.

이벤트 유형 inferred
요청자가 정보 제공
요청자가 필요한 정보를 제공해 상담원이 업무를 재개할 수 있는 시점입니다. 일반적으로 티켓 상태가 'Pending'에서 'Open'으로 자동 변경된 경우로 추정합니다.
중요한 이유

이 활동은 정보 요청과 제공을 하나의 과정으로 연결합니다. 정보 요청부터 제공까지 걸리는 시간은 분석과 최적화가 필요한 주요 대기 시간입니다.

확보 방법

요청자의 답변으로 티켓 상태가 'Pending'에서 'Open' 또는 'In Progress'로 변경된 경우로 추정합니다.

기록

티켓 상태가 대기 상태에서 진행 중 상태로 변경된 시점을 확인합니다.

이벤트 유형 inferred
요청자가 해결 확인
요청자가 제공된 해결책에 만족한다고 명시적으로 확인한 활동입니다. 긍정적인 설문 응답이나 티켓 종료 전의 특정 댓글을 바탕으로 추정할 수 있습니다.
중요한 이유

요청자의 확인은 해결 품질에 대한 직접적인 피드백입니다. 재개되지 않았더라도 확인율이 낮다면 해결책이 사용자의 요구를 충분히 충족하지 못했을 수 있습니다.

확보 방법

이 활동은 직접 기록하기 어려우며 별도 설정이 필요할 수 있습니다. 티켓과 연결된 고객 만족도 설문 응답이나 특정 태그를 바탕으로 추정할 수 있습니다.

기록

만족도 설문이나 해결 후 적용된 태그 등 관련 데이터를 분석해야 합니다.

이벤트 유형 inferred
요청자에게 정보 요청
담당 상담원이 요청자에게 추가 정보를 요청해 처리가 일시 중단된 시점을 나타냅니다. 티켓 상태가 'Pending' 또는 'Awaiting Customer'로 변경된 경우로 추정합니다.
중요한 이유

이 활동은 지연과 재작업이 자주 발생하는 원인을 보여줍니다. 발생 빈도를 분석하면 요청 양식과 초기 정보 수집을 개선할 기회를 찾을 수 있습니다.

확보 방법

티켓 상태 변경 이력을 바탕으로 추정합니다. 'Pending Customer Response' 또는 'Awaiting Information'과 같이 고객 응답이나 정보 제공을 기다리는 상태로 변경된 경우를 확인합니다.

기록

티켓 상태 필드가 사용자 입력을 기다리는 상태로 변경된 시점을 확인합니다.

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

데이터 추출 가이드

Freshservice에서 데이터 가져오기

시작할 준비가 되셨나요?

데이터를 준비해 서비스 요청 관리 프로세스 최적화의 첫걸음을 내딛으세요. 서비스 제공 방식을 개선하실 수 있도록 지원합니다.

지금 Freshservice에서 서비스 요청 처리 효율을 높이세요

처리 지연과 사용자 불만을 줄이고 자동화율 70%를 달성하세요.

무료 체험 시작

신용카드가 필요하지 않습니다. 몇 분이면 설정할 수 있습니다.