Mẫu dữ liệu quản lý sự cố
Mẫu dữ liệu quản lý sự cố
- Các thuộc tính nên thu thập
- Các hoạt động chính cần theo dõi
- Hướng dẫn trích xuất dữ liệu
Thuộc tính quản lý sự cố
| Tên | Mô tả | ||
|---|---|---|---|
|
Mã sự cố
IncidentId
|
Mã định danh duy nhất của mỗi hồ sơ sự cố, dùng làm khóa chính để theo dõi toàn bộ vòng đời sự cố. | ||
|
Mô tả
Mã sự cố là nền tảng để phân tích quản lý sự cố. Mã này đóng vai trò như Case ID, liên kết mọi hoạt động, dấu thời gian và thay đổi thuộc tính liên quan thành một hành trình thống nhất. Trong process mining, mỗi mục trong nhật ký sự kiện đều gắn với một Mã sự cố. Nhờ đó, bạn có thể dựng lại luồng quy trình từ đầu đến cuối cho từng sự cố. Đây là cơ sở để tính thời gian xử lý, phân tích các biến thể quy trình và tìm điểm nghẽn của từng hồ sơ. Nếu không có mã định danh duy nhất, bạn sẽ không thể phân biệt các sự cố hoặc phân tích hành trình từ lúc báo cáo đến khi xử lý xong.
Vì sao điều này quan trọng
Mã này định danh duy nhất từng sự cố, giúp theo dõi và phân tích toàn bộ vòng đời từ lúc tạo đến khi đóng.
Lấy dữ liệu ở đâu
Đây là mã định danh chính của phiếu, có trong Freshservice Tickets API dưới dạng trường 'id' của đối tượng phiếu.
Ví dụ
INC-10234INC-10235INC-10236
|
|||
|
Dấu thời gian sự kiện
EventTimestamp
|
Ngày và giờ chính xác khi hoạt động hoặc sự kiện diễn ra. | ||
|
Mô tả
Dấu thời gian sự kiện, hay thời điểm bắt đầu, ghi lại chính xác lúc một hoạt động diễn ra. Mỗi hoạt động trong vòng đời sự cố, từ lúc tạo đến khi đóng, đều có dấu thời gian tương ứng. Thuộc tính này rất quan trọng với mọi phân tích process mining dựa trên thời gian. Nó giúp sắp xếp sự kiện theo trình tự, tính khoảng thời gian giữa các hoạt động, đo tổng thời gian xử lý hồ sơ và phân tích thời gian chờ. Đây cũng là cơ sở để tạo dashboard theo dõi hiệu suất SLA, độ trễ khi bàn giao và tổng thời gian xử lý.
Vì sao điều này quan trọng
Thuộc tính này cho biết trình tự thời gian của các sự kiện, cần thiết để tính thời lượng, phân tích thời gian xử lý và đánh giá hiệu suất quy trình.
Lấy dữ liệu ở đâu
Thuộc tính này được lấy từ nhiều trường dấu thời gian trong Freshservice, chẳng hạn như 'created_at', 'updated_at' và dấu thời gian trong hội thoại hoặc nhật ký kiểm tra của phiếu.
Ví dụ
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
|
|||
|
Hệ thống nguồn
SourceSystem
|
Hệ thống trích xuất dữ liệu, thường là 'Freshservice'. | ||
|
Mô tả
Thuộc tính này cho biết dữ liệu đến từ đâu. Trong trường hợp này, giá trị luôn là 'Freshservice'. Tuy nhiên, đây là trường quan trọng khi kết hợp dữ liệu từ nhiều hệ thống để có cái nhìn đầy đủ về quy trình. Thêm thuộc tính Hệ thống nguồn là cách làm tốt để quản trị và truy xuất dữ liệu. Thuộc tính này giúp xác định rõ nguồn gốc dữ liệu, hỗ trợ kiểm tra, gỡ lỗi và mở rộng dự án process mining để đưa thêm các hệ thống quản lý dịch vụ hoặc vận hành vào phân tích.
Vì sao điều này quan trọng
Thuộc tính này giúp truy xuất và quản trị dữ liệu bằng cách xác định rõ nguồn gốc dữ liệu quản lý sự cố.
Lấy dữ liệu ở đâu
Đây thường là giá trị cố định được thêm trong quá trình chuyển đổi dữ liệu (ETL) để gắn nhãn cho tập dữ liệu.
Ví dụ
FreshserviceFreshservice-EUFreshservice-PROD
|
|||
|
Lần cập nhật dữ liệu gần nhất
LastDataUpdate
|
Dấu thời gian cho biết lần gần nhất dữ liệu của quy trình được làm mới hoặc trích xuất. | ||
|
Mô tả
Thuộc tính này ghi lại thời điểm toàn bộ tập dữ liệu được cập nhật gần nhất từ hệ thống nguồn. Đây là trường siêu dữ liệu áp dụng cho toàn bộ tập dữ liệu, không phải từng sự kiện riêng lẻ, nhưng thường được đưa vào từng sự kiện để đảm bảo tính nhất quán. Khi phân tích, thông tin này giúp bạn biết dữ liệu mới đến đâu và dashboard cùng KPI bao quát khoảng thời gian nào. Nhờ đó, người dùng có thể tin tưởng hơn vào độ cập nhật của thông tin và biết liệu các sự cố mới nhất đã được đưa vào phân tích hay chưa.
Vì sao điều này quan trọng
Thuộc tính này cho người dùng biết dữ liệu được cập nhật gần đây đến mức nào và phân tích bao quát khoảng thời gian nào.
Lấy dữ liệu ở đâu
Đây là dấu thời gian siêu dữ liệu được tạo trong quá trình trích xuất dữ liệu (ETL).
Ví dụ
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Tên hoạt động
ActivityName
|
Tên của hoạt động nghiệp vụ hoặc sự kiện cụ thể diễn ra tại một thời điểm trong vòng đời sự cố. | ||
|
Mô tả
Tên hoạt động mô tả một bước hoặc sự kiện trong quy trình quản lý sự cố, chẳng hạn như 'Incident Assigned to Group', 'Status Changed to Pending' hoặc 'Incident Resolved'. Các hoạt động này được xác định từ những thay đổi dữ liệu sự cố theo thời gian. Thuộc tính này là nền tảng của process mining vì nó xác định các nút trên sơ đồ quy trình được khám phá. Khi phân tích trình tự và tần suất hoạt động, tổ chức có thể hình dung quy trình xử lý sự cố thực tế, tìm các luồng phổ biến, phát hiện sai lệch so với quy trình chuẩn và nhận diện vòng lặp làm lại, chẳng hạn như việc phân công lại nhiều lần.
Vì sao điều này quan trọng
Thuộc tính này xác định các bước trên sơ đồ quy trình, giúp bạn hình dung và phân tích luồng xử lý sự cố, điểm nghẽn và sai lệch.
Lấy dữ liệu ở đâu
Đây không phải trường có sẵn trong Freshservice. Thuộc tính này được xác định từ những thay đổi trong thông tin phiếu, như trạng thái, mức độ ưu tiên, phân công nhân viên hỗ trợ hoặc nhóm, và việc thêm ghi chú.
Ví dụ
Đã báo cáo sự cốĐã phân công sự cố cho nhómĐã thêm ghi chú xử lýĐã xử lý xong sự cố
|
|||
|
Danh mục sự cố
IncidentCategory
|
Danh mục dùng để phân loại sự cố, chẳng hạn như Phần cứng, Phần mềm hoặc Mạng. | ||
|
Mô tả
Danh mục sự cố giúp phân loại sự cố theo loại vấn đề được báo cáo. Cách phân loại theo cấp bậc này giúp chuyển sự cố đến đúng nhóm và rất hữu ích khi phân tích xu hướng. Thuộc tính này được dùng trong dashboard 'Incident Categorization Accuracy' để xem việc phân loại sai ban đầu có kéo dài thời gian xử lý do phải phân công lại hay không. Khi nhóm sự cố theo danh mục, tổ chức có thể tìm vấn đề lặp lại, biết phần lớn công sức hỗ trợ đang dành cho đâu và điều chỉnh các sáng kiến cải tiến.
Vì sao điều này quan trọng
Thuộc tính này giúp phân tích xu hướng sự cố và xác định liệu phân loại sai có làm chậm quá trình xử lý hay không.
Lấy dữ liệu ở đâu
Đây là trường mặc định có thể tùy chỉnh trong Freshservice. Trường này có trong Tickets API dưới dạng 'category', cùng các trường liên quan 'sub_category' và 'item_category'.
Ví dụ
Phần cứngPhần mềmSự cố mạngQuyền truy cập tài khoản
|
|||
|
Mức độ nghiêm trọng của sự cố
IncidentSeverity
|
Mức độ nghiêm trọng của sự cố, cho biết ảnh hưởng đến hoạt động kinh doanh. | ||
|
Mô tả
Mức độ nghiêm trọng của sự cố đo lường ảnh hưởng của sự cố đến hoạt động kinh doanh, thường được chia thành Thấp, Trung bình, Cao hoặc Nghiêm trọng. Mức độ nghiêm trọng có liên quan đến mức độ ưu tiên, nhưng tập trung vào ảnh hưởng, còn mức độ ưu tiên tập trung vào tính khẩn cấp. Mức độ nghiêm trọng và ảnh hưởng thường được kết hợp để xác định mức độ ưu tiên cuối cùng. Phân tích theo mức độ nghiêm trọng giúp bạn hiểu tổ chức xử lý ra sao những sự cố gây hậu quả đáng kể cho hoạt động kinh doanh. Dashboard có thể dùng thuộc tính này để chia thời gian xử lý và hiệu suất SLA theo nhóm, đảm bảo các vấn đề có ảnh hưởng lớn được ưu tiên đúng mức và có đủ tài nguyên trong suốt vòng đời.
Vì sao điều này quan trọng
Thuộc tính này đo lường ảnh hưởng của sự cố đến hoạt động kinh doanh, giúp tập trung phân tích vào những vấn đề gây thiệt hại lớn nhất.
Lấy dữ liệu ở đâu
Đây là trường mặc định trong Freshservice, có trong Tickets API dưới dạng 'impact'. Giá trị là số.
Ví dụ
ThấpTrung bìnhCao
|
|||
|
Mức độ ưu tiên của sự cố
IncidentPriority
|
Mức độ ưu tiên của sự cố, quyết định mức độ khẩn cấp khi phản hồi và xử lý. | ||
|
Mô tả
Mức độ ưu tiên của sự cố là trường quan trọng, quyết định tốc độ và mức độ tập trung cần thiết khi xử lý. Trường này thường có các mức Thấp, Trung bình, Cao và Khẩn cấp, đồng thời thường quyết định mục tiêu SLA. Trong process mining, mức độ ưu tiên là tiêu chí quan trọng để lọc và phân tích. Bạn có thể so sánh quy trình xử lý sự cố ưu tiên cao với sự cố ưu tiên thấp, qua đó kiểm tra xem các vấn đề nghiêm trọng có được xử lý hiệu quả hay không. Dashboard thường chia các chỉ số như thời gian xử lý và mức độ đáp ứng SLA theo mức độ ưu tiên, giúp quản lý bộ phận hỗ trợ xác định việc cần làm.
Vì sao điều này quan trọng
Thuộc tính này giúp tập trung phân tích vào các sự cố nghiêm trọng nhất, đồng thời cần thiết để đánh giá hiệu suất SLA và phân bổ tài nguyên.
Lấy dữ liệu ở đâu
Có trong Freshservice Tickets API dưới dạng trường 'priority'. Giá trị là số, chẳng hạn 1 là Thấp và 4 là Khẩn cấp.
Ví dụ
ThấpTrung bìnhCaoKhẩn cấp
|
|||
|
Nhân viên hỗ trợ được phân công
AssignedAgent
|
Tên hoặc mã của nhân viên hỗ trợ hiện được giao xử lý sự cố. | ||
|
Mô tả
Nhân viên hỗ trợ được phân công là người phụ trách sự cố tại một thời điểm cụ thể. Khi thuộc tính này thay đổi, trách nhiệm xử lý được chuyển từ nhân viên này sang nhân viên khác. Thuộc tính này cần thiết để phân tích hiệu suất. Bạn có thể tạo dashboard theo dõi khối lượng công việc, thời gian xử lý trung bình của từng nhân viên và tỷ lệ xử lý ngay từ lần liên hệ đầu tiên. Thuộc tính này cũng giúp phân tích việc bàn giao giữa các nhân viên, vốn có thể gây chậm trễ và kém hiệu quả. Theo dõi phân công giúp quản lý xác định nhu cầu đào tạo và ghi nhận những thành viên có hiệu suất tốt.
Vì sao điều này quan trọng
Thuộc tính này giúp phân tích hiệu suất, phân bổ khối lượng công việc và ảnh hưởng của việc bàn giao giữa nhân viên đến thời gian xử lý.
Lấy dữ liệu ở đâu
Có trong Freshservice Tickets API dưới dạng trường 'responder_id'. Bạn có thể kết hợp mã này với Agents API để lấy tên nhân viên hỗ trợ.
Ví dụ
John DoeJane SmithSupportBot
|
|||
|
Nhóm được phân công
AssignedGroup
|
Nhóm hoặc đội ngũ hỗ trợ hiện được giao xử lý sự cố. | ||
|
Mô tả
Nhóm được phân công cho biết đội ngũ nào chịu trách nhiệm xử lý sự cố, chẳng hạn như 'Level 1 Support', 'Network Team' hoặc 'Database Admins'. Khi thuộc tính này thay đổi, sự cố được chuyển cấp hoặc chuyển giữa các nhóm chuyên môn. Phân tích thuộc tính này rất quan trọng để hiểu độ trễ khi bàn giao và chuyển nhóm. Process mining có thể trực quan hóa luồng sự cố giữa các nhóm, làm rõ các tuyến chuyển cấp phổ biến và đo thời gian chờ mỗi nhóm bắt đầu xử lý. Nhờ đó, bạn có thể tìm điểm nghẽn trong tổ chức và cơ hội phối hợp giữa các nhóm hiệu quả hơn.
Vì sao điều này quan trọng
Thuộc tính này theo dõi nhóm chịu trách nhiệm, giúp phân tích việc bàn giao, chuyển cấp và độ trễ giữa các nhóm.
Lấy dữ liệu ở đâu
Có trong Freshservice Tickets API dưới dạng trường 'group_id'. Bạn có thể kết hợp mã này với Groups API để lấy tên nhóm.
Ví dụ
Bộ phận hỗ trợ dịch vụVận hành mạngHỗ trợ hạ tầng
|
|||
|
Thời hạn SLA xử lý sự cố
ResolutionSlaTargetTime
|
Thời điểm sự cố cần được xử lý xong theo chính sách SLA. | ||
|
Mô tả
Thuộc tính này lưu ngày và giờ cụ thể làm hạn chót xử lý sự cố. Thời hạn được xác định theo chính sách Thỏa thuận mức dịch vụ (SLA) áp dụng cho phiếu, thường dựa trên các yếu tố như mức độ ưu tiên. Thời hạn này cần thiết để tính KPI 'SLA Adherence Rate' và cung cấp dữ liệu cho 'SLA Performance Dashboard'. So sánh thời điểm xử lý thực tế với thời hạn giúp xác định sự cố có được xử lý đúng hạn hay vi phạm SLA. Đây là cơ sở để đo lường mức độ đáp ứng cam kết dịch vụ.
Vì sao điều này quan trọng
Thuộc tính này cung cấp hạn chót xử lý, cần thiết để tính mức độ tuân thủ SLA và xác định các sự cố có nguy cơ trễ hạn.
Lấy dữ liệu ở đâu
Có trong Freshservice Tickets API dưới dạng các trường 'fr_due_by' (phản hồi đầu tiên) và 'due_by' (xử lý xong).
Ví dụ
2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-05T17:00:00Z
|
|||
|
Trạng thái sự cố
IncidentStatus
|
Trạng thái hiện tại của sự cố trong vòng đời, chẳng hạn như Open, Pending, Resolved hoặc Closed. | ||
|
Mô tả
Trạng thái sự cố cho biết tình trạng hiện tại của sự cố. Các lần đổi trạng thái là những sự kiện quan trọng tạo nên sơ đồ quy trình được khám phá, chẳng hạn như chuyển từ 'In Progress' sang 'Pending' hoặc từ 'Resolved' sang 'Closed'. Thuộc tính này giúp bạn hiểu hành trình xử lý sự cố. Phân tích thời gian ở từng trạng thái giúp tìm điểm nghẽn, chẳng hạn như sự cố ở trạng thái 'Pending' quá lâu vì chờ người dùng phản hồi. Thuộc tính này cũng rất quan trọng để xác định điểm bắt đầu và kết thúc khi tính thời gian xử lý.
Vì sao điều này quan trọng
Thuộc tính này theo dõi tiến trình của sự cố trong suốt vòng đời và giúp tìm các giai đoạn thường xảy ra chậm trễ.
Lấy dữ liệu ở đâu
Có trong Freshservice Tickets API dưới dạng trường 'status'. Giá trị là số.
Ví dụ
Đang mởĐang xử lýĐang chờĐã xử lýĐã đóng
|
|||
|
Có được mở lại không
IsReopened
|
Cờ được tính toán, có giá trị đúng nếu sự cố được mở lại sau khi đã xử lý xong hoặc đóng. | ||
|
Mô tả
Thuộc tính dạng đúng/sai này là cờ được tính toán để xác định các sự cố đã được mở lại. Cờ có giá trị đúng nếu trạng thái sự cố chuyển từ 'Resolved' hoặc 'Closed' về trạng thái đang mở hoặc đang xử lý. Cờ này rất quan trọng để tính KPI 'Incident Reopening Rate' và phục vụ dashboard 'Recurring Incidents'. Tỷ lệ mở lại cao có thể cho thấy cách xử lý ban đầu chưa tốt, phân tích nguyên nhân gốc rễ chưa đầy đủ hoặc sự cố bị đóng quá sớm. Phân tích các trường hợp này giúp cải thiện chất lượng và độ bền vững của giải pháp.
Vì sao điều này quan trọng
Thuộc tính này giúp phát hiện vấn đề trong quy trình xử lý, làm rõ những sự cố mà cách khắc phục ban đầu không hiệu quả và dẫn đến phải làm lại.
Lấy dữ liệu ở đâu
Đây là trường được tính từ trình tự hoạt động trong nhật ký sự kiện. Trường có giá trị đúng nếu xuất hiện hoạt động như 'Incident Reopened' hoặc nếu một hoạt động ở trạng thái mở diễn ra sau hoạt động ở trạng thái đóng của cùng một Mã sự cố.
Ví dụ
truefalse
|
|||
|
Có vi phạm SLA không
IsSlaBreached
|
Cờ được tính toán, có giá trị đúng nếu sự cố không được xử lý trong thời hạn SLA đã đặt. | ||
|
Mô tả
Thuộc tính dạng đúng/sai này là chỉ số được tính toán, cho biết thời gian xử lý sự cố có vượt quá thời hạn SLA hay không. Thuộc tính được xác định bằng cách so sánh thời điểm xử lý thực tế với 'ResolutionSlaTargetTime'. Cờ này là dữ liệu đầu vào trực tiếp cho KPI 'SLA Adherence Rate' và 'SLA Performance Dashboard'. Cờ giúp đơn giản hóa phân tích bằng cách thể hiện rõ kết quả SLA của từng sự cố dưới dạng đạt hoặc không đạt, thuận tiện cho việc tổng hợp và phân tích xu hướng. Nhờ đó, bạn có thể nhanh chóng xác định số lượng và tỷ lệ sự cố không đáp ứng cam kết dịch vụ.
Vì sao điều này quan trọng
Thuộc tính này đo trực tiếp mức độ tuân thủ SLA của từng sự cố, giúp dễ dàng tính tỷ lệ đáp ứng chung và xác định các vấn đề cần xử lý.
Lấy dữ liệu ở đâu
Đây là trường được tính trong quá trình chuyển đổi dữ liệu bằng cách so sánh dấu thời gian 'Incident Resolved' với trường 'ResolutionSlaTargetTime'.
Ví dụ
truefalse
|
|||
|
Đã cung cấp giải pháp tạm thời
WorkaroundProvided
|
Cờ cho biết người dùng có được cung cấp cách khắc phục tạm thời trước khi xử lý dứt điểm hay không. | ||
|
Mô tả
Thuộc tính dạng đúng/sai này cho biết có áp dụng cách khắc phục tạm thời để giảm ảnh hưởng của sự cố trong khi phát triển giải pháp lâu dài hay không. Thông tin này thường được theo dõi bằng hộp kiểm hoặc một trạng thái cụ thể. Trong process mining, thuộc tính này hỗ trợ dashboard 'Workaround Effectiveness Metrics'. Bạn có thể so sánh thời gian xử lý sự cố có và không có cách khắc phục tạm thời, từ đó đánh giá liệu giải pháp tạm thời có giảm gián đoạn hoạt động kinh doanh và giúp người dùng cảm nhận sự cố được xử lý nhanh hơn hay không.
Vì sao điều này quan trọng
Thuộc tính này giúp đo lường hiệu quả của cách khắc phục tạm thời trong việc giảm ảnh hưởng của sự cố và giúp người dùng cảm nhận rằng vấn đề được xử lý nhanh hơn.
Lấy dữ liệu ở đâu
Đây thường là trường dạng đúng/sai tùy chỉnh (hộp kiểm). Cần kiểm tra xem trường này có tồn tại trong cấu hình 'Ticket Fields' của Freshservice hay không.
Ví dụ
truefalse
|
|||
|
Kênh báo cáo
ReportingChannel
|
Phương thức hoặc kênh dùng để báo cáo sự cố, chẳng hạn như email, cổng thông tin hoặc điện thoại. | ||
|
Mô tả
Kênh báo cáo, còn gọi là nguồn, cho biết sự cố được gửi đến hệ thống hỗ trợ bằng cách nào. Các kênh phổ biến gồm email, cổng tự phục vụ, điện thoại hoặc trò chuyện. Phân tích thuộc tính này giúp đánh giá hiệu quả của từng kênh báo cáo. Dashboard 'Reporting Channel Efficiency' so sánh số lượng sự cố và thời gian xử lý trung bình theo kênh để xác định kênh nào hiệu quả nhất và kênh nào cần cải tiến quy trình. Ví dụ, sự cố gửi qua cổng thông tin có thể được xử lý nhanh hơn nếu ngay từ đầu đã có thông tin theo cấu trúc rõ ràng.
Vì sao điều này quan trọng
Thuộc tính này giúp tìm các kênh báo cáo hiệu quả nhất và cơ hội cải thiện quy trình tiếp nhận sự cố.
Lấy dữ liệu ở đâu
Có trong Freshservice Tickets API dưới dạng trường 'source'. Giá trị là số.
Ví dụ
EmailCổng thông tinĐiện thoạiTrò chuyện
|
|||
|
Nguyên nhân gốc rễ
RootCause
|
Lý do hoặc nguyên nhân gốc rễ của sự cố được xác định sau khi điều tra. | ||
|
Mô tả
Thuộc tính Nguyên nhân gốc rễ ghi lại vấn đề cốt lõi dẫn đến sự cố. Nhân viên hỗ trợ thường điền thông tin này trong hoặc sau khi xử lý, như một phần của quy trình phân tích nguyên nhân gốc rễ (RCA). Thuộc tính này rất quan trọng với dashboard 'Recurring Incidents And Root Causes' và KPI 'Root Cause Analysis Completion Rate'. Phân tích các nguyên nhân gốc rễ phổ biến giúp tổ chức chuyển từ xử lý sự cố bị động sang quản lý vấn đề chủ động, triển khai giải pháp lâu dài để ngăn sự cố tái diễn và giảm vấn đề lặp lại.
Vì sao điều này quan trọng
Thuộc tính này hỗ trợ quản lý vấn đề chủ động bằng cách giúp tìm và loại bỏ nguyên nhân cốt lõi của các sự cố tái diễn.
Lấy dữ liệu ở đâu
Đây thường là trường tùy chỉnh trong Freshservice vì chức năng mặc định có thể còn hạn chế. Kiểm tra cấu hình 'Ticket Fields' để tìm trường tên 'Root Cause' hoặc tên tương tự.
Ví dụ
Lỗi phần mềmLỗi cấu hình mạngVấn đề đào tạo người dùngLỗi phần cứng
|
|||
|
Phòng ban của người yêu cầu
RequestersDepartment
|
Phòng ban của người dùng báo cáo sự cố. | ||
|
Mô tả
Thuộc tính này cho biết phòng ban của người yêu cầu, chẳng hạn như 'Sales', 'Finance' hoặc 'IT'. Thông tin này thường được lấy từ hồ sơ người dùng trong Freshservice. Phân tích sự cố theo phòng ban của người yêu cầu có thể cho thấy một số đơn vị bị ảnh hưởng nhiều hơn bởi sự cố hoặc gặp vấn đề riêng. Thông tin này giúp hiểu rõ tác động của sự cố đến hoạt động kinh doanh và ưu tiên khắc phục những vấn đề ảnh hưởng đến các phòng ban trọng yếu.
Vì sao điều này quan trọng
Thuộc tính này cung cấp bối cảnh kinh doanh, giúp phân tích xu hướng sự cố và ảnh hưởng đến từng phòng ban.
Lấy dữ liệu ở đâu
Thông tin này được liên kết với người yêu cầu của phiếu. Bạn có thể lấy thông tin từ điểm cuối API 'Requesters' bằng 'requester_id' trong phiếu, sau đó truy cập 'department_id' và tên phòng ban.
Ví dụ
Kinh doanhTiếp thịTài chínhNhân sự
|
|||
|
Số lần bàn giao
HandoffCount
|
Số lần sự cố được chuyển giữa các nhân viên hỗ trợ hoặc nhóm. | ||
|
Mô tả
Số lần bàn giao là chỉ số được tính để đếm số lần phân công lại sự cố trong suốt vòng đời. Mỗi lần thuộc tính 'AssignedAgent' hoặc 'AssignedGroup' thay đổi sẽ làm tăng số đếm. Số lần bàn giao cao thường cho thấy quy trình kém hiệu quả, sự cố được chuyển sai nhóm ban đầu hoặc nhân viên hỗ trợ chưa có đủ chuyên môn. Chỉ số này hỗ trợ trực tiếp KPI 'Incident Handoff Count' và dashboard 'Handoff And Transfer Delay Analysis', giúp tìm sự cố hoặc luồng quy trình có quá nhiều lần chuyển giao gây chậm trễ.
Vì sao điều này quan trọng
Thuộc tính này đo lường việc làm lại và phân công lại, giúp tìm sự kém hiệu quả do chuyển sai nhóm hoặc thiếu kiến thức.
Lấy dữ liệu ở đâu
Đây là chỉ số được tính bằng cách đếm số giá trị khác nhau hoặc số lần thay đổi trong các trường 'AssignedAgent' hoặc 'AssignedGroup' trong vòng đời của một sự cố.
Ví dụ
0125
|
|||
Hoạt động quản lý sự cố
| Hoạt động | Mô tả | ||
|---|---|---|---|
|
Đã báo cáo sự cố
|
Đánh dấu thời điểm tạo hồ sơ sự cố mới trong Freshservice. Đây là điểm bắt đầu của vòng đời sự cố. Người dùng cuối thường báo cáo qua cổng thông tin hoặc email, hoặc nhân viên bộ phận hỗ trợ tạo phiếu thay cho họ. Sự kiện này được ghi lại rõ ràng cùng dấu thời gian tạo. | ||
|
Vì sao điều này quan trọng
Đây là sự kiện bắt đầu chính của toàn bộ quy trình. Phân tích thời gian từ sự kiện này đến khi xử lý xong là cơ sở để đo tổng thời gian xử lý và mức độ đáp ứng SLA.
Lấy dữ liệu ở đâu
Lấy từ dấu thời gian tạo trong bảng sự cố. Freshservice ghi lại thông tin này cho từng phiếu mới.
Thu thập
Dùng dấu thời gian 'Created at' trong hồ sơ sự cố chính.
Loại sự kiện
explicit
|
|||
|
Đã chuyển trạng thái sang In Progress
|
Hoạt động này đánh dấu thời điểm chính thức bắt đầu điều tra và xử lý sự cố. Sự kiện được ghi nhận khi nhân viên chuyển trạng thái sự cố sang 'In Progress'. Đây là thay đổi trạng thái tiêu chuẩn được lưu trong lịch sử hoạt động của phiếu. | ||
|
Vì sao điều này quan trọng
Mốc này giúp phân biệt thời gian chờ với thời gian thực sự xử lý. Phân tích khoảng thời gian sự cố ở trạng thái 'In Progress' là điều cần thiết để hiểu rõ công sức xử lý.
Lấy dữ liệu ở đâu
Suy ra từ nhật ký hoạt động của sự cố bằng cách xác định thời điểm trường 'Status' được cập nhật thành 'In Progress'.
Thu thập
Lọc nhật ký hoạt động để tìm lần chuyển trạng thái sang 'In Progress', rồi dùng dấu thời gian tương ứng.
Loại sự kiện
inferred
|
|||
|
Đã đặt mức độ ưu tiên cho sự cố
|
Sự kiện xảy ra khi mức độ ưu tiên của sự cố được đặt hoặc cập nhật. Mức ưu tiên quyết định mức độ khẩn cấp và mục tiêu SLA khi xử lý. Có thể ghi nhận sự kiện này bằng cách theo dõi các thay đổi trong trường 'Priority' ở lịch sử sự cố. | ||
|
Vì sao điều này quan trọng
Đặt mức ưu tiên sai hoặc chậm có thể dẫn đến vi phạm SLA và phân bổ tài nguyên kém hiệu quả. Phân tích hoạt động này giúp bảo đảm sự cố nghiêm trọng được xử lý ngay.
Lấy dữ liệu ở đâu
Suy ra từ nhật ký hoạt động của sự cố, nơi ghi lại mọi cập nhật cho trường 'Priority'.
Thu thập
Dùng dấu thời gian trong nhật ký kiểm tra khi giá trị trường 'Priority' được đặt hoặc thay đổi.
Loại sự kiện
inferred
|
|||
|
Đã phân công sự cố cho nhóm
|
Đánh dấu lần đầu phân công sự cố cho một nhóm hỗ trợ. Việc này có thể diễn ra tự động theo quy tắc định tuyến hoặc do nhân viên điều phối thực hiện thủ công. Có thể ghi nhận hoạt động này bằng cách theo dõi lần đầu trường 'Group' được điền trong nhật ký kiểm tra của sự cố. | ||
|
Vì sao điều này quan trọng
Theo dõi việc phân công là điều cần thiết để đo thời gian phản hồi đầu tiên và xác định điểm nghẽn trong khâu điều phối. Việc này giúp phân tích mức độ hiệu quả khi chuyển sự cố đến đúng đội.
Lấy dữ liệu ở đâu
Suy ra từ mục đầu tiên trong nhật ký hoạt động của sự cố có điền hoặc thay đổi trường 'Group'.
Thu thập
Xác định dấu thời gian đầu tiên khi trường 'Group' được điền cho một sự cố.
Loại sự kiện
inferred
|
|||
|
Đã thêm ghi chú xử lý
|
Sự kiện xảy ra khi nhân viên ghi lại giải pháp cho sự cố bằng cách thêm ghi chú xử lý. Đây là thao tác riêng trong Freshservice, diễn ra trước khi chuyển trạng thái sang 'Resolved'. Thao tác và nội dung ghi chú được ghi lại rõ ràng. | ||
|
Vì sao điều này quan trọng
Mốc này đánh dấu thời điểm xác định được giải pháp. Khoảng thời gian từ đây đến khi sự cố chuyển sang trạng thái 'Incident Resolved' có thể cho thấy thời gian dành cho việc rà soát nội bộ hoặc ghi chép.
Lấy dữ liệu ở đâu
Lấy dấu thời gian khi ghi chú xử lý được thêm vào sự cố. Thông tin này được lưu trong lịch sử trao đổi.
Thu thập
Xác định dấu thời gian của mục 'Resolution Note' trong nhật ký trao đổi của sự cố.
Loại sự kiện
explicit
|
|||
|
Đã xử lý xong sự cố
|
Đánh dấu thời điểm nhân viên đã áp dụng biện pháp khắc phục và xác định sự cố đã được xử lý. Sự kiện được ghi nhận khi trạng thái sự cố chuyển sang 'Resolved'. Trong Freshservice, đây là mốc quan trọng để dừng đồng hồ SLA. | ||
|
Vì sao điều này quan trọng
Đây là mốc quan trọng để đo thời gian xử lý (TTR). Khoảng thời gian từ trạng thái 'Resolved' đến 'Closed' rất hữu ích khi phân tích chậm trễ trong việc chờ người dùng xác nhận và chính sách tự động đóng sự cố.
Lấy dữ liệu ở đâu
Suy ra từ nhật ký hoạt động của sự cố bằng cách xác định thời điểm trường 'Status' được cập nhật thành 'Resolved'.
Thu thập
Dùng dấu thời gian trong mục nhật ký hoạt động ghi nhận lần chuyển trạng thái sang 'Resolved'.
Loại sự kiện
inferred
|
|||
|
Sự cố được đóng
|
Đây là bước đóng chính thức cuối cùng của hồ sơ sự cố. Thường hệ thống tự đóng sau một khoảng thời gian ở trạng thái 'Resolved', hoặc nhân viên hỗ trợ có thể đóng thủ công. Sự kiện này đánh dấu kết thúc vòng đời sự cố. | ||
|
Vì sao điều này quan trọng
Đây là điểm kết thúc chính thức của quy trình. Tổng thời gian đến sự kiện này thể hiện toàn bộ vòng đời sự cố, bao gồm cả thời gian chờ người dùng xác nhận.
Lấy dữ liệu ở đâu
Xác định từ nhật ký hoạt động của sự cố bằng cách tìm thời điểm trường 'Status' được cập nhật thành 'Closed'.
Thu thập
Dùng dấu thời gian trong mục nhật ký hoạt động ghi nhận trạng thái chuyển thành 'Closed'.
Loại sự kiện
inferred
|
|||
|
Đã chuyển trạng thái sang Pending
|
Đánh dấu thời điểm quy trình xử lý tạm dừng, thường là để chờ thông tin từ người dùng hoặc bên thứ ba. Có thể suy ra sự kiện này từ việc chuyển trạng thái sang bất kỳ trạng thái 'Pending' nào. Thời gian ở trạng thái này thường không được tính vào SLA. | ||
|
Vì sao điều này quan trọng
Xác định thời gian ở trạng thái chờ là điều cần thiết để hiểu các yếu tố phụ thuộc bên ngoài và nguyên nhân gây chậm trễ. Việc này giúp tách thời gian nhân viên xử lý khỏi thời gian chờ.
Lấy dữ liệu ở đâu
Suy ra từ nhật ký hoạt động của sự cố khi trường 'Status' được cập nhật thành một giá trị như 'Pending' hoặc 'Awaiting User Response'.
Thu thập
Lọc nhật ký hoạt động để tìm các lần chuyển sang trạng thái chờ, rồi dùng dấu thời gian tương ứng.
Loại sự kiện
inferred
|
|||
|
Đã cung cấp giải pháp tạm thời
|
Hoạt động này ghi nhận việc thông báo cho người dùng về một giải pháp tạm thời nhằm giảm ảnh hưởng của sự cố. Để thu thập dữ liệu này, thường cần cấu hình hệ thống cụ thể, chẳng hạn như dùng hộp kiểm riêng, loại ghi chú cụ thể hoặc phân tích từ khóa trong ghi chú của nhân viên. | ||
|
Vì sao điều này quan trọng
Thông tin này giúp phân tích mức độ hiệu quả của giải pháp tạm thời trong việc giảm ảnh hưởng đến hoạt động kinh doanh và mối liên hệ giữa giải pháp đó với thời gian xử lý cuối cùng. Dữ liệu này hỗ trợ bảng điều khiển chỉ số hiệu quả của giải pháp tạm thời.
Lấy dữ liệu ở đâu
Sự kiện này có thể không được ghi nhận trực tiếp. Có thể suy ra bằng cách đánh dấu các ghi chú chứa từ khóa như 'workaround', hoặc theo dõi thay đổi nếu có trường hộp kiểm tùy chỉnh 'Workaround Provided'.
Thu thập
Suy ra từ thay đổi trong trường tùy chỉnh hoặc phân tích từ khóa trong ghi chú của nhân viên.
Loại sự kiện
inferred
|
|||
|
Đã gửi phản hồi đầu tiên
|
Hoạt động này ghi nhận lần đầu nhân viên liên hệ với người dùng sau khi sự cố được báo cáo. Đây có thể là ghi chú công khai hoặc thư trả lời trực tiếp. Freshservice ghi lại dấu thời gian của mọi trao đổi từ nhân viên. | ||
|
Vì sao điều này quan trọng
Đáp ứng SLA phản hồi đầu tiên là KPI quan trọng đối với mức độ hài lòng của khách hàng. Hoạt động này giúp đo lường và phân tích tốc độ nhân viên bắt đầu xử lý sự cố mới.
Lấy dữ liệu ở đâu
Xác định bằng cách tìm dấu thời gian của ghi chú công khai hoặc thư trả lời đầu tiên do nhân viên thêm vào nhật ký trao đổi của sự cố.
Thu thập
Lọc lịch sử trao đổi của sự cố để tìm mục sớm nhất do nhân viên tạo.
Loại sự kiện
explicit
|
|||
|
Đã phân công lại sự cố
|
Cho biết sự cố đã được chuyển từ nhân viên hoặc nhóm này sang nhân viên hoặc nhóm khác. Đây là một lần bàn giao trong quy trình xử lý. Có thể suy ra sự kiện này bằng cách phát hiện các thay đổi tiếp theo trong trường 'Agent' hoặc 'Group' sau lần phân công đầu tiên. | ||
|
Vì sao điều này quan trọng
Việc phân công lại hoặc bàn giao thường xuyên thường cho thấy quy trình kém hiệu quả, thiếu kiến thức hoặc định tuyến ban đầu chưa chính xác. Phân tích các sự kiện này giúp xác định và giảm chậm trễ.
Lấy dữ liệu ở đâu
Suy ra từ nhật ký hoạt động của sự cố bằng cách theo dõi mọi thay đổi trong trường 'Agent' hoặc 'Group' sau lần phân công đầu tiên.
Thu thập
Phát hiện các thay đổi trong trường 'Agent' hoặc 'Group' ở lịch sử kiểm tra của phiếu.
Loại sự kiện
inferred
|
|||
|
Đã phân công sự cố cho nhân viên
|
Hoạt động này đánh dấu thời điểm phân công một nhân viên cụ thể xử lý sự cố, tức là người đó nhận trách nhiệm xử lý phiếu. Lịch sử hoạt động của phiếu ghi lại nhân viên được phân công và thời điểm phân công. | ||
|
Vì sao điều này quan trọng
Thông tin này giúp phân tích khối lượng công việc và hiệu suất của nhân viên, cũng như thời gian từ lúc phân công cho nhóm đến khi một nhân viên bắt đầu xử lý sự cố. Đây là dữ liệu quan trọng cho bảng điều khiển hiệu suất nhân viên.
Lấy dữ liệu ở đâu
Theo dõi các thay đổi trong trường 'Agent' ở nhật ký hoạt động hoặc nhật ký kiểm tra của sự cố.
Thu thập
Xác định dấu thời gian tương ứng với các lần thay đổi trường 'Agent'.
Loại sự kiện
inferred
|
|||
|
Đã vi phạm mục tiêu SLA
|
Đây là sự kiện được tính toán, xảy ra khi thời gian xử lý sự cố vượt quá mục tiêu SLA đã đặt cho phản hồi hoặc xử lý. Freshservice theo dõi trạng thái SLA nội bộ. Có thể xác định sự kiện này bằng cách so sánh dấu thời gian với chính sách SLA. | ||
|
Vì sao điều này quan trọng
Sự kiện này đo trực tiếp mức độ đáp ứng các cam kết về dịch vụ. Xác định thời điểm và nguyên nhân xảy ra vi phạm là điều cần thiết cho bảng điều khiển hiệu suất SLA và hoạt động cải tiến liên tục.
Lấy dữ liệu ở đâu
Tính bằng cách so sánh thời điểm xử lý xong hoặc phản hồi với thời hạn SLA. Freshservice thường đánh dấu phiếu là 'SLA Violated'.
Thu thập
Xác định bằng cách so sánh thời điểm 'Resolved at' với thời điểm 'Due by', hoặc khi trường 'SLA Status' chuyển thành 'Violated'.
Loại sự kiện
calculated
|
|||
|
Sự cố được mở lại
|
Xảy ra khi sự cố đã được đánh dấu 'Resolved' được chuyển về trạng thái đang mở, thường là do người dùng không đồng ý với cách xử lý. Có thể nhận biết qua thay đổi trạng thái từ 'Resolved' về 'Open' hoặc 'In Progress'. | ||
|
Vì sao điều này quan trọng
Tỷ lệ mở lại cao cho thấy chất lượng xử lý có vấn đề hoặc sự cố chưa được khắc phục triệt để. Đây là chỉ số quan trọng để phân tích việc làm lại và hiệu suất của nhân viên hỗ trợ.
Lấy dữ liệu ở đâu
Xác định từ nhật ký hoạt động của sự cố bằng cách phát hiện trạng thái chuyển từ 'Resolved' sang trạng thái đang hoạt động.
Thu thập
Lọc nhật ký hoạt động để tìm thay đổi 'Status' từ 'Resolved' sang 'Open' hoặc 'In Progress'.
Loại sự kiện
inferred
|
|||
Hướng dẫn trích xuất dữ liệu
Sẵn sàng bắt đầu?
Dùng mẫu này để thiết lập dữ liệu đúng cách và khám phá thông tin hữu ích về quy trình làm việc quản lý sự cố. Bắt đầu rút ngắn thời gian xử lý ngay hôm nay.
Ngăn vi phạm SLA, tối ưu hóa quy trình quản lý sự cố ngay hôm nay
Tham gia cùng các doanh nghiệp đã giảm MTTR 35% và ngăn ngừa những vi phạm SLA gây tốn kém.
Dùng thử miễn phí 14 ngày, không cần thẻ tín dụng.