Mẫu dữ liệu dịch vụ khách hàng

Zendesk Support
Mẫu dữ liệu dịch vụ khách hàng

Mẫu dữ liệu dịch vụ khách hàng

Mẫu này giúp bạn thu thập dữ liệu phù hợp để phân tích quy trình dịch vụ khách hàng. Mẫu nêu các thuộc tính dữ liệu cần thu thập, những hoạt động chính cần theo dõi và hướng dẫn thực tế để trích xuất thông tin. Dựa vào hướng dẫn này, bạn có thể tạo nhật ký sự kiện để tìm ra thông tin hữu ích và cải thiện hoạt động dịch vụ.
  • Các thuộc tính nên thu thập
  • Các hoạt động chính cần theo dõi trong quy trình dịch vụ khách hàng
  • Hướng dẫn trích xuất dữ liệu từ Zendesk Support
Chưa quen với nhật ký sự kiện? Tìm hiểu cách tạo nhật ký sự kiện cho process mining.

Thuộc tính dịch vụ khách hàng

Đây là các trường dữ liệu nên đưa vào nhật ký sự kiện để phân tích quy trình dịch vụ khách hàng.
5 Bắt buộc 6 Nên có 7 Không bắt buộc
Tên Mô tả
Thời gian bắt đầu
StartTime
Dấu thời gian cho biết một hoạt động hoặc sự kiện bắt đầu khi nào.
Mô tả

Thời gian bắt đầu, hay dấu thời gian sự kiện, ghi lại chính xác ngày giờ một hoạt động diễn ra. Ví dụ: thời điểm khách hàng thêm bình luận, thời điểm giao phiếu cho nhân viên hoặc thời điểm trạng thái phiếu chuyển thành 'Resolved'.

Dấu thời gian này là nền tảng của process mining vì xác định thứ tự thời gian của các sự kiện. Dữ liệu được dùng để tính khoảng thời gian giữa các hoạt động, đo thời gian xử lý, phân tích hiệu suất so với SLA và hiểu diễn biến theo thời gian của quy trình dịch vụ.

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

Dấu thời gian này rất cần thiết để sắp xếp sự kiện, tính khoảng thời gian và phân tích tiến trình xử lý yêu cầu dịch vụ.

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

Zendesk Ticket Audits API, trường created_at của mỗi sự kiện trong nhật ký kiểm tra.

Ví dụ
2023-04-15T10:00:00Z2023-04-15T10:05:14Z2023-04-16T14:30:00Z
Yêu cầu dịch vụ
ServiceRequest
Mã định danh duy nhất của mỗi yêu cầu dịch vụ khách hàng, còn gọi là phiếu hoặc trường hợp.
Mô tả

Service Request là mã định danh chính của trường hợp, liên kết mọi hoạt động liên quan đến một yêu cầu hoặc vấn đề của khách hàng, từ lúc tạo đến khi giải quyết xong. Mỗi lần trao đổi, cập nhật hoặc xử lý nội bộ đều gắn với mã duy nhất này.

Trong process mining, nhóm các sự kiện theo Service Request giúp bạn xem toàn bộ hành trình dịch vụ khách hàng từ đầu đến cuối. Đây là cơ sở để tính các chỉ số chính như tổng thời gian giải quyết, xác định sai lệch quy trình và hiểu vòng đời của từng vấn đề khách hàng.

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

Đây là Case ID thiết yếu, liên kết mọi bước trong quy trình để tái dựng và phân tích hành trình dịch vụ của từng khách hàng.

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

Zendesk Tickets API, trường id.

Ví dụ
102451287415332
Hệ thống nguồn
SourceSystem
Hệ thống lưu trữ dữ liệu gốc mà dữ liệu được trích xuất từ đó.
Mô tả

Thuộc tính này cho biết hệ thống nguồn của dữ liệu yêu cầu dịch vụ, trong trường hợp này là Zendesk Support. Thuộc tính giúp quản trị và truy xuất nguồn gốc dữ liệu, nhất là khi kết hợp dữ liệu từ nhiều hệ thống.

Trong quá trình phân tích, thuộc tính này đảm bảo dữ liệu được gắn đúng với nguồn, giúp duy trì tính toàn vẹn và hiểu rõ bối cảnh quy trình, đặc biệt trong môi trường có nhiều hệ thống.

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

Cho biết nguồn gốc dữ liệu, rất quan trọng cho việc quản trị dữ liệu và phân biệt dữ liệu quy trình trong môi trường tích hợp.

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

Đây là giá trị cố định được thêm trong quá trình trích xuất dữ liệu để ghi nhãn nguồn 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 của lần làm mới hoặc trích xuất dữ liệu gần nhất từ hệ thống nguồn.
Mô tả

Thuộc tính này cho biết lần gần nhất bộ dữ liệu được cập nhật từ Zendesk Support, giúp bạn biết dữ liệu đang phân tích mới đến mức nào.

Chuyên viên phân tích và người dùng nghiệp vụ cần biết thời điểm cập nhật gần nhất để xác định họ có đang xem thông tin quy trình mới nhất hay không. Thuộc tính này giúp đặt kỳ vọng phù hợp về độ mới của dữ liệu và rất cần thiết cho việc báo cáo, theo dõi.

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

Cho biết dữ liệu mới đến mức nào, giúp người dùng hiểu thông tin phân tích quy trình được cập nhật gần đây ra sao.

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

Đây là trường siêu dữ liệu được tạo và lưu trong quá trình trích xuất dữ liệu, ghi lại dấu thời gian của tác vụ trích xuất.

Ví dụ
2023-10-27T02:00:00Z
Tên hoạt động
ActivityName
Tên sự kiện hoặc tác vụ cụ thể diễn ra trong vòng đời yêu cầu dịch vụ.
Mô tả

Tên hoạt động mô tả một bước hoặc mốc trong quy trình dịch vụ khách hàng, chẳng hạn 'Service Request Created', 'Request Assigned To Agent' hoặc 'Service Request Resolved'. Mỗi sự kiện có dấu thời gian và tạo thành chuỗi hành động của từng yêu cầu dịch vụ.

Thuộc tính này rất quan trọng để trực quan hóa luồng quy trình, tìm các biến thể quy trình và phân tích tần suất cũng như thứ tự sự kiện. Nhờ đó, chuyên viên phân tích có thể biết những hành động nào đang diễn ra, xác định các luồng phổ biến, điểm nghẽn và sai lệch so với quy trình chuẩn.

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 cũng như các biến thể.

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

Lấy từ nhật ký kiểm tra phiếu hoặc luồng sự kiện của Zendesk, nơi ghi lại các thay đổi và hành động.

Ví dụ
Tạo yêu cầu dịch vụGiao yêu cầu cho nhân viênNhân viên gửi phản hồi công khai đầu tiênGiải quyết yêu cầu dịch vụ
Có vi phạm SLA
IsSlaBreached
Giá trị đúng/sai cho biết thời gian xử lý yêu cầu có vượt quá thời hạn SLA hay không.
Mô tả

Thuộc tính được tính toán này có giá trị đúng hoặc sai, cho biết yêu cầu hỗ trợ có đáp ứng thời hạn xử lý theo Thỏa thuận mức dịch vụ hay không. Giá trị được xác định bằng cách so sánh thời gian xử lý thực tế với thời hạn SLA mục tiêu.

Cờ này giúp đơn giản hóa việc phân tích tuân thủ SLA. Đây là dữ liệu cốt lõi cho bảng điều khiển «Hiệu quả tuân thủ SLA» và KPI «Tỷ lệ tuân thủ SLA», giúp bạn nhanh chóng tổng hợp và trực quan hóa số yêu cầu đạt hoặc không đạt mục tiêu dịch vụ.

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

Cho biết rõ từng trường hợp có đạt SLA hay không, giúp việc theo dõi và báo cáo tuân thủ trở nên đơn giản hơn.

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

Được tính trong quá trình chuyển đổi dữ liệu bằng cách so sánh tổng thời gian xử lý với SlaTargetResolutionTime.

Ví dụ
truefalse
Kênh liên lạc
CommunicationChannel
Kênh khách hàng dùng để gửi yêu cầu hỗ trợ hoặc trao đổi thông tin.
Mô tả

Thuộc tính này cho biết khách hàng đã liên hệ qua phương thức nào, chẳng hạn như email, biểu mẫu web, chat hoặc điện thoại. Qua đó, bạn có thể biết khách hàng đang tương tác với bộ phận hỗ trợ bằng cách nào.

Nắm được mức độ sử dụng từng kênh giúp bạn lên kế hoạch phân bổ nguồn lực và cải thiện trải nghiệm khách hàng. Bảng điều khiển «Tổng quan mức độ sử dụng kênh liên lạc» phân tích dữ liệu để cho biết kênh nào được dùng nhiều nhất, cũng như liệu một số kênh có liên quan đến thời gian xử lý lâu hơn hoặc các luồng quy trình khác hay không. Từ đó, bạn có thể quyết định nên đầu tư cải thiện dịch vụ hoặc tự động hóa ở đâu.

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

Cho biết cách khách hàng và nhân viên hỗ trợ tương tác, giúp bạn phân tích hiệu quả của từng kênh và ảnh hưởng của chúng đến quy trình cũng như trải nghiệm khách hàng.

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

Zendesk Tickets API, trường via.channel.

Ví dụ
webemailapichat
Loại yêu cầu dịch vụ
ServiceRequestType
Phân loại yêu cầu dịch vụ, chẳng hạn “Câu hỏi”, “Sự cố”, “Vấn đề” hoặc “Nhiệm vụ”.
Mô tả

Thuộc tính này phân loại yêu cầu dịch vụ theo tính chất. Thông thường, loại yêu cầu được đặt khi tạo hoặc phân loại ban đầu, giúp xác định quy trình làm việc và mức độ ưu tiên phù hợp.

Trong phân tích, việc phân nhóm theo loại yêu cầu dịch vụ là rất quan trọng. Bạn có thể so sánh thời gian giải quyết, tỷ lệ chuyển cấp và luồng quy trình giữa các loại vấn đề khác nhau, như trong dashboard 'Service Request Resolution Time Analysis' và 'Internal Escalation Rate & Causes'. Qua đó, bạn có thể xác định loại yêu cầu nào khó xử lý hoặc kém hiệu quả hơn.

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

Phân loại yêu cầu để so sánh hiệu suất và phân tích các loại vấn đề khác nhau, làm cơ sở cho cải tiến quy trình đúng trọng tâm.

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

Zendesk Tickets API, trường type.

Ví dụ
Câu hỏiSự cốVấn đềNhiệm vụ
Mức độ ưu tiên
Priority
Mức độ ưu tiên được gán cho yêu cầu dịch vụ, chẳng hạn 'Low', 'Normal', 'High' hoặc 'Urgent'.
Mô tả

Mức độ ưu tiên cho biết yêu cầu dịch vụ cần được xử lý gấp đến đâu, đồng thời thường ảnh hưởng đến vị trí trong hàng đợi và thời hạn giải quyết. Nhờ đó, nhân viên có thể tập trung xử lý vấn đề cấp bách nhất trước.

Thuộc tính này rất cần thiết để phân tích hiệu suất và SLA. Dashboard 'Service Request Resolution Time Analysis' dùng mức độ ưu tiên để phân nhóm dữ liệu, cho thấy yêu cầu ưu tiên cao có được xử lý nhanh hơn yêu cầu ưu tiên thấp hay không và tài nguyên có được phân bổ phù hợp với nhu cầu kinh doanh hay không.

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

Cho biết mức độ khẩn cấp của yêu cầu. Đây là thông tin quan trọng để phân tích việc tuân thủ SLA và bảo đảm các vấn đề nghiêm trọng đượ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ân viên được giao xử lý
AssignedAgent
Tên hoặc mã của nhân viên dịch vụ khách hàng được giao xử lý yêu cầu dịch vụ.
Mô tả

Thuộc tính này xác định nhân viên chịu trách nhiệm cho một hoạt động hoặc yêu cầu dịch vụ tại một thời điểm cụ thể. Người phụ trách có thể thay đổi trong vòng đời yêu cầu nếu yêu cầu được giao lại.

Phân tích theo nhân viên được giao xử lý giúp hiểu khối lượng công việc, hiệu suất và hiệu quả của từng người. Thuộc tính này hỗ trợ dashboard 'Agent Workload and Efficiency', cho phép so sánh thời gian xử lý và số lượng trường hợp giữa các nhân viên, từ đó xác định nhu cầu hướng dẫn và cân bằng khối lượng công việc.

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

Theo dõi nhân viên thực hiện hành động, giúp phân tích hiệu suất cá nhân, phân bổ khối lượng công việc và sử dụng tài nguyên.

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

Zendesk Tickets API, trường assignee_id. Có thể lấy thông tin người dùng từ Users API.

Ví dụ
John SmithJane DoeSupportBot
Thời hạn xử lý theo SLA
SlaTargetResolutionTime
Khoảng thời gian mục tiêu để xử lý xong yêu cầu hỗ trợ theo chính sách SLA.
Mô tả

Thuộc tính này xác định thời hạn xử lý phiếu hỗ trợ theo Thỏa thuận mức dịch vụ (SLA). Thời hạn thường thay đổi tùy theo mức độ ưu tiên, loại yêu cầu hoặc gói dịch vụ của khách hàng.

Đây là thuộc tính nền tảng cho bảng điều khiển «Hiệu quả tuân thủ SLA». Thời hạn mục tiêu là mốc để so sánh với thời gian xử lý thực tế. Phân tích kết quả so với mốc này giúp bạn đánh giá chất lượng cung cấp dịch vụ và bảo đảm đáp ứng các cam kết với khách hàng.

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

Xác định cam kết dịch vụ với khách hàng, đồng thời làm mốc để đo lường việc xử lý đúng hạn và tuân thủ SLA.

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

Được xác định từ các chính sách SLA áp dụng cho phiếu hỗ trợ. Bạn có thể lấy thông tin này qua Zendesk Ticket Metrics API.

Ví dụ
144002880086400
Đã mở lại
IsReopened
Giá trị đúng/sai cho biết yêu cầu hỗ trợ có được mở lại sau khi đã đánh dấu là đã giải quyết hay không.
Mô tả

Cờ này chuyển thành đúng nếu yêu cầu hỗ trợ quay lại trạng thái đang mở sau khi đã được đánh dấu là đã giải quyết hoặc đã đóng. Điều đó cho thấy lần xử lý ban đầu chưa đáp ứng yêu cầu.

Cờ này rất quan trọng để theo dõi việc phải làm lại và các trường hợp không giải quyết được ngay lần liên hệ đầu tiên. Cờ hỗ trợ trực tiếp cho bảng điều khiển «Xu hướng yêu cầu hỗ trợ được mở lại» và KPI «Tỷ lệ yêu cầu hỗ trợ được mở lại». Nhờ đó, bạn dễ dàng đếm và phân tích các trường hợp cần xử lý thêm, vốn thường cho thấy vấn đề sâu xa hơn.

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

Phát hiện việc phải làm lại và các trường hợp xử lý chưa thành công, giúp bạn đo lường chất lượng và hiệu quả của giải pháp đã đưa ra.

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

Được tính trong quá trình chuyển đổi dữ liệu bằng cách kiểm tra xem trạng thái phiếu có chuyển từ 'resolved' hoặc 'closed' về 'open' hay không.

Ví dụ
truefalse
Danh mục sản phẩm, dịch vụ
ProductServiceCategory
Sản phẩm, dịch vụ hoặc tính năng cụ thể mà yêu cầu của khách hàng đề cập đến.
Mô tả

Thuộc tính này bổ sung ngữ cảnh chi tiết bằng cách phân loại yêu cầu theo lĩnh vực sản phẩm hoặc dịch vụ. Nhân viên hỗ trợ có thể chọn danh mục thủ công hoặc hệ thống có thể tự động xác định dựa trên nội dung yêu cầu.

Việc phân loại này rất quan trọng với các bảng điều khiển «Độ chính xác khi phân loại yêu cầu» và «Phân tích thời gian xử lý theo chu kỳ điều tra». Bạn có thể tìm hiểu sâu sản phẩm nào tạo ra nhiều yêu cầu hỗ trợ nhất, yêu cầu nào khó xử lý nhất và danh mục ban đầu có khớp với giải pháp cuối cùng hay không. Những thông tin này giúp cải thiện việc phân luồng yêu cầu và đào tạo nhân viên hỗ trợ.

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

Liên kết yêu cầu với lĩnh vực kinh doanh, sản phẩm hoặc dịch vụ cụ thể, giúp bạn tập trung phân tích vấn đề và ảnh hưởng của chúng đến quy trình.

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

Thông thường, đây là trường tùy chỉnh của phiếu hỗ trợ trong Zendesk. Tên trường cụ thể tùy thuộc vào cấu hình Zendesk của bạn.

Ví dụ
Ứng dụng di độngQuản lý gói đăng kýTích hợp APIPhần cứng
Mã kết quả xử lý
ResolutionCode
Mã hoặc danh mục cho biết lý do yêu cầu được xử lý xong hoặc đóng.
Mô tả

Mã kết quả xử lý cung cấp thông tin có cấu trúc về kết quả của một yêu cầu hỗ trợ. Các giá trị có thể gồm «Nhân viên hỗ trợ đã giải quyết», «Trùng lặp», «Không cần xử lý» hoặc «Sự cố đã biết». Thông tin này cụ thể hơn trạng thái «Đã đóng» đơn thuần.

Thuộc tính này đặc biệt hữu ích khi phân tích nguyên nhân gốc rễ. Trong bảng điều khiển «Xu hướng yêu cầu hỗ trợ được mở lại», bạn có thể phân tích tỷ lệ mở lại theo mã kết quả xử lý để phát hiện những cách giải quyết chưa hiệu quả, khiến khách hàng phải liên hệ lại với bộ phận hỗ trợ.

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

Cho biết kết quả của yêu cầu hỗ trợ, giúp bạn phân tích nguyên nhân gốc rễ và tìm hiểu vì sao yêu cầu được mở lại.

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

Thông thường, đây là trường tùy chỉnh của phiếu hỗ trợ trong Zendesk. Tên trường cụ thể tùy thuộc vào cấu hình Zendesk của bạn.

Ví dụ
Giải quyết ngay lần liên hệ đầu tiênChuyển lên cấp hỗ trợ 2Chờ khách hàng phản hồiLỗi sản phẩm
Mức độ hài lòng
SatisfactionRating
Điểm hài lòng khách hàng cung cấp sau khi yêu cầu hỗ trợ được xử lý xong.
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 gồm «Tốt», «Không tốt» hoặc điểm số.

Đây là thước đo trực tiếp cảm nhận của khách hàng và là chỉ số kết quả quan trọng. Dữ liệu này được dùng để tính KPI «Điểm cảm nhận của khách hàng». Khi phân tích mức độ hài lòng cùng dữ liệu quy trình, chẳng hạn như thời gian xử lý hoặc số lần nhân viên hỗ trợ tương tác, bạn có thể tìm ra cách làm nào mang lại kết quả tốt hơn cho khách hàng.

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

Đo trực tiếp phản hồi của khách hàng về dịch vụ, giúp liên kết hiệu suất quy trình với kết quả dành cho khách hàng.

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

Zendesk Tickets API, trường satisfaction_rating.score.

Ví dụ
tốtkhông tốtđã gửi lời mời đánh giá
Nhóm nhân viên hỗ trợ
AgentGroup
Nhóm hoặc đội hỗ trợ được giao xử lý yêu cầu.
Mô tả

Thuộc tính này cho biết đội ngũ nhân viên chịu trách nhiệm xử lý yêu cầu hỗ trợ. Yêu cầu thường được chuyển đến các nhóm cụ thể dựa trên kỹ năng, lĩnh vực sản phẩm hoặc ngôn ngữ.

Phân tích theo nhóm nhân viên hỗ trợ giúp bạn hiểu hiệu suất của từng nhóm, cách phân bổ khối lượng công việc và tình hình chuyển cấp giữa các nhóm. Cách nhìn này bao quát hơn việc phân tích từng nhân viên, đồng thời giúp phát hiện vấn đề mang tính hệ thống trong một bộ phận hoặc chức năng cụ thể.

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

Theo dõi nhóm chịu trách nhiệm xử lý, giúp bạn phân tích hiệu suất nhóm, việc bàn giao giữa các nhóm và cách phân bổ nguồn lực giữa các cấp hoặc chuyên môn hỗ trợ.

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

Zendesk Tickets API, trường group_id. Bạn có thể lấy thông tin nhóm qua Groups API.

Ví dụ
Hỗ trợ cấp 1Hỗ trợ kỹ thuậtThanh toán
Số lần yêu cầu cung cấp thông tin
InformationRequestCount
Tổng số lần yêu cầu khách hàng cung cấp thông tin cho một yêu cầu hỗ trợ.
Mô tả

Chỉ số được tính toán này đếm số lần hoạt động 'Information Requested From Customer' xảy ra với mỗi yêu cầu hỗ trợ. Số lần cao cho thấy nhân viên hỗ trợ có thể chưa thu thập đủ thông tin cần thiết ngay từ đầu.

Thuộc tính này được dùng trong bảng điều khiển «Phân tích các lần yêu cầu cung cấp thông tin lặp lại». Theo dõi số lần yêu cầu giúp bạn phát hiện điểm kém hiệu quả trong quy trình và xác định nội dung cần đào tạo cho nhân viên. Giảm số lần phải hỏi thêm thông tin có thể rút ngắn đáng kể thời gian xử lý và cải thiện trải nghiệm khách hàng.

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

Đo số lần trao đổi qua lại với khách hàng, giúp phát hiện những điểm kém hiệu quả kéo dài thời gian xử lý và làm giảm trải nghiệm khách hàng.

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

Được tính bằng cách đếm số sự kiện có ActivityName là 'Information Requested From Customer' cho mỗi Service Request.

Ví dụ
013
Thời gian kết thúc
EndTime
Dấu thời gian cho biết một hoạt động hoặc sự kiện hoàn tất khi nào.
Mô tả

Thời gian kết thúc là thời điểm một hoạt động hoàn tất. Trong nhiều cấu trúc nhật ký sự kiện, thời gian bắt đầu của hoạt động tiếp theo có thể được dùng làm thời gian kết thúc của hoạt động hiện tại. Với hoạt động dựa trên trạng thái như 'Agent Investigates Issue', thời điểm này cho biết trạng thái đó kết thúc khi nào.

Thuộc tính này rất cần thiết để tính chính xác thời lượng hoạt động, một phần cốt lõi trong phân tích hiệu suất. Thuộc tính giúp xác định bước nào tốn nhiều thời gian nhất, đồng thời làm cơ sở cho việc phân tích điểm nghẽn chi tiết và tính hiệu quả sử dụng tài nguyên.

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

Cho phép tính thời lượng hoạt động, yếu tố quan trọng để xác định điểm nghẽn và đo hiệu suất.

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

Thường được suy ra từ StartTime của sự kiện tiếp theo trong chuỗi của cùng một Service Request.

Ví dụ
2023-04-15T10:05:14Z2023-04-15T11:20:30Z2023-04-16T15:00:00Z
Bắt buộc Nên có Không bắt buộc

Hoạt động dịch vụ khách hàng

Đây là các bước quy trình và cột mốc chính cần ghi lại trong nhật ký sự kiện để khám phá chính xác quy trình dịch vụ khách hàng.
6 Nên có 8 Không bắt buộc
Hoạt động Mô tả
Đóng yêu cầu dịch vụ
Đây là hoạt động cuối cùng, đánh dấu yêu cầu dịch vụ được đóng vĩnh viễn. 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 phiếu chuyển sang trạng thái 'solved', nếu khách hàng không gửi thêm phản hồi.
Vì sao điều này quan trọng

Đây là sự kiện kết thúc chính thức, khép lại vòng đời của phiếu. Khoảng thời gian từ 'solved' đến 'closed' là lúc khách hàng vẫn có thể mở lại phiếu; sự kiện 'closed' xác nhận việc giải quyết đã được chấp nhận.

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

Đây là sự kiện đổi trạng thái được ghi nhận rõ ràng trong Zendesk Ticket Audits API khi trường 'status' được đặt thành 'closed'.

Thu thập

Tìm các sự kiện 'Change' trong Ticket Audits khi trạng thái phiếu được đặt thành 'closed'.

Loại sự kiện explicit
Giải quyết yêu cầu dịch vụ
Nhân viên chuyển yêu cầu dịch vụ sang trạng thái 'solved' sau khi cung cấp giải pháp cho khách hàng. Đây là trạng thái tạm thời, vì khách hàng vẫn có thể trả lời và mở lại phiếu trước khi phiếu được đóng hẳn.
Vì sao điều này quan trọng

Đây là mốc chính để đo thời gian giải quyết và hiệu quả làm việc của nhân viên. Mốc này cho biết nhân viên cho rằng công việc đã hoàn tất, đồng thời giúp phân tích phần việc phải làm lại nếu phiếu được mở lại.

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

Đây là sự kiện đổi trạng thái được ghi nhận rõ ràng trong Zendesk Ticket Audits API khi trường 'status' được đặt thành 'solved'.

Thu thập

Tìm các sự kiện 'Change' trong Ticket Audits khi trạng thái phiếu được đặt thành 'solved'.

Loại sự kiện explicit
Giao yêu cầu cho nhân viên
Sự kiện này cho biết yêu cầu dịch vụ đã được giao cho một nhân viên cụ thể xử lý. Việc giao có thể diễn ra tự động theo quy tắc định tuyến hoặc do trưởng nhóm hay nhân viên thực hiện thủ công.
Vì sao điều này quan trọng

Giao yêu cầu là mốc quan trọng để xác định trách nhiệm và quản lý khối lượng công việc. Phân tích thời gian giao và các lần giao lại giúp phát hiện điểm nghẽn trong khâu phân loại và phân phối yêu cầu.

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

Đây là sự kiện 'Change' được ghi nhận rõ ràng trong Zendesk Ticket Audits API mỗi khi trường 'assignee_id' được điền hoặc thay đổi.

Thu thập

Theo dõi các thay đổi của trường 'assignee_id' trong nhật ký Ticket Audits.

Loại sự kiện explicit
Mở lại yêu cầu dịch vụ
Hoạt động này xảy ra khi khách hàng trả lời phiếu đang ở trạng thái 'solved'. Zendesk tự động chuyển trạng thái về 'open', cho biết vấn đề chưa được giải quyết triệt để.
Vì sao điều này quan trọng

Phiếu bị mở lại là chỉ báo quan trọng cho thấy chưa giải quyết được vấn đề ngay lần liên hệ đầu tiên và chất lượng giải pháp chưa tốt. Phân tích tần suất và lý do mở lại giúp xác định nội dung cần cải thiện trong đào tạo nhân viên và quy trình giải quyết.

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

Đây là sự kiện đổi trạng thái được ghi nhận rõ ràng trong Ticket Audits API khi trạng thái chuyển từ 'solved' về 'open'.

Thu thập

Theo dõi các sự kiện 'Change' đổi trạng thái từ 'solved' sang 'open'.

Loại sự kiện explicit
Tạo yêu cầu dịch vụ
Hoạt động này đánh dấu thời điểm bắt đầu quy trình dịch vụ khách hàng, khi một phiếu mới được tạo trong Zendesk qua email, biểu mẫu web, trò chuyện hoặc kênh khác. Khi tạo phiếu, hệ thống ghi lại sự kiện này cùng mã phiếu duy nhất và dấu thời gian.
Vì sao điều này quan trọng

Đây là sự kiện bắt đầu chính, cần thiết để tính tổng thời gian xử lý trường hợp và phân tích số lượng yêu cầu tiếp nhận theo thời gian. Sự kiện này làm mốc để đo các chỉ số hiệu suất chính như thời gian phản hồi đầu tiên và tổng thời gian giải quyết.

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

Đây là sự kiện được ghi nhận rõ ràng trong Zendesk Ticket Audits API. Sự kiện tương ứng với thao tác 'Create' của phiếu và cung cấp dấu thời gian tạo ban đầu.

Thu thập

Lấy từ sự kiện tạo phiếu trong nhật ký Ticket Audits.

Loại sự kiện explicit
Yêu cầu khách hàng cung cấp thông tin
Sự kiện này xảy ra khi nhân viên cần thêm thông tin từ khách hàng để tiếp tục xử lý và chuyển trạng thái phiếu thành 'pending'. Thay đổi trạng thái này cho biết quy trình đang chờ phản hồi từ bên ngoài.
Vì sao điều này quan trọng

Hoạt động này cho thấy quy trình phụ thuộc vào khách hàng và tạm dừng đồng hồ SLA nội bộ. Nếu xảy ra thường xuyên hoặc lặp lại trên cùng một phiếu, có thể thông tin thu thập ban đầu chưa đầy đủ, khiến thời gian giải quyết kéo dài.

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

Đây là sự kiện đổi trạng thái được ghi nhận rõ ràng trong Zendesk Ticket Audits API. Sự kiện được ghi lại khi trường 'status' chuyển thành 'pending'.

Thu thập

Tìm các sự kiện 'Change' trong Ticket Audits khi trạng thái phiếu được đặt thành 'pending'.

Loại sự kiện explicit
Gửi khảo sát mức độ hài lòng
Sự kiện này đánh dấu thời điểm khảo sát mức độ hài lòng của khách hàng (CSAT) được tự động gửi. Thông thường, khảo sát được gửi một thời gian ngắn sau khi phiếu chuyển sang trạng thái 'solved'.
Vì sao điều này quan trọng

Hoạt động này bắt đầu quy trình thu thập phản hồi của khách hàng. Việc biết khảo sát được gửi khi nào và có được gửi hay không rất quan trọng để hiểu đúng điểm hài lòng và đánh giá hiệu quả của chương trình phản hồi.

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

Có thể suy ra sự kiện này từ nhật ký tự động hóa hoặc từ một thẻ cụ thể được thêm vào phiếu. Phần 'satisfaction_rating' trong Zendesk Ticket Audits API cũng ghi lại thời điểm khảo sát được gửi.

Thu thập

Tìm các thẻ như 'csat_sent' hoặc dùng dấu thời gian ghi nhận thời điểm khảo sát mức độ hài lòng được gửi.

Loại sự kiện inferred
Gửi xác nhận ban đầu
Đây là phản hồi đầu tiên được gửi tự động cho khách hàng để xác nhận đã nhận yêu cầu. Thông thường, Zendesk trigger sẽ gửi email thông báo theo mẫu ngay sau khi tạo phiếu.
Vì sao điều này quan trọng

Theo dõi hoạt động này rất quan trọng để đo tốc độ phản hồi ban đầu và quản lý kỳ vọng của khách hàng. Thời gian từ lúc tạo yêu cầu đến khi gửi xác nhận là chỉ số quan trọng về mức độ hài lòng.

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

Có thể suy ra sự kiện này từ bình luận công khai đầu tiên trên phiếu nếu người viết là người dùng tự động hoặc bình luận được đăng trong vài giây sau khi tạo phiếu. Có thể xác định bằng cách phân tích luồng Ticket Comments.

Thu thập

Tìm bình luận công khai đầu tiên do tính năng tự động hóa hoặc trigger tạo ngay sau khi tạo phiếu.

Loại sự kiện inferred
Khách hàng phản hồi
Sự kiện này xảy ra khi khách hàng trả lời phiếu, thường là phiếu đang ở trạng thái 'pending'. Zendesk tự động chuyển trạng thái phiếu từ 'pending' về 'open', báo hiệu nhân viên có thể tiếp tục xử lý.
Vì sao điều này quan trọng

Hoạt động này đánh dấu thời gian chờ kết thúc và quy trình tiếp tục. Phân tích thời gian khách hàng phản hồi có thể giúp đánh giá yêu cầu của nhân viên đã rõ ràng hay chưa.

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

Sự kiện này tương ứng với bình luận công khai mới từ người dùng cuối, khiến trạng thái trong Ticket Audits API chuyển rõ ràng từ 'pending' sang 'open'.

Thu thập

Theo dõi các sự kiện 'Change' đổi trạng thái từ 'pending' sang 'open' hoặc tìm bình luận công khai mới do người dùng cuối gửi.

Loại sự kiện explicit
Kích hoạt chuyển cấp nội bộ
Sự kiện này thể hiện việc chuyển yêu cầu dịch vụ sang một nhóm nội bộ khác hoặc cấp hỗ trợ cao hơn. Thông thường, có thể suy ra sự kiện này khi nhóm được giao xử lý phiếu thay đổi.
Vì sao điều này quan trọng

Theo dõi các lần chuyển cấp giúp xác định điểm yếu trong quy trình, thiếu hụt kiến thức ở bộ phận hỗ trợ tuyến đầu và các loại yêu cầu phức tạp. Tỷ lệ chuyển cấp cao có thể cho thấy cần đào tạo tốt hơn hoặc bổ sung tài liệu quy trình.

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

Có thể suy ra từ sự kiện 'Change' trong Zendesk Ticket Audits API khi trường 'group_id' thay đổi. Đổi nhóm cho thấy yêu cầu đã được chuyển giao giữa các nhóm.

Thu thập

Theo dõi các thay đổi của trường 'group_id' trong nhật ký Ticket Audits.

Loại sự kiện inferred
Nhận đánh giá mức độ hài lòng
Sự kiện này xảy ra khi khách hàng gửi câu trả lời cho khảo sát mức độ hài lòng, chẳng hạn đánh giá 'Good' hoặc 'Bad'. Đánh giá và bình luận đi kèm được ghi lại trong phiếu.
Vì sao điều này quan trọng

Phản hồi trực tiếp của khách hàng rất có giá trị để đo chất lượng dịch vụ và cảm nhận của khách hàng. Phân tích các đánh giá này theo luồng quy trình giúp tìm mối liên hệ giữa hoạt động hoặc nhân viên cụ thể với kết quả.

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

Được ghi nhận dưới dạng sự kiện 'Change' trong Zendesk Ticket Audits API khi trường 'satisfaction_rating' có điểm đánh giá và bình luận của khách hàng.

Thu thập

Lọc nhật ký Ticket Audit để tìm các thay đổi của trường 'satisfaction_rating'.

Loại sự kiện explicit
Nhân viên gửi phản hồi công khai đầu tiên
Hoạt động này đánh dấu lần đầu tiên nhân viên gửi bình luận công khai cho khách hàng, không tính phản hồi xác nhận tự động. Đây là chỉ báo quan trọng về thời điểm nhân viên bắt đầu trực tiếp xử lý vấn đề của khách hàng.
Vì sao điều này quan trọng

Đây là mốc quan trọng để đo SLA 'First Reply Time', một chỉ báo thiết yếu về tốc độ phản hồi dịch vụ. Mốc này phân biệt trao đổi tự động với thời điểm nhân viên bắt đầu chủ động tìm hiểu và hỗ trợ.

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

Xác định bằng cách tìm bình luận công khai đầu tiên trong luồng Ticket Comments do nhân viên thật viết, không phải người dùng hệ thống tự động.

Thu thập

Quét bình luận trên phiếu, lọc các bình luận công khai do nhân viên gửi và chọn bình luận có dấu thời gian sớm nhất.

Loại sự kiện inferred
Phân loại và ưu tiên yêu cầu
Hoạt động này diễn ra khi nhân viên hoặc tính năng tự động hóa đặt hay cập nhật các trường của phiếu như loại, danh mục và mức độ ưu tiên. Bước này được ghi lại dưới dạng sự kiện thay đổi trong lịch sử phiếu.
Vì sao điều này quan trọng

Phân loại và ưu tiên đúng cách rất quan trọng để chuyển yêu cầu đến đúng nơi và phân bổ tài nguyên hiệu quả. Phân tích hoạt động này giúp đánh giá độ chính xác của bước phân loại ban đầu và tác động của bước đó đến thời gian giải quyết.

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

Được ghi nhận trong Zendesk Ticket Audits API dưới dạng sự kiện 'Change'. Có thể xác định bằng cách tìm lần cập nhật đầu tiên các trường như 'priority', 'type' hoặc trường tùy chỉnh liên quan đến phân loại.

Thu thập

Lọc nhật ký Ticket Audit để tìm sự kiện 'Change' đầu tiên trên các trường phân loại chính sau khi tạo phiếu.

Loại sự kiện explicit
Xảy ra vi phạm SLA
Hoạt động này đánh dấu thời điểm yêu cầu dịch vụ không đáp ứng thỏa thuận mức dịch vụ đã đặ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. Sự kiện được tính dựa trên dấu thời gian hoạt động của phiếu và đối chiếu với chính sách SLA.
Vì sao điều này quan trọng

Vi phạm SLA ảnh hưởng trực tiếp đến mức độ hài lòng của khách hàng và việc tuân thủ hợp đồng. Phân tích thời điểm và nguyên nhân xảy ra vi phạm rất quan trọng để tìm ra chậm trễ mang tính hệ thống, thiếu tài nguyên hoặc mục tiêu hiệu suất thiếu thực tế.

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

Có thể lấy dữ liệu này từ Zendesk Ticket Metrics API, nơi lưu dấu thời gian vi phạm SLA ('breached_at'). Ngoài ra, bạn có thể tính bằng cách đối chiếu dấu thời gian sự kiện của phiếu với các quy tắc SLA đã đặt.

Thu thập

Dùng dấu thời gian 'breached_at' từ Ticket Metrics API hoặc tính bằng cách so sánh thời gian giải quyết với thời hạn trong chính sách SLA.

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

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

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

Bạn đã sẵn sàng bắt đầu chưa?

Bắt đầu cải tiến dịch vụ khách hàng ngay hôm nay bằng cách chuẩn bị dữ liệu theo mẫu này. Khám phá thông tin hữu ích và nâng cao hiệu quả vận hành trên Zendesk Support.

Xử lý điểm nghẽn trong dịch vụ khách hàng, nâng CSAT ngay hôm nay

Giảm liên hệ lặp lại. Đạt FCR 80% và nâng cao mức độ hài lòng của khách hàng.

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

Không cần thẻ tín dụng