Mẫu dữ liệu quản lý yêu cầu dịch vụ

Freshservice
Mẫu dữ liệu quản lý yêu cầu dịch vụ

Mẫu dữ liệu quản lý yêu cầu dịch vụ

Mẫu này hướng dẫn bạn thu thập dữ liệu cần thiết để phân tích quy trình quản lý yêu cầu dịch vụ. Mẫu nêu rõ các thuộc tính cần có, những hoạt động chính cần theo dõi và cách trích xuất thông tin từ hệ thống nguồn. Hãy dùng tài nguyên này để tạo nhật ký sự kiện đầy đủ, phục vụ phân tích quy trình chuyên sâu.
  • 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
Chưa quen với nhật ký sự kiện? Tìm hiểu cách tạo nhật ký sự kiện cho process mining.

Thuộc tính quản lý yêu cầu dịch vụ

Đây là những trường dữ liệu nên có trong nhật ký sự kiện để phân tích quy trình quản lý yêu cầu dịch vụ.
5 Bắt buộc 5 Nên có 9 Không bắt buộc
Tên Mô tả
Mã yêu cầu dịch vụ
ServiceRequestId
Mã định danh duy nhất của từng yêu cầu dịch vụ.
Mô tả

Mã yêu cầu dịch vụ là số hoặc mã duy nhất được gán cho mỗi yêu cầu dịch vụ mới ghi nhận trong Freshservice. Mã này đóng vai trò khóa chính để theo dõi toàn bộ vòng đời yêu cầu, từ lúc tạo đến khi đóng.

Trong process mining, mã này rất quan trọng vì được dùng làm Case ID. Mọi sự kiện liên quan, như thay đổi trạng thái, phân công nhân viên hỗ trợ và ghi chú, đều được liên kết bằng mã này. Phân tích hành trình của từng mã yêu cầu dịch vụ giúp bạn xem toàn bộ quy trình từ đầu đến cuối, nhận diện các luồng xử lý phổ biến và phát hiện những điểm khác biệt hoặc điểm nghẽn ảnh hưởng đến từng trường hợp.

Vì sao điều này quan trọng

Đây là Case ID thiết yếu, liên kết mọi sự kiện liên quan để bạn theo dõi toàn bộ hành trình của một yêu cầu dịch vụ.

Lấy dữ liệu ở đâu

Đây là trường chính trên đối tượng phiếu trong Freshservice. Trường này hiển thị trên giao diện người dùng và có thể truy cập qua Freshservice API.

Ví dụ
SR-12943SR-13501SR-14011
Tên hoạt động
ActivityName
Tên sự kiện hoặc tác vụ diễn ra tại một thời điểm cụ thể trong quá trình xử lý yêu cầu dịch vụ.
Mô tả

Tên hoạt động mô tả một bước hoặc sự kiện cụ thể trong vòng đời yêu cầu dịch vụ. Dữ liệu hoạt động được trích xuất từ nhật ký kiểm tra hệ thống, thay đổi trạng thái hoặc hành động cụ thể của người dùng, chẳng hạn như 'Đã phân công yêu cầu cho nhân viên hỗ trợ', 'Đã thêm ghi chú' hoặc 'Đã giải quyết yêu cầu dịch vụ'.

Thuộc tính này rất quan trọng để tạo sơ đồ quy trình, thể hiện trực quan luồng xử lý yêu cầu dịch vụ. Phân tích trình tự và tần suất của các hoạt động giúp tổ chức hiểu quy trình thực tế, xác định điểm nghẽn giữa các bước, đo thời lượng hoạt động và phát hiện các biến thể quy trình không tuân thủ hoặc kém hiệu quả.

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 trực quan hóa và phân tích quy trình làm việc xử lý yêu cầu dịch vụ.

Lấy dữ liệu ở đâu

Được tạo từ các mục 'activities' hoặc 'audits' liên quan đến phiếu trong Freshservice. Thường cần logic chuyển đổi để ánh xạ sự kiện hệ thống sang tên hoạt động dễ hiểu với bộ phận nghiệp vụ.

Ví dụ
Tạo yêu cầu dịch vụGiao yêu cầu cho nhân viên hỗ trợGiải quyết yêu cầu dịch vụĐóng yêu cầu dịch vụ
Thời điểm sự kiện
EventTime
Dấu thời gian chính xác khi hoạt động diễn ra.
Mô tả

Thời điểm sự kiện ghi lại ngày giờ một hoạt động cụ thể được ghi nhận cho yêu cầu dịch vụ. Dấu thời gian này rất quan trọng để sắp xếp sự kiện đúng thứ tự và tính khoảng thời gian giữa các sự kiện.

Trong process mining, thuộc tính này dùng để sắp xếp hoạt động của từng trường hợp và làm cơ sở cho mọi phân tích theo thời gian. Thuộc tính này giúp tính thời gian chu kỳ, thời gian chờ giữa các hoạt động và mức độ đáp ứng thỏa thuận mức dịch vụ (SLA). Dấu thời gian chính xác giúp xác định điểm nghẽn và hiểu rõ hiệu suất quy trình.

Vì sao điều này quan trọng

Dấu thời gian này sắp xếp sự kiện theo trình tự thời gian và làm cơ sở cho mọi phân tích hiệu suất, bao gồm thời gian chu kỳ và việc phát hiện điểm nghẽn.

Lấy dữ liệu ở đâu

Đây là dấu thời gian tạo mục hoạt động hoặc nhật ký kiểm tra trong Freshservice.

Ví dụ
2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:20:05Z
Hệ thống nguồn
SourceSystem
Cho biết hệ thống đã trích xuất dữ liệu.
Mô tả

Thuộc tính này cho biết hệ thống nguồn của dữ liệu quy trình, trong trường hợp này là Freshservice. Thuộc tính đặc biệt hữu ích khi hợp nhất dữ liệu từ nhiều hệ thống để có cái nhìn tổng thể về quy trình.

Khi chỉ phân tích một hệ thống, thuộc tính này có thể có vẻ dư thừa. Tuy vậy, đây vẫn là cách làm tốt để dễ mở rộng và quản trị dữ liệu sau này. Thuộc tính giúp xác định rõ nguồn gốc dữ liệu và quản lý các luồng tích hợp dữ liệu.

Vì sao điều này quan trọng

Giúp xác định nguồn gốc và truy xuất dữ liệu, điều rất quan trọng khi kết hợp dữ liệu từ nhiều hệ thống hoặc phục vụ quản trị dữ liệu.

Lấy dữ liệu ở đâu

Thông thường, đây là giá trị cố định được thêm trong quá trình trích xuất và chuyển đổi dữ liệu (ETL).

Ví dụ
FreshserviceFreshservice-API-v2
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 làm mới từ hệ thống nguồn.
Mô tả

Thuộc tính này ghi lại ngày giờ lần gần nhất tập dữ liệu được trích xuất hoặc cập nhật từ Freshservice. Nhờ đó, bạn biết dữ liệu đang phân tích mới đến thời điểm nào.

Khi phân tích quy trình, việc biết dữ liệu có mới hay không rất quan trọng. Dấu thời gian này giúp người dùng biết họ đang xem thông tin mới nhất hay chưa. Đây là cơ sở để đưa ra quyết định vận hành kịp thời và tin cậy vào kết quả phân tích.

Vì sao điều này quan trọng

Cho người dùng biết dữ liệu được cập nhật gần đây đến mức nào, để việc phân tích và ra quyết định dựa trên thông tin mới nhất.

Lấy dữ liệu ở đâu

Giá trị này được tạo và ghi vào tập dữ liệu trong quá trình trích xuất và chuyển đổi dữ liệu (ETL).

Ví dụ
2024-05-21T02:00:00Z2024-05-20T02:00:00Z
Loại dịch vụ
ServiceType
Loại hoặc danh mục cụ thể của dịch vụ được yêu cầu.
Mô tả

Loại dịch vụ phân loại yêu cầu theo dịch vụ cần dùng, chẳng hạn như 'Yêu cầu thiết bị mới', 'Quyền truy cập phần mềm' hoặc 'Đặt lại mật khẩu'. Loại này thường gắn với mục trong danh mục dịch vụ mà người dùng chọn.

Thuộc tính này giúp phân nhóm yêu cầu dịch vụ để so sánh quy trình và hiệu suất giữa các loại dịch vụ. Đây là cơ sở để tính các KPI như 'Số hoạt động trung bình theo loại dịch vụ', qua đó xác định dịch vụ nào phức tạp hơn hoặc cần nhiều tài nguyên hơn. Kết quả phân tích có thể giúp đơn giản hóa quy trình và tự động hóa một số loại dịch vụ cụ thể.

Vì sao điều này quan trọng

Giúp so sánh luồng xử lý và độ phức tạp giữa các nhóm yêu cầu, từ đó xác định những khâu có thể chuẩn hóa hoặc tự động hóa.

Lấy dữ liệu ở đâu

Tùy cấu hình, thuộc tính này thường tương ứng với trường 'category', 'item' hoặc một trường tùy chỉnh trên đối tượng phiếu trong Freshservice.

Ví dụ
Tiếp nhận nhân viên mớiYêu cầu cấp giấy phép phần mềmQuyền truy cập VPN
Mức độ ưu tiên
Priority
Mức độ ưu tiên của yêu cầu dịch vụ, chẳng hạn như Thấp, Trung bình, Cao hoặc Khẩn cấp.
Mô tả

Mức độ ưu tiên cho biết tầm quan trọng và tính cấp bách của yêu cầu dịch vụ. Yếu tố này thường quyết định thời hạn giải quyết mục tiêu và tài nguyên được phân bổ. Hệ thống có thể tự đặt mức ưu tiên theo quy tắc hoặc nhân viên hỗ trợ có thể đặt thủ công.

Trong process mining, mức độ ưu tiên là một chiều phân tích quan trọng. Bạn có thể phân nhóm yêu cầu để so sánh luồng xử lý và hiệu suất giữa các yêu cầu ưu tiên cao và thấp. Việc này rất cần thiết để phân tích mức độ tuân thủ SLA và xem yêu cầu có được phân loại ưu tiên hiệu quả, kịp thời ở bước tiếp nhận ban đầu hay không.

Vì sao điều này quan trọng

Rất quan trọng để phân tích mức độ tuân thủ SLA và xem yêu cầu có được phân loại, xử lý theo tác động đến hoạt động kinh doanh hay không.

Lấy dữ liệu ở đâu

Có trong trường 'priority' trên đối tượng phiếu của Freshservice.

Ví dụ
ThấpTrung bìnhCaoKhẩn cấp
Nhân viên hỗ trợ được phân công
AssignedAgent
Tên nhân viên hỗ trợ hiện được phân công xử lý yêu cầu dịch vụ.
Mô tả

Thuộc tính này xác định nhân viên hỗ trợ cụ thể chịu trách nhiệm xử lý yêu cầu dịch vụ tại một thời điểm nhất định. Người phụ trách có thể thay đổi trong suốt vòng đời yêu cầu.

Phân tích theo nhân viên hỗ trợ được phân công giúp hiểu hiệu suất và khối lượng công việc của từng người. Bạn có thể tính các KPI như thời gian giải quyết trung bình theo nhân viên, số yêu cầu đang xử lý và tỷ lệ phân công lại. Qua đó, tổ chức có thể nhận diện nhân viên có hiệu suất tốt, người cần được đào tạo thêm và tình trạng phân bổ công việc chưa cân bằng.

Vì sao điều này quan trọng

Giúp phân tích khối lượng công việc, hiệu suất của nhân viên hỗ trợ và ảnh hưởng của việc phân công lại đến thời gian giải quyết.

Lấy dữ liệu ở đâu

Có trong trường 'agent' hoặc 'responder' trên đối tượng phiếu của Freshservice.

Ví dụ
Alice JohnsonRobert SmithChưa phân công
Nhóm được phân công
AssignedTeam
Nhóm hỗ trợ được phân công xử lý yêu cầu dịch vụ.
Mô tả

Thuộc tính này cho biết nhóm chức năng, chẳng hạn như 'Hỗ trợ CNTT cấp 2' hoặc 'Mua sắm thiết bị', chịu trách nhiệm xử lý yêu cầu dịch vụ. Yêu cầu có thể được giao cho một nhóm trước khi phân công cho nhân viên cụ thể.

Phân tích theo nhóm được phân công giúp hiểu hiệu suất, khối lượng công việc của từng nhóm và xác định điểm nghẽn ở các bộ phận chức năng cụ thể. Đây là cơ sở để đánh giá hiệu quả xử lý yêu cầu của từng nhóm và tối ưu phân bổ tài nguyên trong bộ phận hỗ trợ.

Vì sao điều này quan trọng

Cho phép phân tích hiệu suất và khối lượng công việc theo nhóm, cần thiết để quản lý tài nguyên và xác định điểm nghẽn ở từng bộ phận chức năng.

Lấy dữ liệu ở đâu

Có trong trường 'group' trên đối tượng phiếu của Freshservice.

Ví dụ
Bộ phận hỗ trợ dịch vụVận hành mạngHỗ trợ ứng dụng
Trạng thái
Status
Trạng thái hiện tại của yêu cầu dịch vụ trong vòng đời xử lý.
Mô tả

Trường Trạng thái thể hiện tình trạng của yêu cầu dịch vụ tại một thời điểm, chẳng hạn như 'Đang mở', 'Đang chờ', 'Đã giải quyết' hoặc 'Đã đóng'. Thay đổi trạng thái thường là nguồn hoạt động chính cho process mining.

Phân tích trạng thái giúp hiểu rõ luồng quy trình và thời gian yêu cầu nằm ở từng trạng thái. Ví dụ, yêu cầu ở trạng thái 'Đang chờ' quá lâu có thể cho thấy điểm nghẽn do chờ thông tin từ người yêu cầu hoặc nhà cung cấp bên ngoài. Đây cũng là thuộc tính quan trọng để xác định điểm bắt đầu và kết thúc của từng giai đoạn quy trình.

Vì sao điều này quan trọng

Cung cấp bối cảnh cần thiết cho từng sự kiện và giúp đo thời gian ở các trạng thái như 'Đang mở' hoặc 'Đang chờ' để phát hiện chậm trễ.

Lấy dữ liệu ở đâu

Có trong trường 'status' trên đối tượng phiếu của Freshservice.

Ví dụ
Đang mởĐang chờĐã giải quyếtĐã đóng
Có làm lại không
IsRework
Cờ đúng/sai cho biết yêu cầu có phát sinh hoạt động làm lại hay không.
Mô tả

Cờ được tính này được đặt thành đúng nếu yêu cầu dịch vụ có một số hoạt động cho thấy cần làm lại. Ví dụ: yêu cầu được mở lại sau khi giải quyết ('Đã mở lại yêu cầu dịch vụ'), bị phân công lại nhiều lần hoặc liên tục phải yêu cầu người dùng cung cấp thông tin ('Đã yêu cầu người gửi bổ sung thông tin').

Thuộc tính này giúp đơn giản hóa việc phân tích điểm kém hiệu quả trong quy trình. Bạn có thể dễ dàng lọc các trường hợp phải làm lại, rồi so sánh sơ đồ quy trình và thời gian chu kỳ với các trường hợp không phải làm lại. Thuộc tính này hỗ trợ trực tiếp cho dashboard 'Phân tích việc làm lại yêu cầu dịch vụ' và giúp định lượng tác động của việc bàn giao kém hiệu quả hoặc thông tin ban đầu chưa đầy đủ.

Vì sao điều này quan trọng

Giúp dễ dàng đánh dấu và phân tích các trường hợp có vòng lặp kém hiệu quả hoặc phải lặp lại bước xử lý, qua đó định lượng chi phí do chất lượng kém.

Lấy dữ liệu ở đâu

Được tính trong quá trình chuyển đổi dữ liệu bằng cách áp dụng logic nghiệp vụ cho chuỗi hoạt động của từng 'ServiceRequestId'.

Ví dụ
truefalse
Có vi phạm SLA không
IsSlaBreached
Cờ đúng/sai cho biết yêu cầu dịch vụ có vượt quá thời hạn giải quyết theo SLA hay không.
Mô tả

Thuộc tính được tính này là cờ đúng/sai, cho biết yêu cầu dịch vụ có được đóng sau hạn SLA hay không. Giá trị được xác định bằng cách so sánh dấu thời gian 'Đã đóng yêu cầu dịch vụ' hoặc 'Đã giải quyết yêu cầu dịch vụ' với 'SlaDueDate'.

Thuộc tính này giúp đơn giản hóa việc phân tích và trực quan hóa trên dashboard Tuân thủ SLA. Bạn có thể dễ dàng lọc và tổng hợp yêu cầu để tính KPI Tỷ lệ tuân thủ SLA. Phân nhóm theo cờ này giúp nhanh chóng xác định và phân tích đặc điểm quy trình của các yêu cầu vi phạm SLA so với những yêu cầu được giải quyết đúng hạn.

Vì sao điều này quan trọng

Đơn giản hóa việc phân tích tuân thủ SLA bằng một cờ rõ ràng để lọc và tổng hợp các yêu cầu không đạt mục tiêu.

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 giải quyết cuối cùng với trường 'SlaDueDate'.

Ví dụ
truefalse
Hạn SLA
SlaDueDate
Thời điểm yêu cầu dịch vụ dự kiến được giải quyết theo SLA.
Mô tả

Thuộc tính này xác định hạn giải quyết yêu cầu dịch vụ theo chính sách SLA áp dụng. Đây là dấu thời gian được tính dựa trên thời điểm tạo yêu cầu, mức độ ưu tiên và giờ làm việc quy định trong SLA.

Đây là dữ liệu quan trọng để theo dõi hiệu suất theo thời gian thực và phân tích mức độ tuân thủ SLA sau khi xử lý. So sánh thời điểm giải quyết thực tế với SlaDueDate giúp xác định yêu cầu 'Đạt' hay 'Vi phạm' SLA. Đây cũng là cơ sở để tính KPI Tỷ lệ tuân thủ SLA.

Vì sao điều này quan trọng

Đây là hạn giải quyết mục tiêu, làm cơ sở tính xem yêu cầu dịch vụ có đáp ứng hay vi phạm SLA.

Lấy dữ liệu ở đâu

Đây là trường được tính trong Freshservice, hiển thị trên phiếu với tên 'Due by' và có thể truy cập qua API.

Ví dụ
2023-10-28T17:00:00Z2023-11-01T09:00:00Z
Kênh tiếp nhận
Channel
Phương thức hoặc kênh gửi yêu cầu dịch vụ.
Mô tả

Kênh tiếp nhận cho biết yêu cầu dịch vụ được tạo bằng cách nào, chẳng hạn qua cổng tự phục vụ, email, điện thoại hoặc trò chuyện. Thông tin này giúp hiểu lựa chọn của người dùng và hiệu quả của từng kênh.

Phân tích quy trình theo kênh có thể cho thấy những điểm đáng chú ý. Ví dụ, yêu cầu gửi qua cổng thông tin có thể đầy đủ hơn và được giải quyết nhanh hơn yêu cầu gửi qua email, vốn có thể cần trao đổi qua lại nhiều lần. Kết quả phân tích giúp bạn khuyến khích người dùng chọn các kênh hiệu quả hơn.

Vì sao điều này quan trọng

Giúp phân tích kênh gửi yêu cầu có ảnh hưởng đến hiệu quả quy trình, thời gian giải quyết hoặc khối lượng công việc phải làm lại hay không.

Lấy dữ liệu ở đâu

Có trong trường 'source' trên đối tượng phiếu của Freshservice.

Ví dụ
EmailCổng thông tinĐiện thoạiTrò chuyện
Người yêu cầu
Requestor
Người đã gửi yêu cầu dịch vụ.
Mô tả

Thuộc tính này xác định người đã gửi yêu cầu dịch vụ, thường là một nhân viên. Thuộc tính cung cấp bối cảnh về người sử dụng bộ phận hỗ trợ dịch vụ và nhu cầu của họ.

Dù không phải lúc nào cũng là chiều phân tích chính cho luồng quy trình, việc phân tích theo người yêu cầu hoặc phòng ban của họ có thể giúp phát hiện xu hướng. Ví dụ, kết quả có thể cho thấy một phòng ban thường gửi yêu cầu thiếu thông tin, từ đó xác định nhu cầu đào tạo phù hợp. Thuộc tính này cũng cần thiết khi phân tích trải nghiệm khách hàng.

Vì sao điều này quan trọng

Cung cấp bối cảnh về người gửi yêu cầu, giúp phân tích xu hướng theo cá nhân, phòng ban hoặc địa điểm.

Lấy dữ liệu ở đâu

Có trong trường 'requester' trên đối tượng phiếu của Freshservice.

Ví dụ
John DoeJane SmithTài khoản dịch vụ
Phòng ban của người yêu cầu
RequestorDepartment
Phòng ban mà người yêu cầu trực thuộc.
Mô tả

Thuộc tính này cho biết phòng ban của người gửi yêu cầu dịch vụ, chẳng hạn như 'Kinh doanh', 'Tài chính' hoặc 'Nhân sự'. Thông tin này thường lấy từ hồ sơ người dùng trong hệ thống.

Phân tích hiệu suất quy trình theo phòng ban là nhu cầu phổ biến. Việc này có thể cho thấy một số phòng ban mất nhiều thời gian hơn để giải quyết yêu cầu hoặc có nhu cầu xử lý riêng. Kết quả phân tích giúp phân bổ tài nguyên, xây dựng chương trình đào tạo hoặc tạo dịch vụ phù hợp với từng phòng ban.

Vì sao điều này quan trọng

Cho phép phân nhóm quy trình theo đơn vị kinh doanh, giúp xác định vấn đề hoặc khác biệt về hiệu suất ở từng phòng ban.

Lấy dữ liệu ở đâu

Thông tin này được liên kết qua hồ sơ của người yêu cầu. Trong Freshservice, thông tin có thể nằm ở trường 'department' mặc định hoặc trường người dùng tùy chỉnh.

Ví dụ
Tài chínhTiếp thịCông nghệ thông tin
Số lần phân công lại
ReassignmentCount
Tổng số lần yêu cầu dịch vụ được chuyển sang nhân viên hỗ trợ hoặc nhóm khác.
Mô tả

Đây là thuộc tính được tính bằng cách đếm số lần diễn ra hoạt động 'Đã phân công lại yêu cầu' hoặc hoạt động tương tự cho từng yêu cầu dịch vụ. Số lần phân công lại cao thường cho thấy vấn đề ở khâu phân loại ban đầu, định tuyến chưa đúng kỹ năng hoặc khối lượng công việc chưa cân bằng.

Thuộc tính này hỗ trợ trực tiếp cho dashboard 'Hiệu suất và phân bổ khối lượng công việc của nhân viên hỗ trợ' và KPI 'Số lần phân công lại trung bình trên mỗi yêu cầu'. Phân tích chỉ số này giúp tổ chức xác định những điểm yếu trong quy trình khiến phiếu bị chuyển qua lại, làm tăng thời gian giải quyết và gây khó chịu cho cả nhân viên hỗ trợ lẫn người yêu cầu.

Vì sao điều này quan trọng

Đo mức độ kém hiệu quả trong định tuyến và trở ngại trong quy trình. Số lần cao cho thấy vấn đề ở khâu phân loại ban đầu hoặc khối lượng công việc của nhân viên hỗ trợ, dẫn đến chậm trễ.

Lấy dữ liệu ở đâu

Được tính bằng cách đếm các hoạt động thay đổi phân công cụ thể cho từng 'ServiceRequestId' trong quá trình chuyển đổi dữ liệu.

Ví dụ
013
Tên chính sách SLA
SlaPolicyName
Tên chính sách thỏa thuận mức dịch vụ (SLA) áp dụng cho yêu cầu.
Mô tả

Thuộc tính này xác định chính sách SLA cụ thể quy định thời gian phản hồi và giải quyết mục tiêu cho yêu cầu dịch vụ. Chính sách thường dựa trên các yếu tố như mức độ ưu tiên, loại dịch vụ hoặc nhóm người yêu cầu.

Việc biết chính sách SLA nào được áp dụng là cần thiết cho dashboard Phân tích tuân thủ và vi phạm SLA. Thông tin này giúp đo chính xác hiệu suất so với mục tiêu đã đặt ra và xác định chính sách nào thường bị vi phạm. Từ đó, tổ chức có thể xem xét lại hiệu suất quy trình hoặc tính khả thi của chính các mục tiêu SLA.

Vì sao điều này quan trọng

Xác định mục tiêu dịch vụ dùng để đo lường yêu cầu, cần thiết để báo cáo chính xác mức độ tuân thủ SLA.

Lấy dữ liệu ở đâu

Thông tin này nằm trong dữ liệu SLA liên kết với phiếu. Có thể cần truy vấn các trường hoặc điểm cuối API dành riêng cho SLA.

Ví dụ
Sự cố ưu tiên cao - 4 giờYêu cầu thông thường - 3 ngàyHỗ trợ VIP - 1 giờ
Thời điểm kết thúc
EndTime
Dấu thời gian chính xác khi hoạt động hoàn tất.
Mô tả

Thời điểm kết thúc là dấu thời gian ghi nhận lúc một hoạt động hoàn tất. Với nhiều sự kiện trong Freshservice, thời điểm bắt đầu và kết thúc giống nhau vì sự kiện chỉ diễn ra tại một thời điểm. Tuy nhiên, với hoạt động dựa trên trạng thái, thời điểm kết thúc là lúc trạng thái tiếp theo thay đổi.

Thuộc tính này cần thiết để tính thời lượng hoạt động và thời gian chờ giữa các hoạt động. Lấy EndTime trừ StartTime sẽ cho biết thời gian xử lý của một tác vụ cụ thể. Đây là cơ sở để xác định hoạt động nào tốn nhiều thời gian nhất và nên được ưu tiên cải tiến.

Vì sao điều này quan trọng

Giúp tính thời lượng hoạt động, yếu tố quan trọng để xác định điểm nghẽn và đo thời gian xử lý của từng bước.

Lấy dữ liệu ở đâu

Đây không phải trường có sẵn trong nhật ký Freshservice. Cần suy ra thời điểm này từ dấu thời gian của sự kiện tiếp theo trong chuỗi sự kiện của từng yêu cầu dịch vụ.

Ví dụ
2023-10-26T10:05:15Z2023-10-26T14:00:20Z2023-10-28T09:30:00Z
Bắt buộc Nên có Không bắt buộc

Hoạt động quản lý yêu cầu dịch vụ

Đây là các bước và mốc chính cần ghi lại trong nhật ký sự kiện để khám phá và phân tích chính xác quy trình làm việc xử lý yêu cầu dịch vụ.
6 Nên có 9 Không bắt buộc
Hoạt động Mô tả
Chuyển yêu cầu cho nhà cung cấp bên ngoài
Hoạt động này đánh dấu thời điểm phiếu được chuyển cho nhà cung cấp bên ngoài hoặc bên thứ ba xử lý. Có thể suy ra hoạt động từ việc trạng thái chuyển sang một giá trị cụ thể như 'Chờ nhà cung cấp' hoặc 'Chờ bên thứ ba'.
Vì sao điều này quan trọng

Việc phối hợp với nhà cung cấp có thể gây chậm trễ đáng kể. Theo dõi hoạt động này là cần thiết để đo hiệu quả của nhà cung cấp và ảnh hưởng đến tổng thời gian xử lý yêu cầu dịch vụ.

Lấy dữ liệu ở đâu

Có thể suy ra từ lịch sử thay đổi trạng thái của phiếu. Tìm trạng thái được cấu hình riêng để theo dõi việc phụ thuộc vào nhà cung cấp bên ngoài.

Thu thập

Phát hiện khi trường trạng thái phiếu chuyển sang giá trị cho biết đang chờ bên thứ ba.

Loại sự kiện inferred
Đóng yêu cầu dịch vụ
Đây là hoạt động cuối cùng, đánh dấu kết thúc vòng đời yêu cầu dịch vụ. Thông thường, yêu cầu được đóng tự động sau một khoảng thời gian ở trạng thái 'Đã giải quyết' nếu không bị mở lại.
Vì sao điều này quan trọng

Sự kiện này đánh dấu kết thúc chính thức của một trường hợp quy trình. Khoảng thời gian từ 'Đã giải quyết' đến 'Đã đóng' là thời gian để người gửi xác nhận kết quả.

Lấy dữ liệu ở đâu

Có thể suy ra từ lịch sử thay đổi trạng thái của phiếu. Đây là dấu thời gian trạng thái chuyển thành 'Đã đóng'.

Thu thập

Ghi nhận dấu thời gian khi trạng thái phiếu chuyển thành 'Đã đóng'.

Loại sự kiện inferred
Giải quyết yêu cầu dịch vụ
Mốc quan trọng này đánh dấu thời điểm nhân viên hỗ trợ đưa ra giải pháp và xem công việc đã hoàn tất. Có thể suy ra hoạt động từ việc trạng thái phiếu chuyển thành 'Đã giải quyết'.
Vì sao điều này quan trọng

Hoạt động này đánh dấu kết thúc giai đoạn xử lý chính. Thời gian đến mốc này là thước đo quan trọng về hiệu quả của nhân viên và quy trình, đồng thời là cơ sở tính SLA.

Lấy dữ liệu ở đâu

Có thể suy ra từ lịch sử thay đổi trạng thái của phiếu. Đây là dấu thời gian lần đầu trạng thái được đặt thành 'Đã giải quyết'.

Thu thập

Ghi nhận dấu thời gian khi trạng thái phiếu lần đầu chuyển thành 'Đã giải quyết'.

Loại sự kiện inferred
Giao yêu cầu cho nhân viên hỗ trợ
Đánh dấu thời điểm yêu cầu dịch vụ được giao cho một nhân viên hỗ trợ cụ thể. Đây là mốc quan trọng, có thể xác định bằng cách theo dõi thay đổi trong trường 'Nhân viên được giao' hoặc 'Người phụ trách' của phiếu.
Vì sao điều này quan trọng

Hoạt động này rất quan trọng để phân tích khối lượng công việc của nhân viên và xác định điểm nghẽn trong khâu phân công. Thời gian từ lúc tạo yêu cầu đến khi giao cho nhân viên là một chỉ số hiệu quả quan trọng.

Lấy dữ liệu ở đâu

Có thể suy ra từ nhật ký hoạt động hoặc lịch sử kiểm tra trường của phiếu bằng cách theo dõi thay đổi trong trường 'Nhân viên hỗ trợ' hoặc 'Người được giao'.

Thu thập

Ghi nhận dấu thời gian khi trường 'Nhân viên được giao' có giá trị hoặc khi giá trị này thay đổi.

Loại sự kiện inferred
Tạo yêu cầu dịch vụ
Hoạt động này đánh dấu thời điểm bắt đầu vòng đời yêu cầu dịch vụ, khi yêu cầu mới được ghi nhận chính thức trên Freshservice. Sự kiện được ghi lại khi tạo bản ghi phiếu mới, qua danh mục dịch vụ, email hoặc kênh khác, đồng thời hệ thống cấp một mã yêu cầu dịch vụ riêng.
Vì sao điều này quan trọng

Đây là sự kiện bắt đầu chính của quy trình. Phân tích thời gian từ hoạt động này đến các hoạt động khác là cơ sở để đo tổng thời gian xử lý và xác định chậm trễ ở giai đoạn đầu.

Lấy dữ liệu ở đâu

Sự kiện này được ghi lại trực tiếp trên Freshservice. Bạn có thể tìm thấy sự kiện trong nhật ký hoạt động hoặc lịch sử kiểm tra của phiếu, thường trùng với dấu thời gian tạo phiếu.

Thu thập

Dùng dấu thời gian tạo phiếu trong dữ liệu phiếu Freshservice.

Loại sự kiện explicit
Vi phạm thời hạn SLA
Đây là sự kiện được tính khi thời gian xử lý yêu cầu dịch vụ vượt quá mục tiêu trong thỏa thuận mức dịch vụ (SLA). Sự kiện này không được hệ thống ghi trực tiếp mà được xác định bằng cách so sánh thời gian xử lý với hạn SLA.
Vì sao điều này quan trọng

Sự kiện này đo trực tiếp hiệu quả dịch vụ so với cam kết và là KPI quan trọng cho công tác quản lý. Sự kiện giúp xác định loại yêu cầu hoặc mức độ ưu tiên nào có nguy cơ không đạt mục tiêu cao nhất.

Lấy dữ liệu ở đâu

Tính bằng cách so sánh dấu thời gian 'Đã giải quyết' với dấu thời gian 'Hạn SLA'. Nếu thời gian giải quyết muộn hơn hạn, sự kiện này được ghi nhận.

Thu thập

So sánh dấu thời gian giải quyết với dấu thời gian hạn SLA. Nếu resolved_at > sla_due_by, hãy tạo sự kiện này.

Loại sự kiện calculated
Chuyển yêu cầu sang nhân viên khác
Hoạt động này ghi nhận mọi thay đổi về nhân viên hoặc nhóm được giao sau lần phân công đầu tiên. Có thể suy ra hoạt động bằng cách phát hiện các lần cập nhật tiếp theo trong trường 'Nhân viên được giao' hoặc 'Nhóm được giao'.
Vì sao điều này quan trọng

Việc chuyển giao thường xuyên có thể cho thấy vấn đề trong khâu phân loại ban đầu, ghép yêu cầu với kỹ năng của nhân viên hoặc cân bằng khối lượng công việc. Hoạt động này rất quan trọng đối với KPI số lần chuyển yêu cầu giữa nhân viên và phân tích việc xử lý lại.

Lấy dữ liệu ở đâu

Có thể suy ra từ lịch sử thay đổi trường của phiếu. Sự kiện được ghi lại mỗi khi trường 'Nhân viên được giao' hoặc 'Nhóm được giao' được cập nhật sau lần thiết lập giá trị ban đầu.

Thu thập

Phát hiện mọi thay đổi trong trường 'Nhân viên được giao' hoặc 'Nhóm được giao' sau lần phân công đầu tiên.

Loại sự kiện inferred
Mở lại yêu cầu dịch vụ
Hoạt động này diễn ra khi người gửi cho biết vấn đề vẫn còn sau khi yêu cầu được đánh dấu 'Đã giải quyết', khiến phiếu chuyển lại trạng thái đang mở. Có thể suy ra hoạt động từ việc trạng thái chuyển từ 'Đã giải quyết' về 'Đang mở' hoặc 'Đang xử lý'.
Vì sao điều này quan trọng

Yêu cầu được mở lại thường cho thấy tỷ lệ giải quyết ngay lần đầu thấp và khách hàng chưa hài lòng. Theo dõi vòng xử lý lại này rất quan trọng để nâng cao chất lượng giải pháp.

Lấy dữ liệu ở đâu

Có thể suy ra từ lịch sử thay đổi trạng thái của phiếu trong nhật ký hoạt động. Đây là lần chuyển trạng thái trực tiếp từ 'Đã giải quyết' sang 'Đang mở'.

Thu thập

Phát hiện khi trạng thái chuyển từ đã giải quyết sang đang mở.

Loại sự kiện inferred
Người gửi cung cấp thông tin
Hoạt động này diễn ra khi người gửi phản hồi và cung cấp thông tin cần thiết để nhân viên tiếp tục xử lý. Thông thường, có thể suy ra hoạt động khi trạng thái phiếu tự động chuyển từ 'Đang chờ' về 'Đang mở'.
Vì sao điều này quan trọng

Hoạt động này khép lại vòng yêu cầu bổ sung thông tin. Thời gian từ lúc yêu cầu đến khi nhận được thông tin là thời gian chờ quan trọng cần phân tích và cải thiện.

Lấy dữ liệu ở đâu

Có thể suy ra từ việc trạng thái chuyển từ 'Đang chờ' về 'Đang mở' hoặc 'Đang xử lý', thường là sau khi người gửi phản hồi.

Thu thập

Phát hiện khi trạng thái phiếu chuyển từ trạng thái đang chờ sang đang mở.

Loại sự kiện inferred
Người gửi xác nhận đã giải quyết xong
Hoạt động này thể hiện người gửi xác nhận rõ ràng rằng giải pháp được cung cấp đáp ứng yêu cầu. Có thể suy ra hoạt động từ phản hồi tích cực trong khảo sát hoặc một bình luận cụ thể trước khi đóng phiếu.
Vì sao điều này quan trọng

Xác nhận của người gửi cung cấp phản hồi trực tiếp về chất lượng giải pháp. Tỷ lệ xác nhận thấp có thể cho thấy giải pháp chưa đáp ứng đầy đủ nhu cầu của người dùng, ngay cả khi yêu cầu không bị mở lại.

Lấy dữ liệu ở đâu

Khó ghi nhận trực tiếp hoạt động này và có thể cần cấu hình riêng. Có thể suy ra hoạt động từ phản hồi khảo sát mức độ hài lòng của khách hàng gắn với phiếu hoặc một thẻ cụ thể được thêm vào.

Thu thập

Cần phân tích dữ liệu liên quan như khảo sát mức độ hài lòng hoặc thẻ được thêm sau khi giải quyết.

Loại sự kiện inferred
Phân loại yêu cầu ban đầu
Đây là bước đánh giá và phân loại ban đầu đối với yêu cầu dịch vụ mới. Thông thường, có thể suy ra hoạt động này từ lần đầu thiết lập mức độ ưu tiên hoặc phân yêu cầu vào một nhóm, cho thấy yêu cầu đã được xem xét và đưa vào hàng đợi.
Vì sao điều này quan trọng

Theo dõi bước phân loại ban đầu giúp đo hiệu quả của nhóm tiếp nhận. Chậm trễ ở giai đoạn này có thể ảnh hưởng đáng kể đến tổng thời gian xử lý và mức độ tuân thủ SLA.

Lấy dữ liệu ở đâu

Có thể suy ra từ nhật ký hoạt động. Xác định dấu thời gian của sự kiện 'Đặt mức độ ưu tiên' hoặc 'Phân vào nhóm' đầu tiên sau khi tạo yêu cầu.

Thu thập

Xác định dấu thời gian sớm nhất của lần thay đổi trường mức độ ưu tiên hoặc trường nhóm được phân công.

Loại sự kiện inferred
Rà soát nội bộ
Hoạt động này cho biết giải pháp đề xuất hoặc yêu cầu cung cấp dịch vụ cần được rà soát hoặc phê duyệt nội bộ trước khi tiếp tục. Có thể suy ra hoạt động từ việc trạng thái chuyển sang giá trị như 'Chờ phê duyệt' hoặc 'Đang rà soát nội bộ'.
Vì sao điều này quan trọng

Rà soát nội bộ có thể tạo ra điểm nghẽn, nhất là với yêu cầu dịch vụ phức tạp hoặc có ảnh hưởng lớn. Đo thời lượng khâu này giúp tinh gọn quy trình phê duyệt.

Lấy dữ liệu ở đâu

Có thể suy ra từ lịch sử thay đổi trạng thái của phiếu. Quy trình cần sử dụng trạng thái cụ thể như 'Chờ phê duyệt nội bộ'.

Thu thập

Phát hiện khi trường trạng thái phiếu chuyển sang giá trị cho biết đang rà soát hoặc chờ phê duyệt nội bộ.

Loại sự kiện inferred
Thêm ghi chú
Đây là mọi ghi chú công khai hoặc riêng tư do nhân viên hỗ trợ hoặc người gửi thêm vào yêu cầu dịch vụ. Sự kiện được ghi trực tiếp trong cuộc trò chuyện hoặc nhật ký hoạt động của phiếu.
Vì sao điều này quan trọng

Phân tích tần suất và thời điểm thêm ghi chú có thể cho thấy cách trao đổi, hiệu quả phối hợp và những chỗ gây nhầm lẫn trong quy trình.

Lấy dữ liệu ở đâu

Ghi chú được lưu trực tiếp trong lịch sử trao đổi của phiếu trên Freshservice. Mỗi ghi chú có dấu thời gian và tên người viết.

Thu thập

Trích xuất từng mục trong nhật ký trao đổi hoặc bình luận của phiếu.

Loại sự kiện explicit
Ưu tiên yêu cầu
Hoạt động này diễn ra khi yêu cầu dịch vụ được gán mức độ ưu tiên như Thấp, Trung bình hoặc Cao. Có thể suy ra hoạt động bằng cách phát hiện thay đổi trong trường 'Mức độ ưu tiên' ở lịch sử phiếu.
Vì sao điều này quan trọng

Ưu tiên yêu cầu rất quan trọng để phân bổ tài nguyên và đảm bảo đạt mục tiêu SLA. Phân tích hoạt động này giúp xác minh yêu cầu được đánh giá chính xác và đúng lúc.

Lấy dữ liệu ở đâu

Có thể suy ra từ lịch sử thay đổi trường của phiếu trên Freshservice. Tìm các lần cập nhật trường 'Mức độ ưu tiên' và ghi nhận dấu thời gian thay đổi.

Thu thập

Phát hiện khi trường 'Mức độ ưu tiên' thay đổi từ giá trị rỗng hoặc giá trị trước đó, rồi ghi lại dấu thời gian.

Loại sự kiện inferred
Yêu cầu người gửi bổ sung thông tin
Hoạt động này diễn ra khi nhân viên được giao cần người gửi cung cấp thêm thông tin và tạm dừng xử lý. Có thể suy ra hoạt động từ việc trạng thái phiếu chuyển sang 'Đang chờ' hoặc 'Chờ khách hàng'.
Vì sao điều này quan trọng

Hoạt động này cho thấy một nguyên nhân phổ biến gây chậm trễ và phải xử lý lại. Phân tích tần suất giúp tìm cơ hội cải thiện mẫu yêu cầu và cách thu thập thông tin ban đầu.

Lấy dữ liệu ở đâu

Có thể suy ra từ lịch sử thay đổi trạng thái của phiếu. Tìm trạng thái như 'Chờ khách hàng phản hồi' hoặc 'Chờ bổ sung thông tin'.

Thu thập

Phát hiện khi trường trạng thái phiếu chuyển sang giá trị cho biết đang chờ người dùng cung cấp thông tin.

Loại sự kiện inferred
Nên có Không bắt buộc

Hướng dẫn trích xuất dữ liệu

Cách lấy dữ liệu từ Freshservice

Sẵn sàng bắt đầu?

Hãy chuẩn bị dữ liệu để bắt đầu tối ưu hóa quy trình quản lý yêu cầu dịch vụ. Chúng tôi sẵn sàng hỗ trợ bạn cải thiện hoạt động cung cấp dịch vụ.

Cải thiện hiệu quả xử lý yêu cầu dịch vụ trong Freshservice ngay hôm nay

Giảm thời gian xử lý kéo dài và sự bất mãn của người dùng, đạt mức tự động hóa 70%.

Bắt đầu dùng thử miễn phí

Không cần thẻ tín dụng. Thiết lập chỉ trong vài phút.