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ụ
- Các thuộc tính nên có để phân tích đầy đủ
- Các hoạt động yêu cầu dịch vụ chính cần theo dõi
- Hướng dẫn trích xuất dữ liệu từ Zendesk Support
Thuộc tính quản lý yêu cầu dịch vụ
| Tên | Mô tả | ||
|---|---|---|---|
|
Hoạt động
ActivityName
|
Tên hoạt động nghiệp vụ hoặc sự kiện xảy ra trong quá trình xử lý yêu cầu dịch vụ. | ||
|
Mô tả
Hoạt động là một bước hoặc sự kiện riêng biệt trong vòng đời yêu cầu dịch vụ, chẳng hạn như 'Tạo yêu cầu dịch vụ', 'Phân công yêu cầu cho nhân viên hỗ trợ' hoặc 'Giải quyết yêu cầu dịch vụ'. Các hoạt động này được xác định từ những thay đổi ghi trong nhật ký kiểm tra ticket Zendesk, nơi theo dõi các trường như trạng thái, người được giao xử lý, mức độ ưu tiên và việc thêm bình luận. Phân tích hoạt động là trọng tâm của process mining. Việc này giúp trực quan hóa sơ đồ quy trình, tìm điểm nghẽn giữa các bước và phân tích các vòng lặp làm lại. Khi hiểu trình tự và tần suất hoạt động, tổ chức có thể phát hiện điểm kém hiệu quả và cơ hội cải tiến quy trình.
Vì sao điều này quan trọng
Thuộc tính này xác định các bước trong quy trình, giúp trực quan hóa sơ đồ quy trình và phân tích luồng, biến thể cũng như mức độ tuân thủ quy trình.
Lấy dữ liệu ở đâu
Về mặt khái niệm, thuộc tính này được xác định từ các sự kiện ghi trong Zendesk Ticket Audits API. Ví dụ, thay đổi trường 'status' từ 'new' sang 'open' có thể được ánh xạ thành hoạt động như 'Phân loại yêu cầu'.
Ví dụ
Tạo yêu cầu dịch vụChuyển yêu cầu sang nhân viên hỗ trợ khácGiải quyết yêu cầu dịch vụ
|
|||
|
Mã yêu cầu dịch vụ
ServiceRequestId
|
Mã định danh duy nhất của từng ticket yêu cầu dịch vụ trong Zendesk. | ||
|
Mô tả
Mã yêu cầu dịch vụ, thường được gọi là Ticket ID trong Zendesk, là khóa chính của mỗi hồ sơ. Mã này liên kết mọi hoạt động, bình luận và thay đổi trạng thái liên quan, từ lúc tạo yêu cầu đến khi đóng. Nhờ đó, bạn có thể theo dõi toàn bộ vòng đời của một yêu cầu. Trong phân tích process mining, thuộc tính này giữ vai trò nền tảng. Mã này xác định từng hồ sơ, giúp tái dựng luồng quy trình, nhận diện các biến thể và tính chỉ số ở cấp hồ sơ như thời gian chu kỳ. Mỗi sự kiện trong tập dữ liệu phải gắn với một mã yêu cầu dịch vụ để xác định đúng ngữ cảnh trong toàn bộ quy trình.
Vì sao điều này quan trọng
Đây là mã định danh thiết yếu, liên kết mọi sự kiện trong quá trình xử lý yêu cầu dịch vụ và giúp phân tích quy trình từ đầu đến cuối.
Lấy dữ liệu ở đâu
Zendesk Tickets API, trường 'id'.
Ví dụ
102451024610247
|
|||
|
Thời gian bắt đầu
EventTimestamp
|
Ngày và giờ chính xác khi hoạt động xảy ra. | ||
|
Mô tả
Dấu thời gian sự kiện, hay Thời gian bắt đầu, ghi lại chính xác thời điểm một hoạt động diễn ra. Ví dụ, thuộc tính này ghi nhận lúc phân công nhân viên hỗ trợ, gửi phản hồi công khai hoặc chuyển trạng thái ticket thành 'Resolved'. Dữ liệu thời gian này lấy từ nhật ký kiểm tra của từng ticket Zendesk. Thuộc tính này rất quan trọng trong mọi phân tích theo thời gian. Bạn có thể dùng thuộc tính này để sắp xếp sự kiện theo trình tự thời gian, tính khoảng cách giữa các hoạt động, đo thời gian chờ và phân tích tổng thời gian chu kỳ của hồ sơ. Đây cũng là cơ sở để tìm điểm nghẽn và đánh giá hiệu suất theo các mục tiêu thời gian như SLA.
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à dữ liệu thiết yếu để phân tích thời lượng, hiệu suất và điểm nghẽn.
Lấy dữ liệu ở đâu
Zendesk Ticket Audits API, trường 'created_at' của từng sự kiện kiểm tra.
Ví dụ
2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
|
|||
|
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 nguồn gốc của dữ liệu yêu cầu dịch vụ. Trong chế độ xem quy trình này, giá trị luôn là 'Zendesk Support', tức hệ thống lưu trữ dữ liệu chính thức cho mọi hoạt động quản lý dịch vụ. Khi có nhiều hệ thống được tích hợp, trường này rất quan trọng để theo dõi nguồn gốc dữ liệu và xử lý sự cố. Trường này giúp giới hạn phân tích đúng vào hệ thống cần xem và phân biệt dữ liệu khi kết hợp từ nhiều nguồn.
Vì sao điều này quan trọng
Xác định hệ thống nguồn của dữ liệu, giúp theo dõi nguồn gốc và tránh nhầm lẫn khi kết hợp dữ liệu từ nhiều hệ thống.
Lấy dữ liệu ở đâu
Đây là giá trị cố định ('Zendesk Support'), được thêm trong quá trình trích xuất và chuyển đổi dữ liệu.
Ví dụ
Zendesk Support
|
|||
|
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 dữ liệu được trích xuất từ Zendesk Support. Nhờ đó, bạn biết dữ liệu đang phân tích mới đến đâu và chế độ xem quy trình được cập nhật vào thời điểm nào. Thông tin này rất cần thiết khi theo dõi liên tục và dùng dashboard. Chuyên viên phân tích và người dùng nghiệp vụ có thể biết dữ liệu gần như theo thời gian thực hay chỉ là ảnh chụp từ một giai đoạn trước. Điều này ảnh hưởng đến độ tin cậy của kết luận.
Vì sao điều này quan trọng
Cho biết dữ liệu mới đến đâu, giúp người dùng nắm được mức độ cập nhật của kết quả phân tích.
Lấy dữ liệu ở đâu
Đây là trường siêu dữ liệu được tạo và gắn vào tập dữ liệu khi trích xuất.
Ví dụ
2023-10-27T08:00:00Z
|
|||
|
Kênh tiếp nhận yêu cầu
RequestChannel
|
Kênh gửi yêu cầu dịch vụ, chẳng hạn email, biểu mẫu web hoặc điện thoại. | ||
|
Mô tả
Thuộc tính này cho biết yêu cầu dịch vụ được gửi qua kênh nào. Zendesk ghi nhận cách tạo ticket, chẳng hạn qua email, cổng web, tích hợp API, chat hoặc kênh khác. Thông tin này cho biết khách hàng đã liên hệ bằng cách nào. Kênh tiếp nhận yêu cầu là một chiều phân tích hữu ích. Thuộc tính này hỗ trợ dashboard 'Hiệu quả kênh tiếp nhận yêu cầu', giúp so sánh thời gian giải quyết, điểm hài lòng và tỷ lệ làm lại giữa các kênh. Nhờ đó, doanh nghiệp có thể tối ưu kênh hỗ trợ và hướng người dùng đến kênh hiệu quả hơn.
Vì sao điều này quan trọng
Giúp phân tích hiệu quả và kết quả của từng kênh hỗ trợ khách hàng, từ đó xác định cải tiến phù hợp.
Lấy dữ liệu ở đâu
Zendesk Tickets API, đối tượng 'via' và thuộc tính 'channel'.
Ví dụ
webemailapichat
|
|||
|
Loại yêu cầu dịch vụ
ServiceType
|
Danh mục hoặc loại yêu cầu dịch vụ, chẳng hạn Sự cố, Câu hỏi, Vấn đề hoặc Tác vụ. | ||
|
Mô tả
Loại yêu cầu dịch vụ phân loại nội dung của yêu cầu. Zendesk dùng trường 'type' để phân biệt các loại tương tác hỗ trợ. Việc phân loại ban đầu giúp định tuyến ticket đến đúng nhóm và áp dụng quy trình phù hợp. Thuộc tính này rất cần thiết để lọc và so sánh. Chuyên viên phân tích có thể xem luồng quy trình của từng loại yêu cầu, vốn thường có cách giải quyết và SLA rất khác nhau. Đây là chiều phân tích chính trong dashboard Hiệu suất nhân viên và nhóm, giúp xác định ai xử lý tốt từng loại yêu cầu.
Vì sao điều này quan trọng
Phân loại yêu cầu để phân tích riêng từng quy trình, chẳng hạn sự cố và câu hỏi, vốn đi theo các luồng khác nhau.
Lấy dữ liệu ở đâu
Zendesk Tickets API, trường 'type'.
Ví dụ
câu hỏisự cốvấn đềtác vụ
|
|||
|
Mức độ ưu tiên của yêu cầu
RequestPriority
|
Mức độ ưu tiên được gán cho yêu cầu dịch vụ, chẳng hạn Thấp, Bình thường, Cao hoặc Khẩn cấp. | ||
|
Mô tả
Mức độ ưu tiên của yêu cầu cho biết yêu cầu dịch vụ khẩn cấp đến đâu. Mức này thường quyết định thời hạn giải quyết mục tiêu và chính sách SLA áp dụng cho ticket. Hệ thống hoặc người dùng có thể đặt mức ưu tiên ban đầu, sau đó nhân viên hỗ trợ có thể thay đổi trong vòng đời ticket. Thuộc tính này rất quan trọng để phân nhóm và tìm nguyên nhân gốc rễ. Bạn có thể phân tích xem ticket ưu tiên cao có được giải quyết nhanh hơn ticket ưu tiên thấp hay không. Đây cũng là chiều phân tích chính trong các dashboard 'Xu hướng chuyển cấp yêu cầu dịch vụ' và 'Mức độ đáp ứng SLA'.
Vì sao điều này quan trọng
Cho phép phân nhóm yêu cầu theo mức độ khẩn cấp, rất cần thiết để phân tích việc tuân thủ SLA và đảm bảo vấn đề cấp bách được xử lý kịp thời.
Lấy dữ liệu ở đâu
Zendesk Tickets API, trường 'priority'.
Ví dụ
ThấpBình thườngCaoKhẩn cấp
|
|||
|
Nhóm được giao xử lý
AssignedTeam
|
Nhóm hoặc bộ phận hỗ trợ được giao xử lý yêu cầu dịch vụ. | ||
|
Mô tả
Thuộc tính này cho biết nhóm hoặc bộ phận nào trong tổ chức hỗ trợ chịu trách nhiệm xử lý yêu cầu dịch vụ. Trong Zendesk, các nhóm này được gọi là 'Groups'. Ticket thường được giao cho một nhóm trước khi một nhân viên cụ thể tiếp nhận. Phân tích theo Nhóm được giao xử lý giúp bạn hiểu hiệu suất và khối lượng công việc ở cấp nhóm. Bạn có thể biết nhóm nào xử lý loại yêu cầu nào, thời gian giải quyết trung bình và tỷ lệ đáp ứng SLA của từng nhóm. Đây là chiều phân tích chính trong dashboard Hiệu suất nhân viên và nhóm.
Vì sao điều này quan trọng
Giúp phân tích hiệu suất nhóm, cân bằng khối lượng công việc và hiệu quả định tuyến giữa các nhóm hỗ trợ.
Lấy dữ liệu ở đâu
Zendesk Groups API, bằng cách kết hợp 'group_id' từ phản hồi của Tickets API.
Ví dụ
Hỗ trợ cấp 1Hỗ trợ kỹ thuậtThanh toán
|
|||
|
Tên nhân viên hỗ trợ
AgentName
|
Tên nhân viên hỗ trợ được giao xử lý yêu cầu dịch vụ tại thời điểm sự kiện xảy ra. | ||
|
Mô tả
Thuộc tính này xác định nhân viên hỗ trợ chịu trách nhiệm xử lý yêu cầu dịch vụ. Người được giao có thể thay đổi nhiều lần trong vòng đời ticket. Trường này ghi lại người phụ trách ở từng bước. Tên nhân viên hỗ trợ rất quan trọng khi phân tích hiệu suất. Bạn có thể lọc và phân nhóm dữ liệu để đánh giá cách phân bổ khối lượng công việc, thời gian giải quyết của từng nhân viên và tần suất chuyển giao. Thông tin này giúp xây dựng dashboard Hiệu suất nhân viên và nhóm, đồng thời hiểu rõ đóng góp của từng người vào hiệu quả chung của quy trình.
Vì sao điều này quan trọng
Thuộc tính này rất cần thiết để phân tích hiệu suất nhân viên hỗ trợ, phân bổ khối lượng công việc và ảnh hưởng của việc chuyển giao đến thời gian giải quyết.
Lấy dữ liệu ở đâu
Zendesk Users API, bằng cách kết hợp 'assignee_id' từ phản hồi của Tickets API.
Ví dụ
Jane DoeJohn SmithEmily Jones
|
|||
|
Thẻ ticket
TicketTags
|
Danh sách thẻ gắn với yêu cầu dịch vụ để phân loại và định tuyến. | ||
|
Mô tả
Thẻ là nhãn linh hoạt mà nhân viên hỗ trợ có thể thêm vào ticket theo cách thủ công hoặc tự động thông qua quy tắc nghiệp vụ. Thẻ bổ sung ngữ cảnh hoặc danh mục cụ thể chưa có trong các trường tiêu chuẩn như Loại hoặc Mức độ ưu tiên. Thẻ rất linh hoạt khi phân tích process mining. Bạn có thể dùng thẻ để lọc các tình huống cụ thể, theo dõi quy trình làm việc tùy chỉnh hoặc tìm nguyên nhân gốc rễ. Ví dụ, thẻ 'VIP' giúp phân tích quy trình cho khách hàng quan trọng, còn thẻ 'product_bug' giúp theo dõi vòng đời báo cáo lỗi sản phẩm.
Vì sao điều này quan trọng
Cho phép phân nhóm dữ liệu linh hoạt để phân tích sâu các quy trình con hoặc thuộc tính ticket không có trong những trường khác.
Lấy dữ liệu ở đâu
Zendesk Tickets API, trường 'tags'. Đây là một mảng chuỗi.
Ví dụ
sales_inquirybilling_issuefeature_requestvip_customer
|
|||
|
Trạng thái yêu cầu
RequestStatus
|
Trạng thái của yêu cầu dịch vụ tại thời điểm xảy ra sự kiện, chẳng hạn Mới, Đang mở hoặc Đang chờ. | ||
|
Mô tả
Trạng thái yêu cầu cho biết tình trạng của ticket tại một thời điểm cụ thể. Zendesk có một số trạng thái tiêu chuẩn như New, Open, Pending, On-hold, Solved và Closed, thể hiện tiến trình xử lý yêu cầu. Các thay đổi ở trường này là căn cứ chính để tạo hoạt động trong nhật ký sự kiện. Phân tích thời gian ở từng trạng thái là phần cốt lõi khi tìm điểm nghẽn. Việc này giúp xác định ticket bị đình trệ ở đâu, chẳng hạn mất quá nhiều thời gian ở trạng thái 'Pending' hoặc 'On-hold'. Hiểu các lần chuyển trạng thái cũng rất quan trọng để phát hiện vòng lặp làm lại.
Vì sao điều này quan trọng
Theo dõi trạng thái là điều cần thiết để hiểu tiến độ xử lý yêu cầu và xác định thời gian ở trạng thái chờ hoặc đang xử lý.
Lấy dữ liệu ở đâu
Zendesk Tickets API, trường 'status'.
Ví dụ
MớiĐang mởĐang chờĐã giải quyếtĐã đóng
|
|||
|
Có làm lại không
IsRework
|
Cờ có giá trị đúng nếu yêu cầu dịch vụ được mở lại sau khi đã giải quyết. | ||
|
Mô tả
Cờ dạng đúng/sai này xác định các trường hợp phải làm lại. Yêu cầu dịch vụ thường được xem là phải làm lại nếu trạng thái chuyển từ “Đã giải quyết” về trạng thái đang mở. Điều này cho thấy cách xử lý ban đầu chưa đáp ứng yêu cầu và khách hàng phải liên hệ lại về cùng vấn đề. Thuộc tính này cần thiết để tính KPI “Tỷ lệ yêu cầu dịch vụ phải làm lại” và dùng trong bảng điều khiển “Phân tích hoạt động làm lại và mở lại”. Khi đánh dấu các trường hợp này, chuyên viên phân tích có thể tách riêng những luồng quy trình kém hiệu quả, tìm nguyên nhân khiến yêu cầu được mở lại và cải thiện tỷ lệ giải quyết ngay từ lần liên hệ đầu tiên.
Vì sao điều này quan trọng
Phát hiện các trường hợp xử lý chưa dứt điểm, qua đó làm rõ vấn đề về chất lượng và hiệu quả ảnh hưởng trực tiếp đến mức độ hài lòng của khách hàng.
Lấy dữ liệu ở đâu
Được tính bằng cách phân tích chuỗi trạng thái của phiếu yêu cầu trong Zendesk Ticket Audits API. Trạng thái chuyển từ 'solved' sang 'open' cho biết yêu cầu phải làm lại.
Ví dụ
truefalse
|
|||
|
Có vi phạm SLA không
IsSlaBreached
|
Cờ cho biết yêu cầu dịch vụ có vi phạm mục tiêu SLA nào hay không. | ||
|
Mô tả
Thuộc tính này là cờ dạng đúng/sai hoặc phân loại, cho biết kết quả SLA của phiếu yêu cầu. Các trạng thái có thể gồm “Đạt”, “Vi phạm” hoặc “Đang xử lý”. Kết quả được xác định bằng cách so sánh thời gian phản hồi hoặc xử lý thực tế với mục tiêu trong chính sách SLA được áp dụng. Đây là thuộc tính quan trọng trong bảng điều khiển “Phân tích mức độ đáp ứng và vi phạm SLA”. Thuộc tính này giúp đếm và trực quan hóa các phiếu yêu cầu tuân thủ hoặc không tuân thủ. Sau đó, bạn có thể phân tích đặc điểm quy trình của các phiếu vi phạm để tìm nguyên nhân gốc rễ, chẳng hạn như thời gian chờ lâu hoặc bị chuyển giao quá nhiều lần.
Vì sao điều này quan trọng
Đo trực tiếp hiệu quả so với cam kết về mức dịch vụ, qua đó phản ánh chất lượng dịch vụ và mức độ hài lòng của khách hàng.
Lấy dữ liệu ở đâu
Lấy từ Zendesk Ticket Metrics API, nơi cung cấp thông tin về trạng thái SLA của từng phiếu yêu cầu.
Ví dụ
ĐạtVi phạmĐang xử lý
|
|||
|
Điểm hài lòng
SatisfactionRating
|
Điểm hài lòng do người yêu cầu cung cấp sau khi ticket được giải quyết. | ||
|
Mô tả
Thuộc tính này ghi nhận phản hồi của khách hàng về trải nghiệm hỗ trợ, thường qua khảo sát sau khi ticket được đánh dấu đã giải quyết. Các mức đánh giá phổ biến gồm 'Tốt' hoặc 'Không tốt', đôi khi kèm bình luận. Điểm hài lòng là chỉ số quan trọng về kết quả. Đối chiếu các mẫu quy trình với điểm hài lòng có thể cho thấy cách xử lý nào khiến khách hàng hài lòng hoặc không hài lòng. Ví dụ, phân tích có thể cho thấy tỷ lệ chuyển giao cao hoặc thời gian giải quyết lâu thường đi kèm điểm hài lòng thấp.
Vì sao điều này quan trọng
Liên kết trực tiếp cách thực hiện quy trình với kết quả của khách hàng, giúp xác định cách xử lý nào tác động đến mức độ hài lòng.
Lấy dữ liệu ở đâu
Zendesk Tickets API, trường 'satisfaction_rating.score' hoặc 'satisfaction_rating.reason'.
Ví dụ
TốtKhông tốtĐã gửi
|
|||
|
Giải quyết ngay lần liên hệ đầu tiên
IsFirstContactResolution
|
Cờ cho biết yêu cầu có được nhân viên hỗ trợ đầu tiên xử lý mà không cần chuyển giao hoặc nhận thêm phản hồi từ người yêu cầu hay không. | ||
|
Mô tả
Giải quyết ngay lần liên hệ đầu tiên (FCR) là chỉ số quan trọng, cho biết vấn đề của khách hàng được xử lý chỉ trong một lần tương tác. Thuộc tính được tính này là cờ đúng/sai. Cờ có giá trị đúng nếu phiếu yêu cầu được nhân viên hỗ trợ đầu tiên xử lý, không bị chuyển giao và chỉ có một phản hồi từ nhân viên. Thuộc tính này hỗ trợ trực tiếp KPI “Tỷ lệ giải quyết ngay lần liên hệ đầu tiên”. Phân tích các trường hợp đạt FCR giúp bạn xác định cách tổ chức quy trình hiệu quả. Ngược lại, phân tích các trường hợp không đạt FCR có thể cho thấy cơ hội cải thiện đào tạo nhân viên, nội dung trong kho kiến thức hoặc khâu phân loại ban đầu.
Vì sao điều này quan trọng
Đo khả năng xử lý vấn đề hiệu quả chỉ trong một lần tương tác, yếu tố góp phần đáng kể vào sự hài lòng của khách hàng và hiệu quả vận hành.
Lấy dữ liệu ở đâu
Đây là thuộc tính được tính theo cách phức tạp. Bạn cần phân tích event log của phiếu yêu cầu để kiểm tra số lần chuyển giao giữa nhân viên hỗ trợ và số phản hồi công khai từ nhân viên.
Ví dụ
truefalse
|
|||
|
Số lần chuyển giao giữa nhân viên hỗ trợ
AgentReassignmentCount
|
Tổng số lần yêu cầu được chuyển từ nhân viên hỗ trợ này sang nhân viên khác. | ||
|
Mô tả
Thuộc tính này đếm số lần trường 'assignee_id' của phiếu yêu cầu thay đổi. Một phiếu bị chuyển giao nhiều lần có thể cho thấy quy trình đang gặp vấn đề, chẳng hạn như phân tuyến ban đầu chưa đúng, nhân viên hỗ trợ chưa nắm đủ thông tin hoặc yêu cầu quá phức tạp để một người xử lý. Đây là chỉ số quan trọng để đo hiệu quả quy trình và tính KPI “Tỷ lệ chuyển giao giữa nhân viên hỗ trợ”. Phân tích các trường hợp bị chuyển giao nhiều lần giúp bạn tìm ra cách cải thiện quy tắc phân tuyến, đào tạo nhân viên hoặc bổ sung tài nguyên cho kho kiến thức, để phiếu yêu cầu đến đúng người nhanh hơn.
Vì sao điều này quan trọng
Giúp đo số lần bàn giao nội bộ và phát hiện vướng mắc trong quy trình. Tỷ lệ chuyển giao cao thường kéo theo chậm trễ và giảm hiệu quả.
Lấy dữ liệu ở đâu
Được tính bằng cách đếm số lần trường 'assignee_id' thay đổi trong Zendesk Ticket Audits API của từng phiếu yêu cầ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) được áp dụng cho yêu cầu. | ||
|
Mô tả
Thuộc tính này cho biết chính sách SLA cụ thể áp dụng cho thời hạn phản hồi và xử lý yêu cầu dịch vụ. Chính sách thường được xác định dựa trên mức độ ưu tiên, loại yêu cầu hoặc gói dịch vụ của khách hàng. Bạn cần biết chính sách SLA được áp dụng để sử dụng bảng điều khiển “Phân tích mức độ đáp ứng và vi phạm SLA”. Thông tin này giúp đánh giá hiệu quả trong đúng bối cảnh, vì mỗi chính sách có mục tiêu riêng. Nhờ đó, bạn có thể xác định chính xác và công bằng liệu phiếu yêu cầu có đáp ứng mục tiêu dịch vụ tương ứng hay không.
Vì sao điều này quan trọng
Cho biết bộ mục tiêu được dùng để đánh giá yêu cầu, giúp phân tích SLA và báo cáo tuân thủ chính xác.
Lấy dữ liệu ở đâu
Zendesk Ticket Metrics API. Dữ liệu SLA thường được liên kết với các chỉ số của phiếu yêu cầu.
Ví dụ
Khẩn cấp, phản hồi trong 1 giờTiêu chuẩn, xử lý trong 24 giờSLA dành cho khách hàng cao cấp
|
|||
|
Tên người yêu cầu
RequestorName
|
Tên người dùng cuối hoặc khách hàng đã 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ụ. Liên kết yêu cầu với một khách hàng cụ thể giúp bạn xem quy trình hỗ trợ từ góc độ người dùng. Trong phân tích quy trình, bạn có thể dùng người yêu cầu để tìm hiểu xu hướng của từng khách hàng hoặc nhóm khách hàng. Ví dụ, bạn có thể kiểm tra xem một số khách hàng có thời gian giải quyết lâu hơn hoặc tỷ lệ làm lại cao hơn không. Những dấu hiệu này có thể cho thấy vấn đề với sản phẩm hoặc dịch vụ họ đang dùng.
Vì sao điều này quan trọng
Liên kết quy trình với khách hàng, giúp phân tích vấn đề riêng của từng khách hàng, yêu cầu lặp lại và mức độ hài lòng.
Lấy dữ liệu ở đâu
Zendesk Users API, bằng cách kết hợp 'requester_id' từ phản hồi của Tickets API.
Ví dụ
Alice JohnsonBob WilliamsCharlie Brown
|
|||
|
Thời gian kết thúc
EndTime
|
Ngày và giờ chính xác khi hoạt động hoàn tất. | ||
|
Mô tả
Thời gian kết thúc ghi nhận lúc một hoạt động hoàn tất. Với nhiều sự kiện trong Zendesk, hoạt động diễn ra tức thời nên Thời gian kết thúc trùng với Thời gian bắt đầu. Tuy nhiên, với hoạt động dựa trên trạng thái như 'Tạm giữ yêu cầu', Thời gian kết thúc là lúc ticket được bỏ tạm giữ. Thuộc tính này cần thiết để tính thời lượng của từng hoạt động, một yếu tố quan trọng khi phân tích điểm nghẽn. So sánh Thời gian bắt đầu và Thời gian kết thúc giúp đo trực tiếp thời gian xử lý, qua đó xác định bước nào mất nhiều thời gian nhất.
Vì sao điều này quan trọng
Giúp tính thời lượng của từng hoạt động, từ đó xác định điểm nghẽn trong quy trình và đo hiệu quả ở từng bước.
Lấy dữ liệu ở đâu
Với các sự kiện riêng lẻ, thời gian này thường trùng với StartTime. Với thời lượng trạng thái, đây là dấu thời gian của sự kiện tiếp theo làm thay đổi trạng thái.
Ví dụ
2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
|
|||
|
Tổ chức của người yêu cầu
RequestorOrganization
|
Tổ chức hoặc công ty nơi người yêu cầu làm việc. | ||
|
Mô tả
Thuộc tính này liên kết yêu cầu dịch vụ với một tổ chức khách hàng cụ thể. Điều này đặc biệt hữu ích trong hỗ trợ B2B, nơi thỏa thuận mức dịch vụ và hợp đồng hỗ trợ thường được xác định ở cấp tổ chức. Phân tích dữ liệu theo tổ chức giúp bạn xem hiệu suất hỗ trợ ở cấp công ty. Bạn có thể xác định tổ chức nào gửi nhiều ticket, gặp vấn đề lặp lại hoặc có điểm hài lòng thấp. Thông tin này hữu ích cho việc quản lý khách hàng và nhận diện xu hướng chung về tình trạng khách hàng.
Vì sao điều này quan trọng
Hỗ trợ phân tích dịch vụ B2B bằng cách nhóm yêu cầu theo công ty, rất cần thiết để quản lý quan hệ khách hàng và SLA ở cấp tổ chức.
Lấy dữ liệu ở đâu
Zendesk Organizations API, bằng cách kết hợp 'organization_id' từ phản hồi của Tickets API.
Ví dụ
Acme CorporationGlobal Tech Inc.Innovate Solutions
|
|||
Hoạt động quản lý yêu cầu dịch vụ
| Hoạt động | Mô tả | ||
|---|---|---|---|
|
Đóng yêu cầu dịch vụ
|
Cho biết yêu cầu dịch vụ đã được đóng hẳn. Ticket tự động chuyển sang trạng thái 'closed' sau một khoảng thời gian ở trạng thái 'solved' và không thể mở lại. | ||
|
Vì sao điều này quan trọng
Hoạt động này đánh dấu thời điểm quy trình yêu cầu dịch vụ kết thúc hoàn toàn. Đây là mốc cuối để tính tổng thời gian xử lý một yêu cầu.
Lấy dữ liệu ở đâu
Được suy ra từ sự kiện 'Change' trên trường 'status' trong nhật ký kiểm tra ticket, khi giá trị mới là 'closed'.
Thu thập
Được suy ra từ sự kiện 'Change' trong nhật ký kiểm tra, khi trạng thái chuyển thành 'closed'.
Loại sự kiện
inferred
|
|||
|
Giải quyết yêu cầu dịch vụ
|
Hoạt động này ghi nhận thời điểm nhân viên hỗ trợ đưa ra giải pháp và chuyển trạng thái ticket thành 'solved'. Theo góc nhìn của nhân viên hỗ trợ, yêu cầu đã hoàn tất, nhưng người yêu cầu vẫn có thể mở lại. | ||
|
Vì sao điều này quan trọng
Đây là cột mốc quan trọng, đánh dấu thời điểm nhân viên hỗ trợ ngừng xử lý yêu cầu. Thời gian để đạt đến trạng thái này là thước đo chính về hiệu quả giải quyết.
Lấy dữ liệu ở đâu
Được suy ra từ sự kiện 'Change' trên trường 'status' trong nhật ký kiểm tra ticket, khi giá trị mới là 'solved'.
Thu thập
Được suy ra từ sự kiện 'Change' trong nhật ký kiểm tra, khi trạng thái chuyển thành 'solved'.
Loại sự kiện
inferred
|
|||
|
Gửi phản hồi công khai
|
Hoạt động này ghi nhận mọi trao đổi mà nhân viên hỗ trợ gửi cho người yêu cầu. Zendesk lưu hoạt động dưới dạng sự kiện 'Comment' trong dữ liệu ticket, với thuộc tính 'public' là true. | ||
|
Vì sao điều này quan trọng
Các sự kiện này rất quan trọng để phân tích tần suất trao đổi, đo thời gian phản hồi của nhân viên hỗ trợ và xác định cần bao nhiêu lần tương tác để giải quyết yêu cầu.
Lấy dữ liệu ở đâu
Đây là sự kiện 'Comment' được ghi nhận rõ ràng trong dữ liệu ticket. Chi tiết sự kiện có thuộc tính 'public: true' để phân biệt với ghi chú nội bộ.
Thu thập
Được ghi nhận từ các sự kiện 'Comment' của ticket có cờ 'public' là true.
Loại sự kiện
explicit
|
|||
|
Không đạt mục tiêu SLA
|
Hoạt động này ghi nhận thời điểm yêu cầu dịch vụ không đạt mục tiêu SLA đã đặt ra, chẳng hạn thời gian phản hồi đầu tiên hoặc thời gian giải quyết. Zendesk ghi lại sự kiện cụ thể khi không đạt mục tiêu. | ||
|
Vì sao điều này quan trọng
Đây là sự kiện quan trọng để theo dõi tuân thủ và là dữ liệu đầu vào chính cho KPI Tỷ lệ đáp ứng SLA. Sự kiện cho biết cam kết dịch vụ nào chưa được đáp ứng.
Lấy dữ liệu ở đâu
Được ghi nhận từ sự kiện 'SLABreach' trong các sự kiện ticket hoặc nhật ký kiểm tra Zendesk. Sự kiện cho biết chỉ số SLA nào không đạt.
Thu thập
Được xác định qua sự kiện 'SLABreach' được ghi nhận rõ ràng trong dữ liệu ticket.
Loại sự kiện
explicit
|
|||
|
Mở lại yêu cầu dịch vụ
|
Xảy ra khi người yêu cầu trả lời một yêu cầu đang ở trạng thái 'solved', khiến trạng thái tự động chuyển lại thành 'open'. Điều này cho thấy cách giải quyết được đề xuất chưa đáp ứng yêu cầu. | ||
|
Vì sao điều này quan trọng
Hoạt động này là dấu hiệu chính của việc phải làm lại. Phân tích tần suất xảy ra giúp đánh giá chất lượng giải quyết và tìm nguyên nhân khiến khách hàng không hài lòng.
Lấy dữ liệu ở đâu
Được suy ra từ sự kiện 'Change' trên trường 'status' trong nhật ký kiểm tra ticket, khi giá trị trước đó là 'solved' và giá trị mới là 'open'.
Thu thập
Được suy ra từ thay đổi trạng thái từ 'solved' sang 'open'.
Loại sự kiện
inferred
|
|||
|
Phân công yêu cầu cho nhân viên
|
Hoạt động này diễn ra khi yêu cầu dịch vụ được phân công cho một nhân viên cụ thể lần đầu tiên. Có thể suy ra hoạt động này từ sự kiện 'Change' trong nhật ký kiểm tra phiếu, khi trường 'assignee_id' được điền từ giá trị null hoặc ID nhóm. | ||
|
Vì sao điều này quan trọng
Đây là thời điểm nhân viên bắt đầu xử lý yêu cầu, rất quan trọng để đo thời gian phản hồi ban đầu, độ trễ trước lần phân công đầu tiên và phân bổ khối lượng công việc.
Lấy dữ liệu ở đâu
Được suy ra từ sự kiện 'Change' đầu tiên trên trường 'assignee_id' trong nhật ký kiểm tra phiếu, khi trường này được gán một ID người dùng cụ thể.
Thu thập
Được suy ra từ sự kiện thay đổi đầu tiên gán trường 'assignee_id' cho một nhân viên.
Loại sự kiện
inferred
|
|||
|
Tạo yêu cầu dịch vụ
|
Đánh dấu thời điểm bắt đầu vòng đời yêu cầu dịch vụ, khi người gửi tạo phiếu mới qua bất kỳ kênh nào. Sự kiện này được ghi nhận là sự kiện 'Create' trong nhật ký kiểm tra phiếu Zendesk, cung cấp thời điểm bắt đầu chính xác của quy trình. | ||
|
Vì sao điều này quan trọng
Hoạt động này là sự kiện bắt đầu chính của mọi yêu cầu dịch vụ, rất cần thiết để tính thời gian xử lý từ đầu đến cuối và phân tích số lượng yêu cầu tiếp nhận.
Lấy dữ liệu ở đâu
Sự kiện này được ghi nhận với loại 'Create' trong nhật ký kiểm tra phiếu Zendesk. Dấu thời gian của sự kiện là thời điểm tạo phiếu yêu cầu dịch vụ.
Thu thập
Được ghi nhận trực tiếp từ sự kiện 'Create' trong nhật ký kiểm tra phiếu.
Loại sự kiện
explicit
|
|||
|
Áp dụng mục tiêu SLA
|
Cho biết thời điểm chính sách thỏa thuận mức dịch vụ (SLA) được áp dụng cho phiếu yêu cầu dịch vụ. Sự kiện này được ghi rõ khi các thuộc tính của phiếu khớp với điều kiện của một chính sách SLA đang hoạt động. | ||
|
Vì sao điều này quan trọng
Theo dõi thời điểm áp dụng SLA rất quan trọng để giám sát mức độ tuân thủ, phân tích nguy cơ vi phạm và hiểu thời hạn dịch vụ dự kiến cho từng loại yêu cầu.
Lấy dữ liệu ở đâu
Được ghi nhận từ sự kiện 'SLAPolicyApplied' trong dữ liệu sự kiện phiếu Zendesk hoặc nhật ký kiểm tra. Sự kiện này cho biết chính sách nào đã được áp dụng.
Thu thập
Được xác định qua sự kiện 'SLAPolicyApplied' được ghi rõ trong dữ liệu phiếu.
Loại sự kiện
explicit
|
|||
|
Chuyển cấp yêu cầu
|
Cho biết yêu cầu dịch vụ được chính thức chuyển lên cấp hỗ trợ cao hơn, sang nhóm khác hoặc lên quản lý. Thường có thể suy ra sự kiện này từ thay đổi nhóm được giao xử lý ticket hoặc thay đổi trường tùy chỉnh dùng để theo dõi việc chuyển cấp. | ||
|
Vì sao điều này quan trọng
Theo dõi các yêu cầu được chuyển cấp giúp phát hiện yêu cầu phức tạp, nhu cầu đào tạo cho nhân viên hỗ trợ tuyến đầu và các vấn đề mang tính hệ thống cần cấp cao hơn can thiệp.
Lấy dữ liệu ở đâu
Đây không phải sự kiện tiêu chuẩn. Cần suy ra từ sự kiện 'Change' trên trường 'group_id' khi ticket được chuyển sang nhóm xử lý cấp cao hơn, hoặc từ thay đổi trường ticket tùy chỉnh dùng để theo dõi việc chuyển cấp.
Thu thập
Được suy ra từ thay đổi 'group_id' hoặc trường tùy chỉnh 'escalation'.
Loại sự kiện
inferred
|
|||
|
Chuyển yêu cầu sang nhân viên hỗ trợ khác
|
Cho biết quyền xử lý yêu cầu dịch vụ được chuyển từ nhân viên hỗ trợ này sang nhân viên khác. Sự kiện này được suy ra từ mọi sự kiện 'Change' tiếp theo trên trường 'assignee_id' sau lần phân công đầu tiên. | ||
|
Vì sao điều này quan trọng
Theo dõi các lần chuyển yêu cầu giúp tính KPI Tỷ lệ chuyển yêu cầu giữa nhân viên hỗ trợ. KPI này giúp phát hiện quy trình kém hiệu quả, định tuyến sai hoặc thiếu kiến thức.
Lấy dữ liệu ở đâu
Được suy ra từ các sự kiện 'Change' trên trường 'assignee_id' trong nhật ký kiểm tra ticket, không tính sự kiện phân công đầu tiên của ticket.
Thu thập
Được suy ra từ sự kiện 'Change' thứ hai trở đi trên trường 'assignee_id'.
Loại sự kiện
inferred
|
|||
|
Tạm giữ yêu cầu
|
Hoạt động này xảy ra khi trạng thái yêu cầu dịch vụ chuyển thành 'on-hold'. Thường là do nhân viên hỗ trợ đang chờ thông tin từ người yêu cầu hoặc bên thứ ba. Sự kiện được suy ra từ thay đổi trạng thái. | ||
|
Vì sao điều này quan trọng
Nhờ đó, bạn có thể tách riêng và đo thời gian chờ nằm ngoài khả năng kiểm soát trực tiếp của nhóm hỗ trợ, từ đó đánh giá chính xác hơn thời gian nhân viên xử lý yêu cầu.
Lấy dữ liệu ở đâu
Được suy ra từ sự kiện 'Change' trên trường 'status' trong nhật ký kiểm tra ticket, khi giá trị mới là 'on-hold'.
Thu thập
Được suy ra từ sự kiện 'Change' trong nhật ký kiểm tra, khi trạng thái chuyển thành 'on-hold'.
Loại sự kiện
inferred
|
|||
|
Thay đổi mức độ ưu tiên
|
Cho biết mức độ ưu tiên của yêu cầu dịch vụ, chẳng hạn như 'Low', 'Normal', 'High' hoặc 'Urgent', đã được cập nhật. Thay đổi này được ghi nhận là sự kiện 'Change' trên trường 'priority' trong nhật ký kiểm tra phiếu. | ||
|
Vì sao điều này quan trọng
Phân tích các lần thay đổi mức độ ưu tiên giúp xác định yêu cầu nào ngày càng khẩn cấp theo thời gian, đồng thời đánh giá việc ưu tiên yêu cầu có hiệu quả hay không.
Lấy dữ liệu ở đâu
Được ghi nhận dưới dạng sự kiện 'Change' trên trường 'priority' trong nhật ký kiểm tra ticket Zendesk, kèm giá trị trước và sau khi thay đổi.
Thu thập
Được suy ra từ các sự kiện 'Change' trên trường 'priority' trong nhật ký kiểm tra.
Loại sự kiện
inferred
|
|||
|
Thêm ghi chú nội bộ
|
Nhân viên hỗ trợ thêm ghi chú hoặc bình luận nội bộ vào yêu cầu dịch vụ. Chỉ các nhân viên hỗ trợ khác mới xem được ghi chú này. Zendesk ghi nhận dưới dạng sự kiện 'Comment' với thuộc tính 'public' là false. | ||
|
Vì sao điều này quan trọng
Theo dõi ghi chú nội bộ giúp bạn hiểu cách nhân viên hoặc các nhóm phối hợp với nhau. Việc này có thể gây chậm trễ, nhưng cũng có thể giúp giải quyết vấn đề hiệu quả hơn.
Lấy dữ liệu ở đâu
Đây là sự kiện 'Comment' được ghi nhận rõ ràng trong dữ liệu ticket. Chi tiết sự kiện có thuộc tính 'public: false', cho biết đây là ghi chú nội bộ.
Thu thập
Được ghi nhận từ các sự kiện 'Comment' của ticket có cờ 'public' là false.
Loại sự kiện
explicit
|
|||
Hướng dẫn trích xuất
Bạn đã sẵn sàng bắt đầu chưa?
Bắt đầu tối ưu hóa quy trình yêu cầu dịch vụ ngay hôm nay. Dùng mẫu dữ liệu này để tìm điểm nghẽn và nâng cao hiệu quả trong Zendesk Support.
Tối ưu hóa quy trình quản lý yêu cầu dịch vụ. Giảm chậm trễ ngay hôm nay.
Chấm dứt tình trạng xử lý chậm và người dùng bực bội. Đạt 70% tự động hóa.
Không cần thẻ tín dụng. Thiết lập nhanh chóng.