> Cải tiến quy trình liên tục > Quản lý sự cố > Zendesk Support > Mẫu dữ liệu

Mẫu dữ liệu quản lý sự cố

Zendesk Support

Thuộc tính quản lý sự cố(23) Hoạt động quản lý sự cố(13) Hướng dẫn trích xuất(4)

Mẫu dữ liệu quản lý sự cố

Mẫu này tổng hợp những dữ liệu cần thiết để phân tích hiệu quả quy trình quản lý sự cố. Mẫu nêu rõ các thuộc tính chính cần thu thập, những hoạt động quan trọng cần theo dõi và hướng dẫn thực tế để trích xuất dữ liệu từ Zendesk Support. Hãy dùng mẫu này để bắt đầu dự án process mining với bộ dữ liệu đầy đủ và đáng tin cậy.

Các thuộc tính nên thu thập
Các hoạt động chính cần theo dõi khi sơ đồ hóa quy trình
Hướng dẫn trích xuất dữ liệu thực tế

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.

Tải mẫu xuống

Thuộc tính quản lý sự cố

Đây là những trường dữ liệu nên có trong nhật ký sự kiện để phân tích kỹ quy trình quản lý sự cố.

5 Bắt buộc 7 Nên có 11 Không bắt buộc

	Tên	Mô tả
	Dấu thời gian sự kiện EventTimestamp	Ngày và giờ chính xác khi hoạt động diễn ra.
Mô tả Dấu thời gian ghi lại chính xác thời điểm một sự kiện xảy ra trong vòng đời sự cố, chẳng hạn khi thêm bình luận hoặc thay đổi trạng thái. Thông tin này xác định thứ tự thời gian của mọi hoạt động trong một hồ sơ. Thuộc tính này là nền tảng cho mọi phân tích process mining dựa trên thời gian. Thuộc tính được dùng để tính thời gian giữa các hoạt động, xác định thời gian chờ, đo tổng thời gian xử lý hồ sơ và phân tích hiệu suất quy trình theo từng giai đoạn. Dấu thời gian chính xác rất cần thiết để tạo sơ đồ quy trình động, thể hiện luồng xử lý hồ sơ theo thời gian, cũng như xây dựng dashboard hiệu suất theo dõi KPI như thời gian xử lý trung bình. Vì sao điều này quan trọng Dấu thời gian cung cấp bối cảnh thời gian cho mọi hoạt động, giúp tính thời lượng, xác định điểm nghẽn và phân tích hiệu suất quy trình theo thời gian. Lấy dữ liệu ở đâu Zendesk Ticket Audits API (/api/v2/tickets/{ticket_id}/audits), trường created_at của từng sự kiện kiểm tra. Ví dụ 2023-04-15T10:00:00Z2023-04-15T10:05:12Z2023-04-16T14:30:00Z
	ID sự cố TicketId	Mã định danh duy nhất do hệ thống tạo cho mỗi ticket sự cố.
Mô tả Incident ID là khóa chính dùng để nhận diện duy nhất từng hồ sơ sự cố trong Zendesk Support. Trong process mining, mã này đóng vai trò CaseId, liên kết mọi hoạt động, thay đổi trạng thái và trao đổi liên quan từ lúc tạo đến khi đóng sự cố. Khi phân tích, mã này rất quan trọng để dựng lại toàn bộ hành trình của từng sự cố. Mã cho phép tổng hợp dữ liệu sự kiện để theo dõi các chỉ số như tổng thời gian xử lý, số lần bàn giao và mức độ đáp ứng thỏa thuận mức dịch vụ của từng hồ sơ. Nhóm các sự kiện theo mã này giúp chuyên viên phân tích trực quan hóa luồng quy trình, tìm ra các lộ trình phổ biến và phát hiện điểm khác biệt so với quy trình chuẩn. 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 với một sự cố duy nhất, giúp theo dõi toàn bộ vòng đời và phân tích chính xác hiệu suất quy trình. Lấy dữ liệu ở đâu Zendesk Tickets API (/api/v2/tickets/{id}), trường id. Ví dụ 19428230113521941055
	Hệ thống nguồn SourceSystem	Hệ thống dùng để trích xuất dữ liệu sự cố.
Mô tả Thuộc tính này cho biết nguồn gốc của dữ liệu quy trình. Trong chế độ xem này, giá trị sẽ cố định, chẳng hạn 'Zendesk Support', cho biết mọi sự kiện và thuộc tính đều lấy từ hệ thống đó. Trong môi trường kết hợp dữ liệu từ nhiều hệ thống, trường này rất quan trọng để phân biệt các nguồn dữ liệu. Trường giúp đảm bảo tính toàn vẹn của dữ liệu và hỗ trợ phân tích theo từng nguồn, chẳng hạn so sánh quy trình quản lý sự cố trên Zendesk với một công cụ ITSM khác. Vì sao điều này quan trọng Cho biết nguồn gốc dữ liệu, yếu tố quan trọng đối với quản trị dữ liệu và các phân tích kết hợp dữ liệu từ nhiều hệ thống nguồn. Lấy dữ liệu ở đâu Giá trị cố định được thiết lập trong quá trình chuyển đổi dữ liệu để xác định nguồn gốc dữ liệu. Ví dụ Zendesk SupportZendesk
	Hoạt động ActivityName	Tên hoạt động nghiệp vụ hoặc sự kiện diễn ra tại một thời điểm cụ thể trong vòng đời sự cố.
Mô tả Thuộc tính này mô tả một bước hoặc hành động cụ thể trong quy trình quản lý sự cố, chẳng hạn 'Incident Created', 'Ticket Assigned to Agent' hoặc 'Incident Resolved'. Các hoạt động này được xác định từ nhật ký sự kiện hoặc dữ liệu lịch sử kiểm tra của Zendesk, nơi hệ thống ghi lại các thay đổi. Trong process mining, chuỗi hoạt động tạo thành sơ đồ quy trình, nền tảng cho mọi phân tích. Phân tích luồng hoạt động giúp tổ chức khám phá các lộ trình xử lý sự cố thực tế, xác định điểm nghẽn giữa các bước, đo lường vòng lặp làm lại, chẳng hạn mở lại ticket đã xử lý xong, và kiểm tra mức độ phù hợp với quy trình chuẩn đã xác định. Vì sao điều này quan trọng Trình tự hoạt động xác định luồng quy trình, trọng tâm của phân tích process mining nhằm tìm ra điểm kém hiệu quả, sai lệch và cơ hội cải tiến. Lấy dữ liệu ở đâu Suy ra từ các sự kiện trong Zendesk Ticket Audits API. Ví dụ: sự kiện Change trên trường trạng thái có thể được ánh xạ thành 'Status Changed'. Ví dụ Sự cố được tạoTicket được giao cho nhân viên hỗ trợTrạng thái chuyển thành PendingSự cố được xử lý xongSự cố được đóng
	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 này được làm mới.
Mô tả Thuộc tính này ghi lại ngày giờ trích xuất hoặc cập nhật dữ liệu gần nhất từ hệ thống nguồn. Thông thường, một giá trị duy nhất được áp dụng cho toàn bộ tập dữ liệu trong mỗi lần làm mới. Thông tin này rất quan trọng đối với quản trị dữ liệu và người dùng phân tích process mining. Thông tin cho biết dữ liệu mới đến đâu, giúp chuyên viên phân tích hiểu liệu họ đang xem thông tin cập nhật nhất hiện có hay không. Điều này đặc biệt quan trọng khi theo dõi hiệu suất vận hành và đưa ra quyết định kịp thời dựa trên kết quả phân tích. 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 hiểu kết quả phân tích cập nhật đến thời điểm nào và dữ liệu được lấy lần gần nhất khi nào. Lấy dữ liệu ở đâu Dấu thời gian do quy trình ETL/đường ống dữ liệu tạo ra sau khi hoàn tất làm mới dữ liệu. Ví dụ 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	Kênh tiếp nhận báo cáo Channel	Kênh ban đầu tiếp nhận báo cáo sự cố, chẳng hạn “Email”, “Web” hoặc “API”.
Mô tả Thuộc tính này ghi lại cách người dùng cuối hoặc hệ thống tạo phiếu sự cố. Hiểu rõ kênh tiếp nhận giúp phân tích nguồn phát sinh sự cố và điều chỉnh quy trình hỗ trợ cho phù hợp. Phân tích sự cố theo kênh có thể cho thấy những kiểu xử lý khác nhau. Chẳng hạn, sự cố được báo qua điện thoại có thể được giải quyết nhanh hơn sự cố gửi qua email. Thông tin này hỗ trợ dashboard “Số lượng sự cố được xử lý” và giúp lập kế hoạch tài nguyên cũng như tối ưu các kênh tiếp nhận. Vì sao điều này quan trọng Giúp phân tích số lượng sự cố và hiệu suất quy trình theo nguồn tiếp nhận, từ đó cải tiến quy trình cho từng kênh và phân bổ tài nguyên phù hợp. Lấy dữ liệu ở đâu Zendesk Tickets API, trường via.channel. Ví dụ webemailapiđiện thoại
	Mức độ ưu tiên TicketPriority	Mức độ ưu tiên của sự cố, 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 sự cố quyết định mức độ khẩn trương cần thiết để phản hồi và giải quyết. Đây là yếu tố quan trọng khi sắp xếp công việc và phân bổ tài nguyên trong nhóm hỗ trợ. Khi phân tích quy trình, bạn có thể dùng mức độ ưu tiên để chia nhóm sự cố và so sánh luồng xử lý cũng như hiệu suất. Chẳng hạn, chuyên viên phân tích có thể kiểm tra xem sự cố “Khẩn cấp” có thực sự được giải quyết nhanh hơn sự cố ở mức “Thấp” hay không. Mức độ ưu tiên cũng giúp theo dõi việc tuân thủ SLA, vì SLA thường được xác định theo từng mức ưu tiên. KPI “Tỷ lệ thay đổi mức độ ưu tiên” dựa trên việc theo dõi các thay đổi ở trường này. Vì sao điều này quan trọng Thuộc tính này rất quan trọng để chia nhóm dữ liệu phân tích, đánh giá hiệu quả sắp xếp ưu tiên và theo dõi việc tuân thủ SLA ở từng mức độ khẩn cấp. Lấy dữ liệu ở đâu Zendesk Tickets API, trường priority. Các thay đổi được ghi lại trong Ticket Audits API. Ví dụ thấpbình thườngcaokhẩn cấp
	Nhân viên hỗ trợ được giao xử lý Assignee	Nhân viên hỗ trợ hiện được giao xử lý sự cố.
Mô tả Thuộc tính này cho biết nhân viên cụ thể chịu trách nhiệm xử lý sự cố tại một thời điểm. Mỗi lần đổi người được giao là một sự kiện quan trọng, cho thấy công việc đã được chuyển từ người này sang người khác. Phân tích nhân viên được giao giúp bạn hiểu cách phân bổ khối lượng công việc, hiệu suất cá nhân và cách phối hợp giữa các nhân viên. Theo dõi thay đổi ở trường này là cần thiết để tính KPI “Số lần chuyển giao trung bình mỗi sự cố” và phát hiện các sự cố bị chuyển qua lại nhiều lần, có thể do thiếu kiến thức hoặc định tuyến chưa hiệu quả. Vì sao điều này quan trọng Cho biết nhân viên chịu trách nhiệm xử lý, giúp phân tích khối lượng công việc và theo dõi việc chuyển giao, từ đó phát hiện những điểm chưa hiệu quả trong quy trình. Lấy dữ liệu ở đâu Zendesk Tickets API, trường assignee_id. Các thay đổi được ghi lại trong Ticket Audits API. Ví dụ John SmithJane DoeTự động hóa bộ phận hỗ trợ dịch vụ
	Nhóm được giao xử lý AssignedGroup	Nhóm hỗ trợ hiện được giao xử lý sự cố.
Mô tả Thuộc tính này cho biết nhóm nào chịu trách nhiệm xử lý sự cố. Sự cố thường được chuyển giữa các cấp hỗ trợ hoặc nhóm chuyên môn khác nhau, chẳng hạn từ “Hỗ trợ cấp 1” sang “Nhóm mạng”. Đây là chiều phân tích quan trọng để xem xét việc chuyển giao giữa các nhóm và tìm điểm nghẽn. Theo dõi luồng sự cố giữa các nhóm giúp chuyên viên phân tích đo lường mức độ phụ thuộc lẫn nhau, tính thời gian chờ của từng nhóm và tối ưu quy tắc định tuyến. Thuộc tính này hỗ trợ trực tiếp cho dashboard “Phân tích chuyển giao và làm lại”. Vì sao điều này quan trọng Theo dõi nhóm chịu trách nhiệm, giúp phân tích việc chuyển giao giữa các nhóm, tìm điểm nghẽn ở từng nhóm và đo thời gian chờ. Lấy dữ liệu ở đâu Zendesk Tickets API, trường group_id. Các thay đổi được ghi lại trong Ticket Audits API. Ví dụ Hỗ trợ cấp 1Nhóm mạng cấp 2Hạ tầng cấp 3Thanh toán
	Thời điểm kết thúc sự kiện EventEndTime	Dấu thời gian cho biết một hoạt động đã hoàn tất khi nào.
Mô tả Thời điểm kết thúc sự kiện đánh dấu lúc một hoạt động hoàn tất. Trong dữ liệu nhật ký sự kiện, thời điểm kết thúc của một hoạt động thường được suy ra từ thời điểm bắt đầu của hoạt động tiếp theo trong cùng một trường hợp. Với hoạt động cuối cùng, thời điểm kết thúc có thể trùng với thời điểm bắt đầu. Thuộc tính này cần thiết để tính thời lượng của từng hoạt động (ProcessingTime) và thời gian chờ giữa các hoạt động. Đây là cơ sở để phân tích điểm nghẽn, giúp chuyên viên phân tích biết không chỉ một bước mất bao lâu mà còn cả trường hợp đã chờ bao lâu trước khi bước đó bắt đầu. Vì sao điều này quan trọng Cho phép tính thời lượng hoạt động và thời gian chờ, làm cơ sở để phân tích điểm nghẽn chi tiết và xác định các chậm trễ trong quy trình. Lấy dữ liệu ở đâu Được tính bằng thời điểm bắt đầu của sự kiện tiếp theo trong cùng một trường hợp. Thời điểm kết thúc của sự kiện cuối cùng có thể trùng với thời điểm bắt đầu hoặc thời điểm đóng trường hợp. Ví dụ 2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
	Trạng thái SLA SlaStatus	Trạng thái hiện tại của Thỏa thuận mức dịch vụ (SLA) cho sự cố.
Mô tả Thuộc tính này cho biết sự cố có đang đi đúng tiến độ để đạt mục tiêu SLA, đã vi phạm SLA hay bộ đếm thời gian SLA đang tạm dừng. Zendesk tự động theo dõi các chỉ số SLA dựa trên chính sách đã cấu hình. Đây là thuộc tính quan trọng trong dashboard “Theo dõi tuân thủ SLA”. Thuộc tính này đo trực tiếp hiệu suất so với cam kết dịch vụ. Phân tích thời điểm và nguyên nhân vi phạm SLA giúp tổ chức tìm ra điểm yếu trong quy trình và cải thiện độ tin cậy của dịch vụ. Thuộc tính này hỗ trợ trực tiếp KPI “Tỷ lệ đáp ứng SLA sự cố”. Vì sao điều này quan trọng Đo trực tiếp hiệu suất so với cam kết dịch vụ, giúp phân tích các trường hợp vi phạm SLA và chủ động theo dõi để cải thiện việc tuân thủ. Lấy dữ liệu ở đâu Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), được suy ra từ các trường như sla_policy, breached_at, v.v. Ví dụ Đang hoạt độngĐang tạm dừngĐã vi phạmĐã hoàn thành
	Trạng thái ticket TicketStatus	Trạng thái của ticket sự cố tại thời điểm diễn ra sự kiện, chẳng hạn 'Open', 'Pending' hoặc 'Solved'.
Mô tả Thuộc tính này thể hiện trạng thái của ticket sự cố tại các thời điểm khác nhau trong vòng đời. Các trạng thái chuẩn của Zendesk gồm new, open, pending, on-hold, solved và closed. Theo dõi thay đổi của trường này là một cách chính để tạo hoạt động phục vụ process mining. Phân tích trạng thái ticket là bước thiết yếu để hiểu quy trình. Việc này giúp xác định sự cố ở từng trạng thái trong bao lâu, chẳng hạn 'Pending', thường cho biết đang chờ khách hàng phản hồi. Trạng thái ticket cũng rất quan trọng để xác định khi nào hồ sơ hoàn tất và tính thời gian xử lý. Vì sao điều này quan trọng Theo dõi các lần đổi trạng thái giúp bạn hiểu quy trình diễn tiến ra sao, xác định thời gian chờ và xác định điểm bắt đầu, kết thúc của vòng đời sự cố. Lấy dữ liệu ở đâu Zendesk Tickets API, trường status. Các thay đổi được ghi lại trong Ticket Audits API. Ví dụ mớiđang mởđang chờđã giải quyếtđã đóng
	Có tự động hóa IsAutomated	Cờ đúng/sai cho biết một hoạt động do hệ thống tự động hay nhân viên thực hiện.
Mô tả Thuộc tính được suy ra này giúp phân biệt sự kiện do người dùng thực hiện với sự kiện do tính năng tự động hóa, trigger hoặc tích hợp API thực hiện. Thông thường, thuộc tính được xác định bằng cách kiểm tra xem tác giả của sự kiện có phải là người dùng hệ thống đã biết hay không. Hiểu rõ mức độ tự động hóa rất quan trọng khi phân tích quy trình hiện đại. Thông tin này giúp đánh giá hiệu quả của các quy tắc tự động hóa, tìm tác vụ thủ công có thể tự động hóa và đo lường ảnh hưởng của tự động hóa đến hiệu suất cũng như thời gian giải quyết. Bạn cũng có thể dùng thuộc tính này để so sánh luồng xử lý tự động với luồng xử lý thủ công. Vì sao điều này quan trọng Phân biệt thao tác của con người với thao tác của hệ thống, giúp phân tích ảnh hưởng của tự động hóa đến hiệu suất quy trình và tìm cơ hội tự động hóa mới. Lấy dữ liệu ở đâu Được suy ra bằng cách kiểm tra xem tác giả sự kiện (author_id trong Ticket Audits API) có tương ứng với người dùng hệ thống hoặc người dùng tự động hóa đã biết hay không. Ví dụ truefalse
	Giải quyết ngay lần liên hệ đầu tiên IsFirstContactResolution	Cờ đúng/sai, có giá trị đúng nếu nhân viên hoặc nhóm đầu tiên được giao đã giải quyết sự cố mà không chuyển giao.
Mô tả Giải quyết ngay lần liên hệ đầu tiên (FCR) là chỉ số quan trọng để đánh giá hiệu quả của trung tâm hỗ trợ và mức độ hài lòng của khách hàng. Thuộc tính được tính này đánh dấu các sự cố được giải quyết mà không cần chuyển sang nhân viên hoặc nhóm khác. Thông thường, logic sẽ kiểm tra xem phiếu có đạt trạng thái “Đã giải quyết” trong khi vẫn được giao cho nhân viên và nhóm ban đầu hay không. Trong process mining, bạn có thể tính trực tiếp tỷ lệ FCR và so sánh luồng xử lý của các sự cố được giải quyết ngay lần đầu với những sự cố phải chuyển cấp. Qua đó, bạn có thể tìm cách trao thêm quyền xử lý cho nhóm hỗ trợ tuyến đầu. Vì sao điều này quan trọng Đo trực tiếp hiệu quả của lần hỗ trợ đầu tiên và giúp tìm cơ hội giải quyết sự cố sớm hơn trong quy trình. Lấy dữ liệu ở đâu Cờ đúng/sai được tính toán. Có giá trị đúng nếu trạng thái phiếu là “đã giải quyết” hoặc “đã đóng” và chỉ có một nhân viên hoặc nhóm duy nhất được giao xử lý trong suốt vòng đời sự cố. Ví dụ truefalse
	Loại phiếu TicketType	Phân loại phiếu, chẳng hạn “Sự cố”, “Vấn đề”, “Câu hỏi” hoặc “Tác vụ”.
Mô tả Trường này phân loại phiếu theo tính chất yêu cầu. Quy trình quản lý sự cố tập trung vào các phiếu có loại “Sự cố”, tức là tình trạng gián đoạn ngoài dự kiến hoặc suy giảm chất lượng dịch vụ CNTT. Trong phân tích, thuộc tính này chủ yếu được dùng làm bộ lọc để chỉ đưa sự cố vào chế độ xem quy trình. Bạn cũng có thể dùng thuộc tính này trong phân tích ITSM rộng hơn để so sánh quy trình xử lý sự cố, vấn đề và yêu cầu dịch vụ. Vì sao điều này quan trọng Cho phép lọc dữ liệu để chỉ tập trung vào sự cố, bảo đảm phân tích quy trình phù hợp với vòng đời quản lý sự cố. Lấy dữ liệu ở đâu Zendesk Tickets API, trường type. Ví dụ sự cốvấn đềcâu hỏitác vụ
	Mức độ hài lòng SatisfactionRating	Mức độ hài lòng do người dùng cuối đánh giá sau khi sự cố đượ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 phiếu được giải quyết. Các mức đánh giá phổ biến trong Zendesk là “Tốt” hoặc “Không tốt”. Mức độ hài lòng không đo trực tiếp hiệu quả quy trình, nhưng là chỉ số kết quả quan trọng. Trong process mining, bạn có thể đối chiếu chỉ số này với các biến thể quy trình để hiểu luồng xử lý nào giúp khách hàng hài lòng hơn. Chẳng hạn, sự cố phải chuyển giao nhiều lần có nhận được đánh giá thấp hơn không? Vì sao điều này quan trọng Cung cấp chỉ số kết quả quan trọng để đối chiếu với các đặc điểm của quy trình, giúp bạn hiểu hiệu suất quy trình ảnh hưởng thế nào đến mức độ hài lòng của người dùng. Lấy dữ liệu ở đâu Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), trường satisfaction_rating.score. Ví dụ tốtkhông tốtđã gửi lời mời đánh giáchưa gửi lời mời đánh giá
	Mức độ nghiêm trọng Severity	Mức độ ảnh hưởng của sự cố đến hoạt động kinh doanh.
Mô tả Mức độ nghiêm trọng cho biết ảnh hưởng của sự cố đến hoạt động kinh doanh. Thông tin này thường được kết hợp với mức độ ưu tiên để xác định mức độ khẩn cấp chung. Trong Zendesk, thuộc tính này thường được cấu hình dưới dạng trường tùy chỉnh. Phân tích mức độ nghiêm trọng giúp bạn hiểu tính chất cấp bách của các sự cố đang được xử lý. Đây là chiều dữ liệu quan trọng để chia nhóm trong các dashboard như “Theo dõi tuân thủ SLA” và “Chỉ số hiệu quả sắp xếp ưu tiên”. So sánh luồng xử lý ở các mức độ nghiêm trọng khác nhau có thể cho thấy sự cố nghiêm trọng có được xử lý với tốc độ và tài nguyên phù hợp hay không. Vì sao điều này quan trọng Cho biết ảnh hưởng của sự cố đến hoạt động kinh doanh, giúp tập trung phân tích vào các vấn đề nghiêm trọng nhất và bảo đảm chúng được giải quyết hiệu quả. Lấy dữ liệu ở đâu Đây thường là trường tùy chỉnh. Kiểm tra cấu hình Ticket Fields trong Zendesk Admin Center. Ví dụ 1 - Nghiêm trọng2 - Cao3 - Trung bình4 - Thấp
	Người gửi báo cáo Submitter	Người dùng cuối hoặc hệ thống ban đầu báo cáo sự cố.
Mô tả Thuộc tính này cho biết người hoặc hệ thống đã tạo phiếu. Người gửi báo cáo không nhất thiết là người yêu cầu hỗ trợ, vì nhân viên hỗ trợ có thể tạo phiếu thay cho người khác. Trong phân tích, thông tin người gửi giúp bạn hiểu ai đang báo cáo sự cố. Khi kết hợp với dữ liệu tổ chức, thông tin này có thể cho biết khách hàng hoặc nhóm người dùng cụ thể nào đang gặp nhiều sự cố. Từ đó, bạn có thể chủ động hỗ trợ hoặc tổ chức đào tạo phù hợp. Vì sao điều này quan trọng Cho biết nguồn báo cáo sự cố, giúp tìm ra các xu hướng liên quan đến người dùng, phòng ban hoặc hệ thống tự động cụ thể. Lấy dữ liệu ở đâu Zendesk Tickets API, trường submitter_id. Ví dụ alice.jones@example.combob.williams@example.comTrình giám sát hệ thống
	Nhóm nguyên nhân gốc rễ RootCauseCategory	Nhóm khái quát của nguyên nhân gốc rễ gây ra sự cố.
Mô tả Thuộc tính này dùng để phân loại nguyên nhân cốt lõi gây ra sự cố. Thông tin thường được ghi nhận vào cuối vòng đời sự cố, thường trong quá trình đánh giá sau sự cố hoặc quản lý vấn đề, rồi lưu vào trường tùy chỉnh. Dữ liệu này rất cần thiết cho dashboard “Độ chính xác khi xác định nguyên nhân gốc rễ” và KPI “Mức độ bao phủ phân tích nguyên nhân gốc rễ (RCA)”. Phân tích sự cố theo nguyên nhân gốc rễ giúp phát hiện vấn đề lặp lại, từ đó định hướng việc khắc phục triệt để và giảm số sự cố trong tương lai. Nhờ vậy, tổ chức có thể chuyển từ xử lý sự cố bị động sang chủ động ngăn ngừa vấn đề. Vì sao điều này quan trọng Hỗ trợ quản lý vấn đề chủ động bằng cách phân loại nguyên nhân sự cố, giúp phát hiện xu hướng và ngăn sự cố tái diễn. Lấy dữ liệu ở đâu Đây thường là trường phiếu tùy chỉnh. Kiểm tra cấu hình Ticket Fields trong Zendesk Admin Center. Ví dụ Lỗi phần mềmHỏng phần cứngLỗi người dùngMất kết nối mạng
	Số lần chuyển giao HandoffCount	Tổng số lần sự cố được chuyển sang nhân viên hoặc nhóm khác.
Mô tả Chỉ số được tính này cho biết số lần trách nhiệm xử lý sự cố được chuyển giao. Mỗi lần trường Assignee hoặc AssignedGroup thay đổi sẽ làm tăng số đếm của trường hợp đó. Chuyển giao thường gây kém hiệu quả và chậm trễ trong quản lý sự cố. Số lần chuyển giao cao có thể cho thấy quy tắc định tuyến chưa rõ ràng, nhóm hỗ trợ thiếu kiến thức hoặc quy trình quá phức tạp. Chỉ số này là cơ sở để tính KPI “Số lần chuyển giao trung bình mỗi sự cố” và rất quan trọng với dashboard “Phân tích chuyển giao và làm lại”. Vì sao điều này quan trọng Đo mức độ vướng mắc trong quy trình do việc chuyển giao gây ra, giúp xác định điểm chưa hiệu quả trong định tuyến và những thiếu hụt kiến thức làm kéo dài thời gian giải quyết. Lấy dữ liệu ở đâu Được tính bằng cách đếm số lần trường AssignedGroup hoặc Assignee thay đổi đối với một sự cố. Ví dụ 0135
	Thẻ Tags	Danh sách thẻ được gắn vào sự cố để phân loại và bổ sung ngữ cảnh.
Mô tả Thẻ là nhãn linh hoạt có thể gắn vào phiếu để bổ sung ngữ cảnh, hỗ trợ phân loại hoặc định tuyến. Nhân viên có thể thêm thẻ thủ công, hoặc hệ thống tự thêm thông qua trigger và tính năng tự động hóa. Thẻ cung cấp nhiều dữ liệu hữu ích cho phân tích process mining. Bạn có thể dùng thẻ để chia dữ liệu thành các nhóm chi tiết, chẳng hạn lọc sự cố liên quan đến một đợt ra mắt sản phẩm cụ thể (“launch_q4”) hoặc một sự cố gián đoạn đã biết (“outage_20231027”). Nhờ đó, bạn có thể điều tra sâu hơn những gì các trường phiếu tiêu chuẩn cho phép. Vì sao điều này quan trọng Cung cấp cách linh hoạt để phân loại và lọc sự cố, cho phép phân tích chi tiết theo ngữ cảnh mà chỉ dùng các trường tiêu chuẩn có thể không làm được. Lấy dữ liệu ở đâu Zendesk Tickets API, trường tags. Ví dụ vip_usernetwork_issueoutage_20231027billing_related
	Thời lượng trường hợp CaseDuration	Tổng thời gian từ lúc tạo sự cố đến khi sự cố được đóng hoàn toàn.
Mô tả Chỉ số được tính này thể hiện thời gian xử lý từ đầu đến cuối của một sự cố. Chỉ số được tính bằng hiệu giữa dấu thời gian của sự kiện đầu tiên (ví dụ: “Tạo sự cố”) và sự kiện cuối cùng (ví dụ: “Đóng sự cố”). Thời lượng trường hợp là KPI chính để đo hiệu suất tổng thể của quy trình. Chỉ số này thường được dùng trong dashboard để hiển thị thời gian xử lý trung bình, tìm các trường hợp kéo dài và phân tích xu hướng theo thời gian. Đây là thước đo tổng quan về tốc độ xử lý và giải quyết sự cố của quy trình. Vì sao điều này quan trọng Đây là KPI quan trọng để đo tốc độ tổng thể của quy trình và xác định các yếu tố khiến thời gian giải quyết kéo dài. Lấy dữ liệu ở đâu Được tính bằng hiệu giữa dấu thời gian của sự kiện cuối cùng và sự kiện đầu tiên cho từng Incident ID. Ví dụ 25920060480086400
	Tổ chức khách hàng Organization	Tổ chức hoặc công ty mà người yêu cầu xử lý sự cố trực thuộc.
Mô tả Thuộc tính này liên kết sự cố với tổ chức của khách hàng. Đây là thông tin thiết yếu trong môi trường hỗ trợ B2B, nơi mức dịch vụ và quy trình hỗ trợ có thể khác nhau tùy khách hàng. Phân tích sự cố theo tổ chức giúp nhóm hỗ trợ theo dõi tình hình khách hàng, phát hiện vấn đề lặp lại ở từng khách hàng và bảo đảm thực hiện đúng cam kết trong hợp đồng. Đây cũng là chiều dữ liệu quan trọng để lọc dashboard và báo cáo, qua đó xem hiệu suất từ góc độ khách hàng. Vì sao điều này quan trọng Cho phép phân tích theo từng khách hàng, giúp theo dõi mức dịch vụ, phát hiện xu hướng ở các khách hàng trọng điểm và quản lý quan hệ khách hàng hiệu quả. Lấy dữ liệu ở đâu Zendesk Tickets API, trường organization_id. Ví dụ Global Tech Inc.Innovate SolutionsData Corp

Bắt buộc Nên có Không bắt buộc

Hoạt động quản lý sự cố

Đây là những bước và mốc quan trọng cần ghi lại trong nhật ký sự kiện để khám phá và phân tích quy trình chính xác.

6 Nên có 7 Không bắt buộc

	Hoạt động	Mô tả
	Sự cố được đóng	Đánh dấu thời điểm kết thúc vòng đời sự cố, khi ticket được đóng vĩnh viễn. Trong Zendesk, việc này thường diễn ra tự động sau một khoảng thời gian nhất định kể từ khi ticket được xử lý xong và được ghi nhận thành thay đổi trạng thái cuối cùng.
Vì sao điều này quan trọng Đây là hoạt động kết thúc chính thức của quy trình. Tổng thời gian quy trình được tính từ 'Incident Created' đến sự kiện này, cho thấy toàn bộ thời gian xử lý. Lấy dữ liệu ở đâu Lấy từ nhật ký kiểm tra ticket qua sự kiện 'Change', khi giá trị mới của trường 'status' chuyển thành 'closed'. Thu thập Được xác định qua sự kiện 'Change' của trường 'status' thành 'closed'. Loại sự kiện explicit
	Sự cố được tạo	Đánh dấu thời điểm bắt đầu vòng đời sự cố, khi một ticket mới được tạo trong Zendesk. Sự kiện này được ghi nhận rõ trong nhật ký kiểm tra việc tạo ticket của Zendesk, làm mốc bắt đầu cho mỗi trường hợp.
Vì sao điều này quan trọng Đây là hoạt động bắt đầu chính. Phân tích khoảng thời gian từ sự kiện này đến các sự kiện khác rất quan trọng để đo tổng thời gian xử lý ticket và thời gian phản hồi ban đầu. Lấy dữ liệu ở đâu Đây là sự kiện được ghi nhận rõ trong nhật ký kiểm tra ticket của Zendesk. Mỗi ticket mới tạo ra một sự kiện 'Create' kèm dấu thời gian tương ứng. Thu thập Lấy trực tiếp từ sự kiện tạo ticket trong nhật ký kiểm tra. Loại sự kiện explicit
	Sự cố được xử lý xong	Mốc quan trọng này xảy ra khi nhân viên hỗ trợ đã đưa ra giải pháp và đánh dấu ticket là 'solved'. Đây là hành động được ghi nhận rõ dưới dạng thay đổi trạng thái trong nhật ký kiểm tra ticket.
Vì sao điều này quan trọng Đây là hoạt động xử lý xong chính và là mốc quan trọng để đo thời gian xử lý. Khoảng thời gian từ sự kiện này đến 'Incident Closed' là thời gian chờ người dùng xác nhận hoặc thời gian trước khi ticket tự động đóng. Lấy dữ liệu ở đâu Lấy từ nhật ký kiểm tra ticket qua sự kiện 'Change', khi giá trị mới của trường 'status' chuyển thành 'solved'. Thu thập Được xác định qua sự kiện 'Change' của trường 'status' thành 'solved'. Loại sự kiện explicit
	Ticket được giao cho nhân viên hỗ trợ	Hoạt động này diễn ra khi ticket được giao cho một nhân viên hỗ trợ cụ thể. Sự kiện được ghi rõ trong lịch sử kiểm tra của ticket, cho biết một cá nhân đã nhận trách nhiệm xử lý.
Vì sao điều này quan trọng Mốc này rất quan trọng để đo thời gian đến lần giao xử lý đầu tiên, đồng thời là cơ sở phân tích các lần bàn giao, làm lại và tỷ lệ xử lý ngay lần liên hệ đầu tiên. Lấy dữ liệu ở đâu Lấy từ nhật ký kiểm tra ticket khi trường 'assignee_id' được điền hoặc thay đổi. Lần giao xử lý đầu tiên là mốc quan trọng để tính KPI. Thu thập Được xác định qua sự kiện 'Change' của trường 'assignee_id' trong nhật ký kiểm tra ticket. Loại sự kiện explicit
	Ticket được giao lại	Xảy ra khi trách nhiệm xử lý ticket đượ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 sau lần giao ban đầu. Đây là sự kiện được ghi rõ trong lịch sử kiểm tra của ticket.
Vì sao điều này quan trọng Việc giao lại rất quan trọng khi phân tích bàn giao và làm lại. Tần suất giao lại cao thường cho thấy định tuyến ban đầu chưa đúng, vấn đề phức tạp hoặc có điểm nghẽn trong quy trình. Lấy dữ liệu ở đâu Lấy từ nhật ký kiểm tra ticket bằng cách tìm sự kiện 'Change' trên trường 'assignee_id' hoặc 'group_id' sau lần đầu trường đó được điền. Thu thập Được xác định qua sự kiện 'Change' tiếp theo của trường 'assignee_id' hoặc 'group_id'. Loại sự kiện explicit
	Trạng thái chuyển thành Open	Cho biết nhân viên hỗ trợ đã bắt đầu xử lý sự cố. Hoạt động này thường được suy ra khi trường 'status' của ticket chuyển từ 'new' sang 'open', đánh dấu thời điểm bắt đầu điều tra và chẩn đoán.
Vì sao điều này quan trọng Sự kiện này đánh dấu lúc ticket chuyển từ hàng đợi sang trạng thái đang được xử lý. Thời gian ticket ở trạng thái 'new' trước khi chuyển sang 'open' là chỉ số quan trọng để đo thời gian phản hồi ban đầu. Lấy dữ liệu ở đâu Suy ra từ nhật ký kiểm tra ticket bằng cách tìm sự kiện 'Change' trong đó giá trị mới của trường 'status' là 'open' và giá trị trước đó là 'new'. Thu thập Suy ra từ thay đổi trạng thái từ 'new' sang 'open'. Loại sự kiện inferred
	Đã gửi phản hồi công khai	Đây là thông tin nhân viên hỗ trợ gửi cho người dùng cuối. Zendesk ghi nhận rõ sự kiện này mỗi khi có bình luận công khai được thêm vào ticket.
Vì sao điều này quan trọng Theo dõi phản hồi công khai giúp hiểu tần suất trao đổi. Đây cũng có thể là mốc quan trọng khi phân tích thời gian chờ người dùng xác nhận. Lấy dữ liệu ở đâu Lấy từ dữ liệu bình luận của ticket. Bình luận được xác định là công khai khi thuộc tính 'public' có giá trị true. Thu thập Ghi nhận sự kiện khi thêm bình luận mới có 'public: true' vào ticket. Loại sự kiện explicit
	Đã thêm ghi chú nội bộ	Hoạt động này thể hiện sự phối hợp nội bộ, khi nhân viên hỗ trợ thêm ghi chú riêng vào ticket để các thành viên khác trong nhóm xem. Sự kiện được ghi nhận rõ khi bình luận được đánh dấu là không công khai.
Vì sao điều này quan trọng Phân tích ghi chú nội bộ có thể giúp phát hiện những vấn đề phức tạp cần phối hợp xử lý. Tuy nhiên, số lượng ghi chú quá nhiều có thể cho thấy thiếu hụt kiến thức hoặc quy trình chưa hiệu quả. Lấy dữ liệu ở đâu Lấy từ dữ liệu bình luận của ticket. Bình luận được xác định là ghi chú nội bộ khi thuộc tính 'public' có giá trị false. Thu thập Ghi nhận sự kiện khi thêm bình luận mới có 'public: false' vào ticket. Loại sự kiện explicit
	Đặt mức ưu tiên	Mức độ ưu tiên của sự cố, chẳng hạn Thấp, Bình thường, Cao hoặc Khẩn cấp, được xác định. Thông tin này được ghi nhận thành sự kiện thay đổi và quyết định mức độ khẩn cấp cũng như thời gian phản hồi cần thiết cho ticket.
Vì sao điều này quan trọng Theo dõi thời điểm và cách đặt mức ưu tiên rất quan trọng đối với dashboard “Chỉ số hiệu quả ưu tiên”, giúp đảm bảo các vấn đề nghiêm trọng được xử lý kịp thời. Lấy dữ liệu ở đâu Lấy từ sự kiện 'Change' trên trường 'priority' trong nhật ký kiểm tra ticket. Bạn cũng có thể theo dõi các lần thay đổi tiếp theo để đo KPI Tỷ lệ thay đổi mức ưu tiên. Thu thập Được xác định qua sự kiện 'Change' của trường 'priority' trong nhật ký kiểm tra ticket. Loại sự kiện explicit
	Không đạt mục tiêu SLA	Đánh dấu thời điểm ticket không đáp ứng thỏa thuận mức dịch vụ đã xác định, chẳng hạn thời gian phản hồi đầu tiên hoặc thời gian xử lý. Sự kiện này được tính dựa trên định nghĩa chính sách SLA và dấu thời gian cập nhật ticket.
Vì sao điều này quan trọng Sự kiện này hỗ trợ trực tiếp việc theo dõi tuân thủ SLA. Xác định thời điểm và nguyên nhân xảy ra vi phạm là bước thiết yếu để nâng cao độ tin cậy của dịch vụ và lòng tin của khách hàng. Lấy dữ liệu ở đâu Đây là sự kiện được tính toán. Có thể suy ra sự kiện này bằng cách phân tích dữ liệu 'sla_policy_metrics' gắn với ticket, dùng dấu thời gian 'breached_at' của từng mục tiêu SLA. Thu thập Suy ra từ dấu thời gian 'breached_at' trong dữ liệu chỉ số SLA của ticket. Loại sự kiện calculated
	Người dùng đánh giá mức độ hài lòng	Đây là thời điểm người dùng cuối đánh giá mức độ hài lòng với dịch vụ hỗ trợ đã nhận. Zendesk ghi nhận rõ sự kiện này sau khi ticket được xử lý xong.
Vì sao điều này quan trọng Phân tích điểm đánh giá mức độ hài lòng cung cấp phản hồi quan trọng về hiệu suất của nhân viên hỗ trợ và hiệu quả quy trình, giúp liên kết chỉ số quy trình với kết quả dành cho khách hàng. Lấy dữ liệu ở đâu Lấy từ dữ liệu đánh giá mức độ hài lòng gắn với ticket. Dữ liệu này thường gồm điểm đánh giá ('good' hoặc 'bad') và bình luận tùy chọn. Thu thập Ghi nhận sự kiện khi có người gửi đánh giá mức độ hài lòng cho ticket. Loại sự kiện explicit
	Ticket được giao cho nhóm	Đây là bước định tuyến hoặc phân loại ban đầu, đưa sự cố đến một nhóm hỗ trợ cụ thể. Thường đây là bước đầu tiên để xác định trách nhiệm xử lý và được ghi lại thành sự kiện thay đổi trong lịch sử kiểm tra của ticket.
Vì sao điều này quan trọng Theo dõi việc giao ticket cho nhóm giúp phân tích hiệu quả phân loại ban đầu và phát hiện chậm trễ trước khi ticket được chuyển đến đúng đội. Lấy dữ liệu ở đâu Lấy từ nhật ký kiểm tra ticket mỗi khi trường 'group_id' được thiết lập hoặc thay đổi. Lần thay đổi đầu tiên sau khi tạo ticket là lần giao nhóm ban đầu. Thu thập Được xác định qua sự kiện 'Change' của trường 'group_id' trong nhật ký kiểm tra ticket. Loại sự kiện explicit
	Trạng thái chuyển thành Pending	Cho biết quy trình đang tạm dừng để chờ người gửi yêu cầu phản hồi. Sự kiện này được suy ra khi trường 'status' của ticket chuyển thành 'pending'.
Vì sao điều này quan trọng Hoạt động này rất quan trọng để tính Thời gian chờ người dùng xác nhận. Thời gian ở trạng thái này kéo dài có thể làm tăng đáng kể tổng thời gian xử lý và cho thấy việc trao đổi đang bị chậm. Lấy dữ liệu ở đâu Suy ra từ nhật ký kiểm tra ticket bằng cách tìm sự kiện 'Change' trong đó giá trị mới của trường 'status' là 'pending'. Thu thập Suy ra từ thay đổi trường trạng thái thành 'pending'. Loại sự kiện inferred

Nên có Không bắt buộc

Hướng dẫn trích xuất

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

Các bước

Mở Zendesk Explore: Đăng nhập vào Zendesk Support bằng tài khoản người dùng có quyền tạo và quản lý báo cáo trong Zendesk Explore.
Tạo báo cáo mới: Mở mô-đun Explore. Nhấp vào biểu tượng 'Reports' trên thanh điều hướng bên trái, sau đó nhấp vào nút 'New report'.
Chọn bộ dữ liệu: Trong cửa sổ 'Choose a dataset', chọn bộ dữ liệu Support: Ticket updates [default]. Bộ dữ liệu này lưu lịch sử kiểm tra của mọi thay đổi trên phiếu, cần thiết để tạo nhật ký sự kiện.
Thêm thuộc tính ban đầu (cột): Trong trình tạo báo cáo, mở phần 'Rows'. Nhấp 'Add' và chọn các thuộc tính sau. Chúng sẽ trở thành các cột trong nhật ký sự kiện: Ticket ID, Update - Timestamp, Ticket status, Assignee name, Ticket group, Ticket priority, Ticket channel, Changes - Field name, Changes - Previous value, Changes - New value, Comment public.
Tạo thuộc tính tính toán: Đây là bước quan trọng nhất. Mở menu 'Calculations' (biểu tượng bình thí nghiệm) và chọn 'Standard calculated attribute'. Tạo ba thuộc tính trong phần 'Query' bên dưới: ActivityName, SourceSystem và LastDataUpdate. Sao chép chính xác các công thức được cung cấp.
Chỉnh sửa các cột báo cáo: Thêm các thuộc tính tính toán vừa tạo (ActivityName, SourceSystem, LastDataUpdate) vào phần 'Rows'. Sau đó, bạn có thể xóa các trường dữ liệu thô dùng để tạo ActivityName (Changes - Field name, Changes - Previous value, Changes - New value, Comment public) để bảng gọn hơn.
Thêm bộ lọc báo cáo: Mở phần 'Filters' và nhấp 'Add'. Thêm bộ lọc cho Update - Date và chọn khoảng ngày phù hợp, chẳng hạn 3 tháng gần nhất. Thêm bộ lọc khác cho thuộc tính tính toán ActivityName và loại các giá trị null để bỏ những cập nhật phiếu không tương ứng với hoạt động cần theo dõi.
Chạy và kiểm tra báo cáo: Zendesk Explore tự cập nhật báo cáo khi bạn thêm thuộc tính và bộ lọc. Kiểm tra bảng dữ liệu để đảm bảo các hàng và cột hiển thị như mong muốn. Báo cáo cần có một hàng cho mỗi sự kiện.
Xuất dữ liệu sang CSV: Khi hoàn tất báo cáo, nhấp nút 'Export' ở góc trên bên phải và chọn 'CSV'. Zendesk sẽ tạo và tải tệp CSV xuống.
Chuẩn bị tải lên: Mở tệp CSV đã xuất. Đổi tên tiêu đề cột cho khớp với tên thuộc tính mà công cụ process mining yêu cầu, chẳng hạn đổi 'Ticket ID' thành TicketId và 'Update - Timestamp' thành EventTimestamp. Đảm bảo dấu thời gian dùng định dạng ISO 8601. Tệp đã sẵn sàng để tải lên.

Cấu hình

Bộ dữ liệu Zendesk: Báo cáo phải dựa trên bộ dữ liệu Support: Ticket updates [default]. Đây là bộ dữ liệu tiêu chuẩn duy nhất có lịch sử kiểm tra chi tiết cần thiết để dựng lại quy trình theo từng sự kiện.
Lọc theo khoảng ngày: Bạn cần lọc ngày để giới hạn lượng dữ liệu. Dùng thuộc tính Update - Date làm bộ lọc chính. Với lần phân tích đầu tiên, thường nên lấy dữ liệu trong 3-6 tháng.
Lọc hoạt động: Sau khi tạo thuộc tính tính toán ActivityName, hãy lọc báo cáo để loại các hàng có giá trị null. Việc này loại bỏ những thay đổi phiếu không liên quan, chẳng hạn cập nhật hệ thống hoặc thay đổi thẻ, khỏi nhật ký sự kiện.
Thuộc tính tính toán: Việc trích xuất phụ thuộc nhiều vào thuộc tính tính toán tiêu chuẩn để chuyển các thay đổi trường dữ liệu thô của phiếu thành tên hoạt động dễ hiểu. Công thức cần chính xác.
Điều kiện cần có: Người chạy báo cáo cần có ít nhất vai trò 'Viewer' trong Zendesk Explore. Để tạo và lưu báo cáo, cần quyền 'Editor' hoặc 'Admin'.

Truy vấn mẫu config

This extraction is configured using the Zendesk Explore UI. The core logic is contained within a standard calculated attribute. 

**1. Dataset Selection:**
* `Support: Ticket updates [default]`

**2. Report Columns (Add to 'Rows' panel):**
* `Ticket ID`
* `ActivityName` (Calculated Attribute)
* `EventTimestamp` (Use the `Update - Timestamp` attribute)
* `SourceSystem` (Calculated Attribute)
* `LastDataUpdate` (Calculated Attribute)
* `Ticket status`
* `Assignee name`
* `Ticket group`
* `Ticket priority`
* `Ticket channel`
* `SLA metric status`
* `EventEndTime` (Use the `Update - Timestamp` attribute again)

**3. Standard Calculated Attribute Formulas:**

**Attribute Name:** `ActivityName`
**Formula:**
```
IF ([Changes - Field name] = "status" AND [Changes - Previous value] = NULL AND [Changes - New value] = "new") THEN "Incident Created"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "open") THEN "Status Changed to Open"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN "Status Changed to Pending"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "solved") THEN "Incident Resolved"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "closed") THEN "Incident Closed"
ELIF ([Changes - Field name] = "group_id") THEN "Ticket Assigned to Group"
ELIF ([Changes - Field name] = "assignee_id") THEN "Ticket Assigned to Agent"
ELIF ([Changes - Field name] = "priority") THEN "Priority Set"
ELIF ([Changes - Field name] = "satisfaction_score") THEN "User Satisfaction Rated"
ELIF ([Changes - Field name] = "SLA metric breach") THEN "SLA Target Breached"
ELIF ([Comment public] = TRUE) THEN "Public Reply Sent"
ELIF ([Comment public] = FALSE) THEN "Internal Note Added"
ELSE NULL
ENDIF
```

**Attribute Name:** `SourceSystem`
**Formula:**
```
"Zendesk Support"
```

**Attribute Name:** `LastDataUpdate`
**Formula:**
```
NOW()
```

Các bước

Điều kiện cần có: Đảm bảo hệ thống đã cài Python 3.6 trở lên cùng các thư viện requests và pandas. Bạn có thể cài bằng pip: pip install requests pandas.
Tạo Zendesk API Token: Đăng nhập vào Zendesk Support bằng tài khoản quản trị viên. Mở Admin Center > Apps and integrations > APIs > Zendesk APIs. Trong phần "API Tokens", thêm API token mới đang hoạt động và lưu an toàn chuỗi token được tạo.
Cấu hình Python Script: Tạo tệp Python mới, chẳng hạn extract_zendesk_logs.py, rồi sao chép script được cung cấp vào đó. Cập nhật các biến giữ chỗ ở đầu script bằng thông tin của bạn: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL và ZENDESK_API_TOKEN. Đặt START_TIMESTAMP để xác định thời điểm bắt đầu trích xuất dữ liệu mong muốn (dấu thời gian Unix epoch).
Tìm hiểu các API endpoint: Script chủ yếu dùng hai API endpoint của Zendesk. Endpoint incremental/tickets/cursor.json giúp lấy hiệu quả tất cả phiếu được cập nhật kể từ START_TIMESTAMP. Với mỗi phiếu, script gọi endpoint tickets/{ticket_id}/audits.json để lấy lịch sử chi tiết của mọi thay đổi và sự kiện.
Chạy script: Chạy lệnh sau trong terminal: python extract_zendesk_logs.py. Script sẽ bắt đầu lấy dữ liệu từ Zendesk API.
Theo dõi tiến độ: Script sẽ in số phiếu đã xử lý ra cửa sổ dòng lệnh để bạn theo dõi. Tùy khoảng ngày và số lượng phiếu, quá trình này có thể mất khá nhiều thời gian.
Lấy dữ liệu và phân trang: Script tự xử lý phân trang API. Script bắt đầu từ URL xuất phiếu ban đầu rồi tiếp tục theo after_url trong từng phản hồi API cho đến khi lấy đủ phiếu trong khoảng thời gian.
Chuyển đổi sự kiện: Với mỗi phiếu, script duyệt lịch sử kiểm tra. Script phân tích từng sự kiện và ánh xạ loại sự kiện nội bộ của Zendesk, như Create, Change, Comment, sang hoạt động nghiệp vụ tương ứng, như Incident Created, Status Changed to Open, Public Reply Sent.
Xử lý dữ liệu SLA: Script có hàm riêng get_sla_breach_events để lấy chỉ số SLA cho từng phiếu đã giải quyết. Cần bước này vì vi phạm SLA không phải là sự kiện tiêu chuẩn trong nhật ký kiểm tra. Hàm sẽ gọi API bổ sung để lấy thông tin áp dụng chính sách SLA.
Tạo nhật ký sự kiện: Sau khi xử lý tất cả phiếu, script tổng hợp các sự kiện đã trích xuất vào pandas DataFrame và lưu nhật ký sự kiện cuối cùng thành tệp CSV có tên zendesk_incident_event_log.csv trong thư mục chạy script.
Chuẩn bị tải lên: Kiểm tra tệp CSV vừa tạo để đảm bảo dữ liệu chính xác. Tệp đã đúng định dạng để tải trực tiếp lên ProcessMind phân tích.

Cấu hình

Thông tin xác thực Zendesk API: Bạn cần cung cấp tên miền phụ Zendesk, địa chỉ email gắn với tài khoản quản trị viên hoặc nhân viên hỗ trợ và API token hợp lệ. Lưu an toàn các thông tin này. Khi triển khai thực tế, không ghi cứng chúng trong script được quản lý bằng hệ thống kiểm soát phiên bản.
Dấu thời gian bắt đầu (START_TIMESTAMP): Giá trị số nguyên này xác định thời điểm bắt đầu trích xuất dữ liệu. Giá trị phải là dấu thời gian Unix epoch. Nên chọn thời điểm cách hiện tại 3-6 tháng để thu thập đủ dữ liệu mà không gây quá tải hệ thống. Bạn có thể dùng công cụ chuyển đổi trực tuyến để lấy dấu thời gian chính xác cho một ngày cụ thể.
Giới hạn tốc độ API: Script thực hiện nhiều lệnh gọi API. Zendesk áp dụng giới hạn tốc độ khác nhau tùy gói dịch vụ. Script phù hợp với lượng dữ liệu vừa phải. Với hệ thống rất lớn, bạn có thể cần thêm lệnh time.sleep() trong các vòng lặp để tránh vượt giới hạn và nhận lỗi 429.
Thư viện Python cần thiết: Script dùng thư viện requests để gọi API và pandas để xử lý dữ liệu, xuất CSV. Đảm bảo đã cài các thư viện này trong môi trường Python.
Quyền người dùng: Tài khoản gắn với API token phải có đủ quyền đọc dữ liệu phiếu, bao gồm lịch sử kiểm tra và chỉ số phiếu.

Truy vấn mẫu python

import requests
import pandas as pd
import time
import os
from datetime import datetime

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">"[your_subdomain]"
ZENDESK_EMAIL = class="hl-string">"[your_login_email@example.com]"
ZENDESK_API_TOKEN = class="hl-string">"[your_zendesk_api_token]"

class=class="hl-string">"hl-comment"># Set the start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is for January 1, 2023 00:00:00 UTC
class=class="hl-string">"hl-comment"># It's recommended to extract the last 3-6 months of data.
START_TIMESTAMP = 1672531200 

class=class="hl-string">"hl-comment"># --- SCRIPT --- 
BASE_URL = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2"
AUTH = (fclass="hl-string">"{ZENDESK_EMAIL}/token", ZENDESK_API_TOKEN)
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"
LAST_DATA_UPDATE = datetime.utcnow().isoformat() + class="hl-string">'Z'

def get_sla_breach_events(ticket_id, session):
    class="hl-string">"""Fetches SLA metrics for a ticket and creates breach events."""
    sla_events = []
    try:
        metrics_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/metrics.json"
        response = session.get(metrics_url)
        response.raise_for_status()
        metrics = response.json().get(class="hl-string">'ticket_metric', {})
        
        if metrics and metrics.get(class="hl-string">'sla_policy'):
            for sla in metrics.get(class="hl-string">'sla_policy').get(class="hl-string">'policy_metrics', []):
                if sla.get(class="hl-string">'breach_at'):
                    breach_timestamp = sla[class="hl-string">'breach_at']
                    sla_events.append({
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'ActivityName': class="hl-string">'SLA Target Breached',
                        class="hl-string">'EventTimestamp': breach_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': class="hl-string">'breached',
                        class="hl-string">'Assignee': metrics.get(class="hl-string">'assignee_updated_at'), 
                        class="hl-string">'AssignedGroup': metrics.get(class="hl-string">'group_stations'),
                        class="hl-string">'TicketPriority': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'Channel': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'SlaStatus': fclass="hl-string">"{sla.get('metric')} Breached",
                        class="hl-string">'EventEndTime': breach_timestamp
                    })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not fetch SLA metrics for ticket {ticket_id}: {e}")
    return sla_events

def process_ticket(ticket, session):
    class="hl-string">"""Processes a single ticket's audits to extract all relevant events."""
    all_events = []
    ticket_id = ticket[class="hl-string">'id']
    ticket_created_at = ticket[class="hl-string">'created_at']
    
    class=class="hl-string">"hl-comment"># 1. Incident Created event
    all_events.append({
        class="hl-string">'TicketId': ticket_id,
        class="hl-string">'ActivityName': class="hl-string">'Incident Created',
        class="hl-string">'EventTimestamp': ticket_created_at,
        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
        class="hl-string">'TicketStatus': class="hl-string">'new',
        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
        class="hl-string">'SlaStatus': None,
        class="hl-string">'EventEndTime': ticket_created_at
    })
    
    class=class="hl-string">"hl-comment"># Process audits for other events
    audits_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    try:
        response = session.get(audits_url)
        response.raise_for_status()
        audits = response.json().get(class="hl-string">'audits', [])
        
        is_first_group_assignment = True
        is_first_agent_assignment = True

        for audit in audits:
            event_timestamp = audit[class="hl-string">'created_at']
            for event in audit.get(class="hl-string">'events', []):
                activity = {}
                event_type = event.get(class="hl-string">'type')

                if event_type == class="hl-string">'Change':
                    field_name = event.get(class="hl-string">'field_name')
                    value = event.get(class="hl-string">'value')
                    
                    if field_name == class="hl-string">'group_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Group' if is_first_group_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_group_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'AssignedGroup': value}

                    elif field_name == class="hl-string">'assignee_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Agent' if is_first_agent_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_agent_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'Assignee': value}
                        
                    elif field_name == class="hl-string">'priority':
                        activity = {class="hl-string">'ActivityName': class="hl-string">'Priority Set', class="hl-string">'TicketPriority': value}
                        
                    elif field_name == class="hl-string">'status':
                        if value == class="hl-string">'open': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Open', class="hl-string">'TicketStatus': class="hl-string">'open'}
                        elif value == class="hl-string">'pending': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Pending', class="hl-string">'TicketStatus': class="hl-string">'pending'}
                        elif value == class="hl-string">'solved': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Resolved', class="hl-string">'TicketStatus': class="hl-string">'solved'}
                        elif value == class="hl-string">'closed': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Closed', class="hl-string">'TicketStatus': class="hl-string">'closed'}
                        
                elif event_type == class="hl-string">'Comment':
                    is_public = event.get(class="hl-string">'public', False)
                    activity_name = class="hl-string">'Public Reply Sent' if is_public else class="hl-string">'Internal Note Added'
                    activity = {class="hl-string">'ActivityName': activity_name}

                elif event_type == class="hl-string">'SatisfactionRating':
                    activity = {class="hl-string">'ActivityName': class="hl-string">'User Satisfaction Rated'}

                if activity:
                    base_event = {
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'EventTimestamp': event_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': ticket.get(class="hl-string">'status'),
                        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
                        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
                        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaStatus': None,
                        class="hl-string">'EventEndTime': event_timestamp
                    }
                    base_event.update(activity)
                    all_events.append(base_event)
    
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not process audits for ticket {ticket_id}: {e}")

    class=class="hl-string">"hl-comment"># Get SLA Breach events if ticket is solved
    if ticket.get(class="hl-string">'status') in [class="hl-string">'solved', class="hl-string">'closed']:
        all_events.extend(get_sla_breach_events(ticket_id, session))

    return all_events

def main():
    class="hl-string">"""Main function to fetch tickets and generate the event log."""
    all_ticket_events = []
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}"
    
    with requests.Session() as session:
        session.auth = AUTH
        
        ticket_count = 0
        while url:
            try:
                response = session.get(url)
                response.raise_for_status()
                data = response.json()
                tickets = data.get(class="hl-string">'tickets', [])
                
                for ticket in tickets:
                    ticket_count += 1
                    all_ticket_events.extend(process_ticket(ticket, session))
                    if ticket_count % 100 == 0:
                        print(fclass="hl-string">"Processed {ticket_count} tickets...")

                if data.get(class="hl-string">'end_of_stream', True):
                    print(class="hl-string">"Reached the end of the ticket stream.")
                    break
                
                url = data.get(class="hl-string">'after_url')
                class=class="hl-string">"hl-comment"># Respect rate limits
                time.sleep(1) 

            except requests.exceptions.RequestException as e:
                print(fclass="hl-string">"An API error occurred: {e}")
                if hasattr(e, class="hl-string">'response') and e.response.status_code == 429:
                    retry_after = int(e.response.headers.get(class="hl-string">'Retry-After', 60))
                    print(fclass="hl-string">"Rate limit exceeded. Retrying after {retry_after} seconds...")
                    time.sleep(retry_after)
                else:
                    break

    if not all_ticket_events:
        print(class="hl-string">"No events were extracted. Check configuration and API access.")
        return

    print(fclass="hl-string">"\nTotal events extracted: {len(all_ticket_events)}")
    df = pd.DataFrame(all_ticket_events)
    
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    cols = [
        class="hl-string">'TicketId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventEndTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'TicketStatus', class="hl-string">'Assignee', class="hl-string">'AssignedGroup', class="hl-string">'TicketPriority', class="hl-string">'Channel', class="hl-string">'SlaStatus'
    ]
    df = df[cols]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    output_file = class="hl-string">'zendesk_incident_event_log.csv'
    df.to_csv(output_file, index=False)
    print(fclass="hl-string">"Event log successfully saved to {output_file}")

if __name__ == class="hl-string">"__main__":
    main()

Các bước

Tạo ứng dụng khách Zendesk API có quyền đọc phiếu, lịch sử kiểm tra phiếu, người dùng, nhóm, điểm hài lòng và dữ liệu xuất tăng dần. Dùng mã thông báo API hoặc thông tin xác thực OAuth được cấu hình cho Zendesk Support của bạn. Lưu tên miền phụ, thông tin xác thực và mốc thời gian trích xuất dưới dạng giá trị cấu hình an toàn.
Dùng Zendesk Incremental Ticket Export API để lấy các phiếu được cập nhật sau mốc thời gian thành công gần nhất. Tập lệnh bên dưới dùng mẫu điểm cuối đã được tài liệu hóa, https://[Your Zendesk subdomain].zendesk.com/api/v2/incremental/tickets/cursor.json, và phân trang bằng con trỏ cho đến khi API báo đã trả về đầy đủ kết quả.
Với mỗi phiếu được trả về, hãy gọi điểm cuối lịch sử kiểm tra phiếu để lấy lịch sử kiểm tra. Cần có các bản ghi này vì ProcessMind đọc nguyên trạng nhật ký sự kiện, không suy ra hoạt động từ trạng thái cuối cùng của phiếu. Giữ nguyên dấu thời gian kiểm tra, người thực hiện, mã phiếu và các sự kiện kiểm tra.
Chuyển các sự kiện kiểm tra thành từng dòng sự kiện cụ thể. Trích xuất các sự kiện tạo phiếu, phân công nhóm, phân công nhân viên hỗ trợ, thay đổi mức độ ưu tiên, đổi trạng thái sang đang mở, trả lời công khai, ghi chú nội bộ, chuyển giao, đổi trạng thái sang chờ xử lý, chuyển sang trạng thái đã giải quyết và đóng phiếu. Nếu có điểm hài lòng, hãy trích xuất thành các dòng riêng. Chỉ tính vi phạm SLA khi có đủ mục tiêu SLA và dấu thời gian sự kiện cần thiết, đồng thời ghi lại các dữ liệu đầu vào dùng để tính.
Lưu dấu thời gian cập nhật thành công gần nhất hoặc con trỏ mới nhất. Chỉ cập nhật mốc thời gian sau khi đã ghi thành công tất cả các trang, lịch sử kiểm tra phiếu và dữ liệu hài lòng tùy chọn. Trong lần chạy đầu tiên, hãy đặt thời điểm bắt đầu có giới hạn, chẳng hạn [Start date in ISO 8601 format], thường bao phủ từ ba đến sáu tháng.
Điền các cột bắt buộc TicketId, ActivityName, EventTimestamp, SourceSystem và LastDataUpdate. Điền các cột nên có TicketStatus, Assignee, AssignedGroup, TicketPriority, Channel, SlaStatus và EventEndTime khi dữ liệu nguồn hỗ trợ. Chỉ để trống khi Zendesk không cung cấp thuộc tính đó cho sự kiện.
Loại bỏ bản ghi trùng dựa trên TicketId, ActivityName, EventTimestamp và mã sự kiện nguồn ổn định nếu có. Giữ lại các lần lặp hợp lệ của cùng một hoạt động, chẳng hạn nhiều câu trả lời công khai, ghi chú nội bộ, lần phân công hoặc thay đổi trạng thái.
Ghi các dòng kết quả vào CSV hoặc định dạng nhật ký sự kiện khác mà ProcessMind hỗ trợ. Đảm bảo dấu thời gian theo ISO 8601 có múi giờ UTC rõ ràng, TicketId luôn cùng kiểu dữ liệu, giá trị ActivityName khớp chính xác với tên hoạt động đã quy định và LastDataUpdate giống nhau trên mọi dòng trong cùng một đợt trích xuất.
Tải nhật ký sự kiện lên ProcessMind và đặt Mã sự cố làm mã trường hợp, Hoạt động làm cột hoạt động và Thời gian sự kiện làm cột thời gian sự kiện. Kiểm tra để đảm bảo mỗi hoạt động bắt buộc đều có dòng dữ liệu cụ thể, thay vì được suy ra khi trực quan hóa.

Cấu hình

Phương thức API: Zendesk Incremental Ticket Export API có phân trang bằng cursor. Dùng endpoint ticket audit để trích xuất từng sự kiện và endpoint mức độ hài lòng khi tính năng này được bật và có quyền truy cập.
Cấu hình bắt buộc: tên miền phụ Zendesk, phương thức xác thực API, ngày bắt đầu ban đầu, mốc thời gian trích xuất, thời gian chờ yêu cầu, chính sách thử lại và vị trí lưu kết quả. Thay [Your Zendesk subdomain], [Your API email] và [Your API token] bằng thông tin bảo mật dùng khi triển khai.
Khoảng ngày: Với lần tải đầu tiên, lấy dữ liệu trong ba đến sáu tháng, trừ khi cần lịch sử dài hơn. Với các lần tải định kỳ, yêu cầu bản ghi sau mốc thời gian thành công gần nhất và thêm một khoảng chồng lấn ngắn để tránh bỏ sót cập nhật đến muộn, sau đó loại bản ghi trùng.
Bộ lọc: Chỉ lọc theo công ty, thương hiệu, nhóm, tổ chức, biểu mẫu phiếu, kênh hoặc trường tùy chỉnh khi phạm vi quy trình yêu cầu rõ ràng. Zendesk Support không dùng bộ lọc Company Code hoặc Document Type theo kiểu SAP, trừ khi các khái niệm này được thể hiện bằng trường Zendesk đã cấu hình.
Ý nghĩa sự kiện: Dùng sự kiện kiểm tra làm nguồn chính thức cho các thay đổi cụ thể. Không tạo sự kiện đổi trạng thái chỉ vì phiếu hiện có một giá trị trạng thái. Chỉ tạo sự kiện trạng thái từ sự kiện kiểm tra hoặc một sự kiện nguồn khác đã được ghi nhận trong tài liệu.
Cấu hình SLA: Để xác định SLA Target Breached, cần truy cập chính sách SLA áp dụng, thời lượng mục tiêu, lịch giờ làm việc và dấu thời gian cần thiết để đánh giá mục tiêu. Nếu Zendesk cung cấp sự kiện hoặc chỉ số vi phạm, hãy dùng nguồn đó. Nếu không, chỉ tính khi có dữ liệu chính sách được ghi rõ và lưu lại cơ sở tính toán.
Cấu hình mức độ hài lòng: User Satisfaction Rated yêu cầu bật tính năng đánh giá mức độ hài lòng và có thể truy cập bản ghi đánh giá qua API. Không tạo sự kiện đánh giá giả cho phiếu đã giải quyết nhưng chưa có đánh giá.
Hiệu suất: Dùng phân trang bằng cursor, giới hạn số yêu cầu đồng thời khi lấy lịch sử kiểm tra phiếu, tái sử dụng kết nối, tăng dần thời gian chờ giữa các lần thử lại khi chạm giới hạn tốc độ và lưu điểm kiểm tra sau mỗi đợt thành công. Tránh lấy lại toàn bộ lịch sử kiểm tra của mọi phiếu trong mỗi lần chạy.
Tính đầy đủ: Dữ liệu xuất tăng dần có thể bao gồm phiếu được cập nhật sau thời điểm yêu cầu, nhưng cần xử lý riêng việc lấy lịch sử kiểm tra và các cập nhật đến muộn. Dùng khoảng chồng lấn và khóa loại trùng ổn định.
Điều kiện cần có: Quyền truy cập API, quyền đọc phiếu và lịch sử kiểm tra, quyền truy cập người dùng và nhóm để tra cứu tên, quyền truy cập dữ liệu mức độ hài lòng nếu cần và dữ liệu SLA nếu cần tính vi phạm. Các loại sự kiện kiểm tra cụ thể có thể khác nhau tùy cấu hình và gói Zendesk.

Truy vấn mẫu python

import csv
import json
import os
import time
from datetime import datetime, timezone, timedelta
from typing import Any, Dict, Iterable, List, Optional, Tuple

import requests

ZENDESK_SUBDOMAIN = os.getenv(class="hl-string">"ZENDESK_SUBDOMAIN", class="hl-string">"[Your Zendesk subdomain]")
API_EMAIL = os.getenv(class="hl-string">"ZENDESK_API_EMAIL", class="hl-string">"[Your API email]")
API_TOKEN = os.getenv(class="hl-string">"ZENDESK_API_TOKEN", class="hl-string">"[Your API token]")
START_DATE = os.getenv(class="hl-string">"START_DATE", class="hl-string">"[Start date in ISO 8601 format]")
OUTPUT_FILE = os.getenv(class="hl-string">"OUTPUT_FILE", class="hl-string">"incident_event_log.csv")
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"
LAST_DATA_UPDATE = datetime.now(timezone.utc).isoformat()

if class="hl-string">"[" in ZENDESK_SUBDOMAIN or class="hl-string">"[" in API_EMAIL or class="hl-string">"[" in API_TOKEN or class="hl-string">"[" in START_DATE:
    raise ValueError(class="hl-string">"Set ZENDESK_SUBDOMAIN, ZENDESK_API_EMAIL, ZENDESK_API_TOKEN, and START_DATE before running")

BASE_URL = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2"
SESSION = requests.Session()
SESSION.auth = (fclass="hl-string">"{API_EMAIL}/token", API_TOKEN)
SESSION.headers.update({class="hl-string">"Accept": class="hl-string">"application/json"})

FIELDS = [
    class="hl-string">"TicketId", class="hl-string">"ActivityName", class="hl-string">"EventTimestamp", class="hl-string">"SourceSystem", class="hl-string">"LastDataUpdate",
    class="hl-string">"TicketStatus", class="hl-string">"Assignee", class="hl-string">"AssignedGroup", class="hl-string">"TicketPriority", class="hl-string">"Channel",
    class="hl-string">"SlaStatus", class="hl-string">"EventEndTime"
]


def parse_time(value: Optional[str]) -> Optional[datetime]:
    if not value:
        return None
    return datetime.fromisoformat(value.replace(class="hl-string">"Z", class="hl-string">"+00:00"))


def iso(value: Any) -> str:
    if isinstance(value, datetime):
        return value.astimezone(timezone.utc).isoformat()
    if value is None:
        return class="hl-string">""
    return str(value)


def get_json(url: str, params: Optional[Dict[str, Any]] = None) -> Dict[str, Any]:
    for attempt in range(6):
        response = SESSION.get(url, params=params, timeout=60)
        if response.status_code == 429:
            retry_after = int(response.headers.get(class="hl-string">"Retry-After", class="hl-string">"5"))
            time.sleep(max(retry_after, 2 ** attempt))
            continue
        response.raise_for_status()
        return response.json()
    raise RuntimeError(fclass="hl-string">"Request failed after retries: {url}")


def incremental_tickets(start_time: str) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json"
    params: Optional[Dict[str, Any]] = {class="hl-string">"start_time": int(parse_time(start_time).timestamp())}
    while url:
        payload = get_json(url, params)
        for ticket in payload.get(class="hl-string">"tickets", []):
            yield ticket
        if payload.get(class="hl-string">"end_of_stream"):
            break
        url = payload.get(class="hl-string">"after_url")
        params = None


def ticket_audits(ticket_id: int) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    while url:
        payload = get_json(url)
        for audit in payload.get(class="hl-string">"audits", []):
            yield audit
        url = payload.get(class="hl-string">"next_page")


def satisfaction_for_ticket(ticket_id: int) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/satisfaction_ratings.json"
    try:
        payload = get_json(url)
    except requests.HTTPError as error:
        if error.response is not None and error.response.status_code in (403, 404):
            return
        raise
    for rating in payload.get(class="hl-string">"satisfaction_ratings", []):
        yield rating


def user_name(user_id: Any, cache: Dict[str, str]) -> str:
    if not user_id:
        return class="hl-string">""
    key = str(user_id)
    if key not in cache:
        payload = get_json(fclass="hl-string">"{BASE_URL}/users/{user_id}.json")
        user = payload.get(class="hl-string">"user", {})
        cache[key] = user.get(class="hl-string">"name") or user.get(class="hl-string">"email") or key
    return cache[key]


def group_name(group_id: Any, cache: Dict[str, str]) -> str:
    if not group_id:
        return class="hl-string">""
    key = str(group_id)
    if key not in cache:
        payload = get_json(fclass="hl-string">"{BASE_URL}/groups/{group_id}.json")
        cache[key] = payload.get(class="hl-string">"group", {}).get(class="hl-string">"name") or key
    return cache[key]


def ticket_context(ticket: Dict[str, Any], users: Dict[str, str], groups: Dict[str, str]) -> Dict[str, str]:
    assignee = user_name(ticket.get(class="hl-string">"assignee_id"), users)
    group = group_name(ticket.get(class="hl-string">"group_id"), groups)
    return {
        class="hl-string">"TicketStatus": str(ticket.get(class="hl-string">"status") or class="hl-string">""),
        class="hl-string">"Assignee": assignee,
        class="hl-string">"AssignedGroup": group,
        class="hl-string">"TicketPriority": str(ticket.get(class="hl-string">"priority") or class="hl-string">""),
        class="hl-string">"Channel": str((ticket.get(class="hl-string">"via") or {}).get(class="hl-string">"channel") or class="hl-string">""),
        class="hl-string">"SlaStatus": class="hl-string">"",
    }


def make_row(ticket_id: Any, activity: str, event_time: Any, context: Dict[str, str], end_time: Any = class="hl-string">"") -> Dict[str, str]:
    row = {
        class="hl-string">"TicketId": str(ticket_id),
        class="hl-string">"ActivityName": activity,
        class="hl-string">"EventTimestamp": iso(event_time),
        class="hl-string">"SourceSystem": SOURCE_SYSTEM,
        class="hl-string">"LastDataUpdate": LAST_DATA_UPDATE,
        class="hl-string">"TicketStatus": context.get(class="hl-string">"TicketStatus", class="hl-string">""),
        class="hl-string">"Assignee": context.get(class="hl-string">"Assignee", class="hl-string">""),
        class="hl-string">"AssignedGroup": context.get(class="hl-string">"AssignedGroup", class="hl-string">""),
        class="hl-string">"TicketPriority": context.get(class="hl-string">"TicketPriority", class="hl-string">""),
        class="hl-string">"Channel": context.get(class="hl-string">"Channel", class="hl-string">""),
        class="hl-string">"SlaStatus": context.get(class="hl-string">"SlaStatus", class="hl-string">""),
        class="hl-string">"EventEndTime": iso(end_time),
    }
    return row


def audit_value(audit_event: Dict[str, Any], field: str) -> Any:
    for change in audit_event.get(class="hl-string">"changes", []):
        if change.get(class="hl-string">"field") == field:
            return change
    return None


def append_audit_rows(ticket: Dict[str, Any], audit: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    ticket_id = ticket.get(class="hl-string">"id")
    event_time = audit.get(class="hl-string">"created_at")
    context = ticket_context(ticket, users, groups)
    author = user_name(audit.get(class="hl-string">"author_id"), users)
    for change in audit.get(class="hl-string">"events", []):
        event_type = change.get(class="hl-string">"type")
        field = change.get(class="hl-string">"field")
        value = change.get(class="hl-string">"value")
        previous = change.get(class="hl-string">"previous_value")
        if event_type == class="hl-string">"Create" or field == class="hl-string">"created_at":
            rows.append(make_row(ticket_id, class="hl-string">"Incident Created", event_time, context))
        if field == class="hl-string">"group_id" and value is not None:
            context[class="hl-string">"AssignedGroup"] = group_name(value, groups)
            if previous not in (None, class="hl-string">"", value):
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Reassigned", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Assigned to Group", event_time, context))
        if field == class="hl-string">"assignee_id" and value is not None:
            context[class="hl-string">"Assignee"] = user_name(value, users)
            if previous not in (None, class="hl-string">"", value):
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Reassigned", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Assigned to Agent", event_time, context))
        if field == class="hl-string">"priority" and value is not None:
            context[class="hl-string">"TicketPriority"] = str(value)
            rows.append(make_row(ticket_id, class="hl-string">"Priority Set", event_time, context))
        if field == class="hl-string">"status":
            context[class="hl-string">"TicketStatus"] = str(value or class="hl-string">"")
            if value == class="hl-string">"open":
                rows.append(make_row(ticket_id, class="hl-string">"Status Changed to Open", event_time, context))
            if value == class="hl-string">"pending":
                rows.append(make_row(ticket_id, class="hl-string">"Status Changed to Pending", event_time, context))
            if value == class="hl-string">"solved":
                rows.append(make_row(ticket_id, class="hl-string">"Incident Resolved", event_time, context))
            if value == class="hl-string">"closed":
                rows.append(make_row(ticket_id, class="hl-string">"Incident Closed", event_time, context))
        if event_type == class="hl-string">"Comment":
            if bool(change.get(class="hl-string">"public")):
                rows.append(make_row(ticket_id, class="hl-string">"Public Reply Sent", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Internal Note Added", event_time, context))


def append_satisfaction_rows(ticket: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    context = ticket_context(ticket, users, groups)
    for rating in satisfaction_for_ticket(ticket.get(class="hl-string">"id")):
        rated_at = rating.get(class="hl-string">"created_at") or rating.get(class="hl-string">"updated_at")
        if rated_at:
            rows.append(make_row(ticket.get(class="hl-string">"id"), class="hl-string">"User Satisfaction Rated", rated_at, context))


def append_sla_breach_rows(ticket: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    context = ticket_context(ticket, users, groups)
    sla_breach_time = ticket.get(class="hl-string">"sla_breach_at")
    if sla_breach_time:
        context[class="hl-string">"SlaStatus"] = class="hl-string">"Breached"
        rows.append(make_row(ticket.get(class="hl-string">"id"), class="hl-string">"SLA Target Breached", sla_breach_time, context))


def extract() -> List[Dict[str, str]]:
    rows: List[Dict[str, str]] = []
    users: Dict[str, str] = {}
    groups: Dict[str, str] = {}
    seen = set()
    for ticket in incremental_tickets(START_DATE):
        for audit in ticket_audits(ticket.get(class="hl-string">"id")):
            append_audit_rows(ticket, audit, rows, users, groups)
        append_satisfaction_rows(ticket, rows, users, groups)
        append_sla_breach_rows(ticket, rows, users, groups)
    unique_rows: List[Dict[str, str]] = []
    for row in rows:
        key = (row[class="hl-string">"TicketId"], row[class="hl-string">"ActivityName"], row[class="hl-string">"EventTimestamp"], row[class="hl-string">"Assignee"], row[class="hl-string">"AssignedGroup"])
        if key not in seen:
            seen.add(key)
            unique_rows.append(row)
    unique_rows.sort(key=lambda item: (item[class="hl-string">"TicketId"], item[class="hl-string">"EventTimestamp"], item[class="hl-string">"ActivityName"]))
    return unique_rows


if __name__ == class="hl-string">"__main__":
    event_rows = extract()
    with open(OUTPUT_FILE, class="hl-string">"w", newline=class="hl-string">"", encoding=class="hl-string">"utf-8") as output:
        writer = csv.DictWriter(output, fieldnames=FIELDS)
        writer.writeheader()
        writer.writerows(event_rows)
    print(json.dumps({class="hl-string">"output_file": OUTPUT_FILE, class="hl-string">"rows": len(event_rows), class="hl-string">"last_data_update": LAST_DATA_UPDATE}))

Các bước

Chọn công cụ ETL hoặc tích hợp dữ liệu thương mại có Zendesk Support connector đã được xác minh, hỗ trợ lịch sử kiểm tra phiếu và trích xuất bình luận, đồng thời có thể ghi dữ liệu vào kho dữ liệu hoặc hệ thống tệp đích. Xác nhận connector hỗ trợ trích xuất tăng dần, phân trang, xử lý giới hạn tốc độ và giữ nguyên dấu thời gian nguồn.
Tạo kết nối Zendesk trong công cụ đã chọn. Nhập tên miền phụ Zendesk, phương thức xác thực, thông tin xác thực hoặc token và các cài đặt kết nối cần thiết trong giao diện cấu hình. Cấp quyền truy cập phiếu, lịch sử kiểm tra phiếu, bình luận, người dùng, nhóm, mức độ hài lòng và dữ liệu SLA nếu các đối tượng này có trong gói Zendesk và được connector hỗ trợ.
Cấu hình khoảng thời gian trích xuất. Với lần tải đầu tiên, dùng khoảng thời gian luân phiên từ 3 đến 6 tháng, sau đó thiết lập tải tăng dần dựa trên dấu thời gian cập nhật hoặc dấu thời gian kiểm tra mà connector hỗ trợ. Lưu mốc trích xuất thành công gần nhất bên ngoài nhật ký sự kiện để các lần chạy sau không tạo bản ghi trùng hoặc bỏ sót sự kiện.
Trích xuất dữ liệu cấp phiếu cần thiết để bổ sung ngữ cảnh, gồm mã phiếu, trạng thái hiện tại hoặc trạng thái theo sự kiện, người phụ trách, nhóm, mức ưu tiên, kênh báo cáo, trạng thái SLA và dấu thời gian cập nhật liên quan. Trích xuất bản ghi kiểm tra phiếu vì thay đổi về phân công, mức ưu tiên, trạng thái và các trường khác phải được thể hiện thành hàng sự kiện cụ thể.
Trích xuất bình luận phiếu và phân biệt bình luận công khai với ghi chú nội bộ bằng chỉ báo công khai hoặc hiển thị của connector. Lấy dấu thời gian bình luận, mã phiếu, mã người viết và thời gian kết thúc hoặc hoàn tất nếu có. Tạo hàng Public Reply Sent cho bình luận công khai và Internal Note Added cho ghi chú riêng tư.
Trích xuất bản ghi đánh giá mức độ hài lòng và vi phạm SLA nếu connector cung cấp. Nếu connector không cung cấp trực tiếp sự kiện vi phạm SLA, hãy cấu hình công cụ ETL tính vi phạm từ mục tiêu SLA, chính sách, giờ làm việc và dấu thời gian sự kiện phiếu hiện có. Không tạo hàng vi phạm nếu dữ liệu nguồn hoặc phép tính đã cấu hình không xác nhận mục tiêu bị vi phạm.
Chuyển các bản ghi nguồn đã trích xuất thành nhật ký sự kiện chuẩn hóa. Tạo một hàng cho mỗi lần hoạt động diễn ra. Ánh xạ việc tạo phiếu thành Incident Created, thay đổi nhóm được phân công thành Ticket Assigned to Group hoặc Ticket Reassigned, thay đổi nhân viên được phân công thành Ticket Assigned to Agent hoặc Ticket Reassigned, thay đổi mức ưu tiên thành Priority Set, chuyển trạng thái thành hoạt động trạng thái tương ứng, bình luận thành Public Reply Sent hoặc Internal Note Added, trạng thái đã giải quyết thành Incident Resolved, bản ghi đánh giá thành User Satisfaction Rated và trạng thái đã đóng thành Incident Closed.
Áp dụng quy tắc phân loại sự kiện theo thứ tự xác định. Dùng giá trị cũ và mới trong lịch sử kiểm tra nếu có. Phân loại lần đầu gán nhóm là Ticket Assigned to Group, lần đầu gán nhân viên là Ticket Assigned to Agent, các lần thay đổi người phụ trách sau đó là Ticket Reassigned. Tạo một hàng cho mỗi thay đổi đủ điều kiện, không chỉ cho trạng thái phiếu mới nhất.
Điền các cột bắt buộc TicketId, ActivityName, EventTimestamp, SourceSystem và LastDataUpdate. Điền các cột khuyến nghị TicketStatus, Assignee, AssignedGroup, TicketPriority, Channel, SlaStatus và EventEndTime từ ngữ cảnh sự kiện hoặc bản ghi nguồn hợp lệ gần nhất. Giữ dấu thời gian nguồn theo cùng một múi giờ, ưu tiên UTC, và giữ nguyên độ chính xác mà connector hỗ trợ.
Kiểm tra dữ liệu đầu ra sau chuyển đổi: đảm bảo mỗi TicketId có hàng Incident Created, dấu thời gian sự kiện nằm trong khoảng trích xuất nếu phù hợp, có đủ 13 tên hoạt động bắt buộc khi dữ liệu nguồn có các hoạt động đó, và xử lý khóa sự kiện trùng theo mã kiểm tra nguồn hoặc khóa tổng hợp đã được ghi rõ.
Ghi nhật ký sự kiện vào bảng kho dữ liệu hoặc tệp đích theo định dạng bảng tương thích với ProcessMind, chẳng hạn CSV hoặc định dạng connector kho dữ liệu được hỗ trợ. Dùng một hàng tiêu đề, tên cột ổn định, mã hóa UTF-8, dấu thời gian ISO 8601 và không để JSON lồng nhau trong các cột sự kiện cuối cùng. Tải hoặc kết nối nhật ký sự kiện với ProcessMind, không dựa vào việc suy ra hoạt động vì ProcessMind đọc nguyên trạng các hàng đã trích xuất.

Cấu hình

Connector và giấy phép: Dùng công cụ ETL hoặc tích hợp dữ liệu thương mại có Zendesk Support connector, hỗ trợ truy xuất phiếu, lịch sử kiểm tra phiếu, bình luận, người dùng, nhóm, mức độ hài lòng và thông tin SLA theo gói Zendesk và phiên bản connector.
Xác thực và phân quyền: Cấu hình tên miền phụ Zendesk và phương thức xác thực được phê duyệt. Chỉ cấp quyền cần thiết để trích xuất phiếu, lịch sử kiểm tra, bình luận, người dùng, nhóm, mức độ hài lòng và SLA. Xác nhận tài khoản tích hợp có thể đọc bản ghi lịch sử.
Khoảng ngày: Bắt đầu với 3 đến 6 tháng để kiểm tra và tải dữ liệu ban đầu. Chỉ mở rộng khoảng thời gian sau khi đã xác minh số hàng, phân trang và cách xử lý giới hạn tốc độ. Dùng mốc thời gian tăng dần cho các lần chạy theo lịch.
Bộ lọc bắt buộc: Chỉ áp dụng bộ lọc theo công ty đã được xác nhận trong cấu hình nguồn, chẳng hạn tên miền phụ Zendesk, thương hiệu, tổ chức, nhóm hoặc phạm vi phiếu được chọn. Không lọc theo Company Code hoặc Document Type trừ khi các trường này có trong mô hình dữ liệu Zendesk đã cấu hình.
Lịch sử kiểm tra: Bật trích xuất sự kiện kiểm tra phiếu và giữ lại mã kiểm tra nguồn nếu có để tránh tạo sự kiện trùng trong các lần tải tăng dần.
Bình luận: Trích xuất cả bình luận công khai và riêng tư. Dùng chỉ báo hiển thị của nguồn để phân loại Public Reply Sent và Internal Note Added. Không suy đoán mức độ hiển thị từ nội dung bình luận.
Phân loại phân công: So sánh giá trị nhóm hoặc người phụ trách cũ và mới. Phân loại riêng lần phân công đầu tiên đủ điều kiện, sau đó tạo Ticket Reassigned cho các lần thay đổi người phụ trách tiếp theo.
Phân loại trạng thái: Chỉ tạo hàng cho các lần chuyển trạng thái cụ thể. Ánh xạ các giá trị new, open, pending, solved và closed theo mô hình trạng thái Zendesk đã cấu hình. Nếu dùng trạng thái tùy chỉnh, hãy ghi rõ cách ánh xạ trước khi tải dữ liệu.
Xử lý SLA: Ưu tiên dùng sự kiện vi phạm SLA từ nguồn. Nếu không có, hãy cấu hình phép tính được ghi rõ dựa trên mục tiêu SLA, chính sách, giờ làm việc và dấu thời gian sự kiện hiện có. Ghi cơ sở tính toán trong metadata ETL, không tự tạo trường nguồn.
Xử lý dấu thời gian: Chuẩn hóa EventTimestamp và EventEndTime về UTC hoặc múi giờ khác đã được ghi rõ. Giữ dấu thời gian nguồn, không thay thời điểm sự kiện bằng thời điểm trích xuất.
LastDataUpdate: Đặt LastDataUpdate thành thời điểm làm mới ETL thành công và dùng cùng một giá trị cho mọi hàng trong lần tải đó.
Hiệu suất: Dùng phân trang, trích xuất tăng dần, chia vùng theo thời điểm cập nhật phiếu hoặc dấu thời gian kiểm tra, giới hạn số tác vụ chạy song song, xử lý thử lại và chờ tăng dần khi chạm giới hạn tốc độ. Tránh trích xuất lại toàn bộ lịch sử phiếu trong mỗi lần chạy theo lịch.
Lược đồ đích: Cấu hình bảng sự kiện phẳng hoặc tệp có các cột bắt buộc TicketId, ActivityName, EventTimestamp, SourceSystem và LastDataUpdate, cùng các thuộc tính khuyến nghị nếu có.
Cách ProcessMind xử lý dữ liệu: Không dựa vào ProcessMind để suy ra thay đổi trạng thái, phân công, trả lời, ghi chú, vi phạm SLA hoặc các mốc vòng đời. Mỗi hoạt động phải có sẵn dưới dạng một hàng sự kiện trước khi tải lên.

Truy vấn mẫu config

-- Configure this transformation in the selected ETL tool using its Zendesk connector.
-- Replace bracketed connection, credential, date, and company-specific values in the tool configuration.
-- The connector source objects and field mappings must be selected from the tool's verified Zendesk schema.

WITH
source_tickets AS (
    SELECT
        ticket_id,
        created_at,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        updated_at
    FROM [Your Zendesk tickets source]
    WHERE updated_at >= [Start date parameter]
      AND updated_at < [End date parameter]
),
source_audits AS (
    SELECT
        ticket_id,
        audit_id,
        event_timestamp,
        event_type,
        previous_value,
        new_value,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk ticket audits source]
    WHERE event_timestamp >= [Start date parameter]
      AND event_timestamp < [End date parameter]
),
source_comments AS (
    SELECT
        ticket_id,
        comment_id,
        event_timestamp,
        is_public,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk ticket comments source]
    WHERE event_timestamp >= [Start date parameter]
      AND event_timestamp < [End date parameter]
),
source_sla_breaches AS (
    SELECT
        ticket_id,
        breach_timestamp,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk SLA breach source]
    WHERE breach_timestamp >= [Start date parameter]
      AND breach_timestamp < [End date parameter]
),
source_satisfaction AS (
    SELECT
        ticket_id,
        rating_timestamp,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk satisfaction rating source]
    WHERE rating_timestamp >= [Start date parameter]
      AND rating_timestamp < [End date parameter]
),
classified_audits AS (
    SELECT
        a.*,
        ROW_NUMBER() OVER (
            PARTITION BY a.ticket_id, a.event_type
            ORDER BY a.event_timestamp, a.audit_id
        ) AS event_sequence
    FROM source_audits a
),
event_log AS (
    SELECT
        CAST(t.ticket_id AS VARCHAR(255)) AS TicketId,
        'Incident Created' AS ActivityName,
        t.created_at AS EventTimestamp,
        'Zendesk Support' AS SourceSystem,
        [ETL refresh timestamp] AS LastDataUpdate,
        t.status AS TicketStatus,
        t.assignee AS Assignee,
        t.assigned_group AS AssignedGroup,
        t.priority AS TicketPriority,
        t.channel AS Channel,
        t.sla_status AS SlaStatus,
        CAST(NULL AS TIMESTAMP) AS EventEndTime
    FROM source_tickets t

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Assigned to Group',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'group_assignment'
      AND a.event_sequence = 1
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Assigned to Agent',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'assignee_assignment'
      AND a.event_sequence = 1
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Priority Set',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.new_value,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'priority_change'
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Status Changed to Open',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.previous_value = 'new'
      AND a.new_value = 'open'

    UNION ALL

    SELECT
        CAST(c.ticket_id AS VARCHAR(255)),
        'Public Reply Sent',
        c.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        c.status,
        c.assignee,
        c.assigned_group,
        c.priority,
        c.channel,
        c.sla_status,
        c.event_end_time
    FROM source_comments c
    WHERE c.is_public = TRUE

    UNION ALL

    SELECT
        CAST(c.ticket_id AS VARCHAR(255)),
        'Internal Note Added',
        c.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        c.status,
        c.assignee,
        c.assigned_group,
        c.priority,
        c.channel,
        c.sla_status,
        c.event_end_time
    FROM source_comments c
    WHERE c.is_public = FALSE

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Reassigned',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type IN ('group_assignment', 'assignee_assignment')
      AND a.event_sequence > 1
      AND COALESCE(a.previous_value, '') <> COALESCE(a.new_value, '')

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Status Changed to Pending',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'pending'

    UNION ALL

    SELECT
        CAST(s.ticket_id AS VARCHAR(255)),
        'SLA Target Breached',
        s.breach_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        s.status,
        s.assignee,
        s.assigned_group,
        s.priority,
        s.channel,
        s.sla_status,
        s.event_end_time
    FROM source_sla_breaches s
    WHERE s.breach_timestamp IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Incident Resolved',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'solved'

    UNION ALL

    SELECT
        CAST(s.ticket_id AS VARCHAR(255)),
        'User Satisfaction Rated',
        s.rating_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        s.status,
        s.assignee,
        s.assigned_group,
        s.priority,
        s.channel,
        s.sla_status,
        s.event_end_time
    FROM source_satisfaction s
    WHERE s.rating_timestamp IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Incident Closed',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'closed'
)
SELECT
    TicketId,
    ActivityName,
    EventTimestamp,
    SourceSystem,
    LastDataUpdate,
    TicketStatus,
    Assignee,
    AssignedGroup,
    TicketPriority,
    Channel,
    SlaStatus,
    EventEndTime
FROM event_log
WHERE TicketId IS NOT NULL
  AND ActivityName IS NOT NULL
  AND EventTimestamp IS NOT NULL
ORDER BY TicketId, EventTimestamp, ActivityName;

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

Dùng mẫu này để chuẩn bị dữ liệu nhanh hơn và tìm hiểu sâu hơn về hiệu quả quản lý sự cố. Bắt đầu cải tiến quy trình ngay hôm nay.

Quay lại hướng dẫn cải tiến

Tải mẫu xuống

Tối ưu quản lý sự cố, xử lý nhanh hơn ngay hôm nay

Giảm MTTR 35%, loại bỏ sự cố tái diễn và nâng cao mức độ hài lòng.

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

Không cần thẻ tín dụng, bắt đầu cải tiến chỉ trong vài phút

Mẫu dữ liệu quản lý sự cố

Mẫu dữ liệu quản lý sự cố

Thuộc tính quản lý sự cố

Hoạt động quản lý sự cố

Hướng dẫn trích xuất

Xuất báo cáo Zendesk Explore sang tệp CSV

Các bước

Cấu hình

Truy vấn mẫu config

Dùng Python Script với Zendesk Support REST API

Các bước

Cấu hình

Truy vấn mẫu python

Zendesk Incremental Export API để đồng bộ dữ liệu hàng loạt

Các bước

Cấu hình

Truy vấn mẫu python

Dùng công cụ ETL bên thứ ba có Zendesk API Connector

Các bước

Cấu hình

Truy vấn mẫu config

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

Tối ưu quản lý sự cố, xử lý nhanh hơn ngay hôm nay