Cách tạo báo cáo phiếu hỗ trợ: Từng bước chi tiết

Một báo cáo phiếu hỗ trợ phần lớn là vấn đề về mặt định nghĩa. Phiếu được tạo, phiếu đã giải quyết, thời gian phản hồi đầu tiên và thời gian giải quyết đều nghe có vẻ rất rõ ràng. Nhưng mỗi chỉ số này đều có nhiều hơn một định nghĩa chính thức ngay trong cùng một help desk.

Chỉ cần làm rõ các quy tắc tính toán là báo cáo sẽ tự khắc hoàn thành. Bỏ qua bước đó, hai người trung thực cùng xuất một tệp dữ liệu như nhau nhưng kết quả sẽ lệch nhau tới vài giờ.

Hướng dẫn này sẽ đề cập đến những nội dung cần có trong báo cáo, bốn điểm mấu chốt dễ gây nhầm lẫn trong định nghĩa, và cách xây dựng báo cáo từ tệp xuất dữ liệu phiếu hỗ trợ.

Những gì cần có trong một báo cáo phiếu hỗ trợ

Chỉ riêng số lượng thì gần như không nói lên điều gì. Cách sắp xếp mới là yếu tố giúp các con số trở nên đáng tin cậy và dễ hiểu.

Thành phần	Lý do xuất hiện
Phiếu được tạo trong kỳ	Phía nhu cầu (đầu vào)
Phiếu đã giải quyết trong kỳ	Phía cung cấp (đầu ra), dựa trên quy tắc trạng thái được quy định
Phiếu tồn đọng cuối kỳ	Tất cả những phiếu chưa được giải quyết hoặc chưa đóng
Thời gian phản hồi đầu tiên	Dựa trên khung giờ và định nghĩa được quy định
Thời gian giải quyết	Giải quyết lần đầu hoặc giải quyết hoàn toàn, được chỉ rõ cụ thể
Phiếu bị mở lại	Tín hiệu chất lượng mà các con số khác thường che giấu
Phiếu chưa được phản hồi	Nơi quy trình bị thất bại hoàn toàn
Phạm vi và cơ sở ngày tháng được quy định	Bao gồm những kênh, thương hiệu và hàng đợi nào

Hai hàng dữ liệu này có tầm quan trọng lớn hơn nhiều so với vẻ bề ngoài của chúng. Phiếu bị mở lại và phiếu chưa được phản hồi chính là điểm giúp báo cáo không chỉ dừng lại ở một bảng điểm vô hồn mà thực sự trở nên hữu ích.

Zendesk công bố các công thức cơ bản, giúp các định nghĩa có thể kiểm chứng được thay vì chỉ là ý kiến cá nhân. Tài liệu tham khảo về chỉ số và thuộc tính của họ cung cấp chi tiết cho từng loại.

Hãy bắt đầu với chỉ số đơn giản nhất. Phiếu đã giải quyết là "số lượng phiếu đã giải quyết hoặc đã đóng", vì vậy chỉ số này bao gồm hai trạng thái chứ không phải một.

"Thời gian phản hồi đầu tiên" có hai định nghĩa chính thức

Đây là điểm rẽ nhánh gây ra nhiều tranh cãi nhất, và chính nhà cung cấp cũng đã trực tiếp đưa ra cảnh báo về điều này.

Tài liệu hướng dẫn về SLA của Zendesk đã nêu rõ trong một dòng: "Đừng nhầm lẫn thời gian phản hồi SLA với chỉ số thời gian phản hồi mặc định của Zendesk."

Chỉ số mặc định rất khắt khe về người phản hồi. Zendesk tuyên bố rằng "thời gian phản hồi đầu tiên được tính toán dựa trên phản hồi của nhân viên hỗ trợ." Các hành động tự động và liên quan đến bot "không được tính khi tính toán thời gian phản hồi đầu tiên."

Chỉ số SLA thì không như vậy. Ở đó, thời gian phản hồi đầu tiên là "khoảng thời gian từ khi tạo phiếu đến khi có bình luận công khai đầu tiên từ nhân viên hỗ trợ (hoặc phản hồi tự động)." Zendesk cho biết thêm rằng "các chỉ số thời gian phản hồi sẽ được hoàn thành nếu bạn thiết lập một trigger để tự động phản hồi bằng một bình luận công khai."

Khi đặt hai định nghĩa này cạnh nhau, hệ quả hiện ra rất rõ ràng. Một hệ thống phản hồi tự động có thể giúp bạn đạt mục tiêu SLA, trong khi chỉ số thời gian phản hồi đầu tiên mặc định vẫn tiếp tục chạy.

Vì vậy, một báo cáo hiển thị tỷ lệ đạt SLA là 98% và thời gian phản hồi đầu tiên trung vị là bốn giờ không hề mâu thuẫn với nhau. Nó đang báo cáo hai thứ khác nhau, và cả hai đều chính xác.

Có hai ngoại lệ nhỏ hơn đáng lưu ý. Hãy xem xét trường hợp nhân viên hỗ trợ tự tạo phiếu và bình luận đầu tiên là công khai. Tài liệu tham khảo về chỉ số thời gian cho biết mốc thời gian thứ hai sẽ "chuyển sang bình luận công khai thứ hai của nhân viên hỗ trợ."

And các phiếu được chia sẻ sẽ không được tính. Zendesk lưu ý rằng khi một nhân viên hỗ trợ bình luận công khai từ một tài khoản khác bằng tính năng chia sẻ phiếu, "điều này không được tính vào thời gian phản hồi đầu tiên của tài khoản của bạn."

"Thời gian giải quyết" cũng có hai định nghĩa

Sự phân chia tương tự cũng xuất hiện trong các chỉ số giải quyết, và ở đây cả hai phiên bản đều được cung cấp theo mặc định.

Thời gian giải quyết lần đầu là "khoảng thời gian từ khi tạo phiếu đến lần giải quyết đầu tiên", kết thúc vào "lần đầu tiên trạng thái phiếu được chuyển thành đã giải quyết."

Thời gian giải quyết hoàn toàn là "khoảng thời gian từ khi tạo phiếu đến lần giải quyết gần đây nhất." Nó kết thúc vào "lần cuối cùng trạng thái phiếu được chuyển thành đã giải quyết."

Đối với một phiếu chỉ giải quyết một lần, hai chỉ số này là như nhau. Đối với một phiếu đã giải quyết, bị mở lại, rồi lại được giải quyết tiếp, hai chỉ số này sẽ chênh lệch nhau một khoảng thời gian bằng đúng thời gian xử lý của lượt thứ hai.

That chính là lý do tại sao các phiếu bị mở lại cần phải có mặt trong báo cáo. Zendesk định nghĩa chúng là các phiếu "được mở lại sau khi đã giải quyết," và lưu ý rằng chỉ số này "không bao gồm các phiếu được giải quyết và mở lại trong cùng một lần cập nhật."

Có một tác động gián tiếp mà mọi người thường bỏ qua. Số lượng phiếu giải quyết trung bình hàng ngày chỉ tính các phiếu "nếu chúng hiện đang ở trạng thái đã giải quyết hoặc đã đóng." Vì vậy, một phiếu được mở lại vào ngày hôm nay sẽ âm thầm biến mất khỏi số lượng phiếu đã giải quyết của tháng trước.

Do đó, một báo cáo bạn đã chạy vào tháng 6 sẽ không khớp với kết quả khi chạy lại vào tháng 8. Không có lỗi gì xảy ra cả; chỉ là trạng thái cốt lõi của phiếu đã thay đổi.

Hai chỉ số khác giúp phân biệt giữa thời gian chờ đợi và thời gian xử lý. Thời gian chờ của người yêu cầu là tổng thời gian ở các trạng thái mới, mở và tạm dừng, còn thời gian chờ của nhân viên hỗ trợ là tổng thời gian ở trạng thái chờ xử lý.

Cặp chỉ số này trả lời cho câu hỏi mà con số trung bình thời gian giải quyết không thể làm được. Thời gian giải quyết kéo dài do phải chờ đợi khách hàng phản hồi là một vấn đề hoàn toàn khác so với thời gian giải quyết kéo dài do hàng đợi quá tải.

Giờ lịch hay giờ làm việc

Mọi số liệu về phản hồi và giải quyết đều tồn tại trên hai hệ thống thời gian, và việc lựa chọn một trong hai là bắt buộc.

Zendesk lưu trữ cả hai. Sau phản hồi công khai đầu tiên, "hệ thống sẽ tính toán thời gian phản hồi đầu tiên theo giờ lịch và giờ làm việc." Cả hai chỉ số này "đều được lưu trữ cùng với dữ liệu của phiếu."

Chế độ mặc định bạn nhìn thấy không hề trung lập. Zendesk lưu ý rằng các báo cáo Explore được dựng sẵn "hiển thị thông tin theo giờ lịch." Các chỉ số giờ làm việc "vẫn có sẵn và có thể được sử dụng trong các báo cáo tự thiết lập của riêng bạn."

Vì vậy, một đội ngũ làm việc từ 9 giờ sáng đến 5 giờ chiều trông sẽ có vẻ chậm chạp trên báo cáo mặc định. Một phiếu gửi đến lúc 6 giờ tối thứ Sáu sẽ tích lũy khoảng 63 giờ lịch trước sáng thứ Hai, nhưng lại gần như bằng 0 giờ làm việc.

Các kênh trò chuyện trực tiếp còn có thêm một điểm phức tạp khác. Chỉ số Thời gian phản hồi đầu tiên (giây) cho tin nhắn và chat "bỏ qua các thiết lập về giờ làm việc của tin nhắn và giờ hoạt động của chat trực tiếp."

Và các SLA về thời gian phản hồi chat là tùy chọn kích hoạt. Zendesk tuyên bố rằng các SLA thời gian phản hồi cho chat trực tiếp "được tắt theo mặc định," vì vậy việc không có chúng là do trạng thái cấu hình chứ không phải do hiệu suất hoàn hảo.

Cách thực hiện thủ công

Tùy chọn 1: Mỗi nhóm chỉ số một tab

Xuất danh sách phiếu cùng các trường chỉ số, sau đó chia nhỏ số lượng, thời gian phản hồi và thời gian giải quyết thành các tab riêng biệt trước khi tiến hành tổng hợp bất kỳ dữ liệu nào.

Hãy để các cột giờ lịch và giờ làm việc cạnh nhau thay vì chỉ chọn một trong hai khi xuất dữ liệu. Chắc chắn bạn sẽ bị hỏi về cột còn lại sau đó.

Hãy tính toán số trung vị thay vì số trung bình cho các chỉ số thời gian. Chỉ cần một vài phiếu bị bỏ quên trong kỳ nghỉ lễ cũng có thể kéo con số trung bình lên mức mà thực tế không có phiếu nào mất nhiều thời gian đến vậy để xử lý.

Giới hạn ở đây là bảng tính không thể xem được lịch sử trạng thái. Bạn chỉ nhận được trạng thái hiện tại của từng phiếu, vì vậy hành vi mở lại phải được lấy từ số lượng phiếu bị mở lại chứ không thể tái dựng lại được.

Tùy chọn 2: Viết tab định nghĩa trước tiên

Ghi lại định nghĩa thời gian phản hồi, hệ thống thời gian, chỉ số giải quyết, quy tắc trạng thái cho phiếu đã giải quyết, các kênh trong phạm vi áp dụng và cơ sở ngày tháng.

Sau đó, hãy ghi lại những gì báo cáo không khẳng định. Việc làm rõ rằng tỷ lệ đạt SLA và thời gian phản hồi đầu tiên mặc định đo lường những thứ khác nhau sẽ giúp ngăn một đồng nghiệp (dù có ý tốt) gộp chúng lại thành một con số duy nhất.

Giới hạn ở đây vẫn là điều thường thấy. Việc ghi chép lại một quy tắc không có nghĩa là nó sẽ được áp dụng tự động, và đến quý sau, ai đó sẽ lại dựng lại bảng pivot table từ trí nhớ của họ.

Tùy chọn 3: Phân đoạn trước khi tính trung bình

Hãy chia nhỏ theo kênh trước khi tính toán bất kỳ chỉ số thời gian nào. Các phiếu từ email, chat và điện thoại có tính chất vận hành hoàn toàn khác nhau, và một con số trung vị gộp chung sẽ không phản ánh đúng thực tế của bất kỳ kênh nào.

Sau đó, hãy loại trừ hoặc gắn cờ những phiếu làm sai lệch dữ liệu. Những phiếu chờ khách hàng phản hồi hàng tuần trời nên được xếp riêng một dòng thay vì gộp chung vào mức trung bình thời gian giải quyết.

Hãy hiển thị rõ những gì bạn đã loại trừ và số lượng của chúng là bao nhiêu. Người đọc nếu không nhìn thấy bộ lọc sẽ mặc định rằng không có bộ lọc nào được áp dụng.

Hạn chế là việc phân đoạn sẽ làm tăng khối lượng công việc lên gấp nhiều lần. Ba kênh nhân với hai hệ thống thời gian nhân với hai chỉ số giải quyết sẽ tạo ra mười hai con số cần phải theo dõi chính xác.

Giới hạn chung. Cả ba tùy chọn đều giả định rằng tệp xuất dữ liệu bao gồm một khoảng ngày duy nhất trên một cơ sở ngày duy nhất cho mọi hàng đợi. Việc lẫn lộn các khoảng ngày giữa các tab là lỗi ngầm phổ biến nhất trong loại báo cáo này.

Nơi quy trình thủ công bắt đầu chậm lại

Báo cáo phiếu hỗ trợ đầu tiên có thể chỉ mất một buổi chiều. Nhưng đến báo cáo thứ tư thì sẽ mất nhiều thời gian hơn, bởi vì hệ thống help desk bên dưới đã thay đổi.

Một kênh mới được kích hoạt, khiến số trung vị gộp chung thay đổi vì những lý do không liên quan đến hiệu suất. Giờ làm việc được chỉnh sửa cho một khu vực mới, và mọi số liệu giờ làm việc trong lịch sử cũng thay đổi theo.

Sau đó, hiệu ứng mở lại phiếu xuất hiện. Số liệu của quý trước không còn khớp nữa, và việc giải thích lý do tại sao còn mất nhiều thời gian hơn cả việc xây dựng lại báo cáo từ đầu.

Có một chi phí thứ tư chỉ xuất hiện khi chịu áp lực. Ai đó hỏi liệu dịch vụ hỗ trợ có nhanh hơn trong quý này không. Một câu trả lời trung thực đòi hỏi phải làm rõ hệ thống thời gian, định nghĩa và cơ cấu kênh trước tiên.

Để có cái nhìn toàn diện về khía cạnh mức độ hài lòng, hãy xem hướng dẫn của chúng tôi về cách tạo báo cáo NPS. Nếu bản thân số lượng phiếu là vấn đề, bài viết hướng dẫn của chúng tôi về xây dựng một AI agent cho bộ phận hỗ trợ khách hàng trước bán hàng sẽ giải quyết khía cạnh giảm tải phiếu hỗ trợ.

Cách xây dựng báo cáo với Powerdrill Bloom

Bước 1: Tải lên tệp xuất dữ liệu phiếu hỗ trợ của bạn

Tải lên tệp xuất dữ liệu phiếu hỗ trợ, hoặc cả tệp xuất phiếu và SLA cùng lúc. Powerdrill Bloom sẽ phân tích các cột ngay khi tải lên, nhờ đó các mốc thời gian trống, định dạng ngày bị lẫn lộn và các phiếu thiếu phản hồi đầu tiên sẽ được phát hiện trước khi bất kỳ số trung vị nào được tính toán.

Bước 2: Mô tả báo cáo bằng ngôn ngữ tự nhiên

Hãy nêu rõ các định nghĩa thay vì phải xây dựng lại chúng. Chỉ rõ định nghĩa thời gian phản hồi, hệ thống thời gian, chỉ số giải quyết bạn muốn, quy tắc trạng thái cho phiếu đã giải quyết và các kênh trong phạm vi áp dụng.

Sau đó, hãy đặt những câu hỏi giúp phát hiện lỗi. Hỏi xem có bao nhiêu phiếu hoàn toàn không có phản hồi từ nhân viên hỗ trợ. Hỏi xem những phiếu nào đã bị mở lại. Yêu cầu tính số trung vị cho từng kênh thay vì một con số gộp chung duy nhất.

Bước 3: Xuất biểu đồ, báo cáo hoặc slide trình bày

Xuất bảng chỉ số cho từng kênh, hoặc biểu đồ so sánh số phiếu được tạo với số phiếu đã giải quyết cùng với lượng phiếu tồn đọng phía sau. Các slide trình bày chứa định nghĩa ngay cạnh các con số cũng sẽ được tạo ra trong cùng một lượt chạy.

Các sai lầm phổ biến

Trích dẫn tỷ lệ đạt SLA làm thời gian phản hồi đầu tiên. Một bên chấp nhận phản hồi tự động, còn bên kia loại trừ hoàn toàn các hành động tự động.

So sánh giờ lịch với giờ làm việc. Báo cáo mặc định cung cấp cho bạn chỉ số đầu tiên, trong khi mục tiêu của bạn có lẽ được thiết lập dựa trên chỉ số thứ hai.

Sử dụng số trung bình cho thời gian phản hồi và giải quyết. Một vài phiếu bị bỏ quên có thể kéo con số trung bình lên mức mà không một phiếu thực tế nào gặp phải.

Gộp chung các kênh. Số trung vị của chat và email vốn dĩ khác nhau theo thiết kế, và việc gộp chung sẽ che giấu thực tế của cả hai.

Báo cáo thời gian giải quyết mà không chỉ rõ loại nào. Thời gian giải quyết lần đầu và giải quyết hoàn toàn là các chỉ số được lưu trữ riêng biệt, chứ không phải là các biến thể làm tròn của nhau.

Coi số lượng phiếu đã giải quyết là con số cuối cùng. Số lượng phiếu đã giải quyết chỉ bao gồm các phiếu hiện đang ở trạng thái đã giải quyết hoặc đã đóng, vì vậy việc mở lại phiếu sẽ làm thay đổi dữ liệu quá khứ.

Bỏ qua các phiếu chưa được phản hồi. Chúng được định nghĩa là các phiếu có ít hơn một phản hồi từ nhân viên hỗ trợ, và chúng là minh chứng rõ ràng nhất cho sự thất bại trong quy trình mà báo cáo có thể chỉ ra.

Kết luận

Hãy chỉ rõ định nghĩa phản hồi, chỉ rõ hệ thống thời gian, chọn giải quyết lần đầu hoặc giải quyết hoàn toàn, nêu rõ quy tắc trạng thái, phân đoạn theo kênh, và hiển thị các phiếu bị mở lại cũng như phiếu chưa được phản hồi. Điều đó sẽ tạo ra một báo cáo phiếu hỗ trợ thực sự có giá trị hành động.

Điều mà báo cáo này có thể không làm được là so sánh một cách sòng phẳng với số liệu của một công ty khác. Các định nghĩa có thể cấu hình được, vì vậy một chỉ số chuẩn bạn đọc được ở đâu đó gần như chắc chắn đã được đo lường theo các quy tắc khác.

Thay vào đó, hãy theo dõi nó so với lịch sử của chính bạn dựa trên một bộ quy tắc cố định. Đó mới là phiên bản cho bạn biết liệu có điều gì thực sự được cải thiện hay không.

Nếu việc xây dựng lại báo cáo này hàng tháng làm tiêu tốn của bạn cả ngày trời, hãy dùng thử Powerdrill Bloom cho tệp xuất dữ liệu phiếu hỗ trợ của bạn. Xem thêm trang AI report generator và công cụ voice of customer summarizer.

Câu hỏi thường gặp

Tại sao tỷ lệ đạt SLA của tôi không khớp với thời gian phản hồi đầu tiên?

Chúng đo lường các sự kiện khác nhau. Thời gian phản hồi đầu tiên theo SLA của Zendesk có thể được hoàn thành bằng một phản hồi tự động, trong khi chỉ số thời gian phản hồi đầu tiên mặc định loại trừ hoàn toàn các hành động tự động và của bot.

Tôi nên báo cáo thời gian giải quyết lần đầu hay thời gian giải quyết hoàn toàn?

Hãy báo cáo bất kỳ chỉ số nào bạn đã chỉ định rõ. Thời gian giải quyết lần đầu kết thúc vào lần đầu tiên phiếu được chuyển sang trạng thái đã giải quyết. Thời gian giải quyết hoàn toàn kết thúc vào lần cuối cùng, vì vậy các phiếu bị mở lại chính là yếu tố tạo ra sự khác biệt giữa hai chỉ số này.

Các chỉ số hỗ trợ được đo lường theo giờ lịch hay giờ làm việc?

Cả hai đều được lưu trữ. Các báo cáo Explore được dựng sẵn của Zendesk hiển thị giờ lịch, và các chỉ số giờ làm việc luôn có sẵn cho các báo cáo do bạn tự xây dựng.

Tại sao số lượng phiếu đã giải quyết của quý trước lại thay đổi?

Số lượng phiếu đã giải quyết chỉ bao gồm các phiếu hiện đang ở trạng thái đã giải quyết hoặc đã đóng. Một phiếu được mở lại sau khi kỳ báo cáo kết thúc sẽ bị loại ra khỏi số lượng của kỳ đó.

Tôi có thể so sánh thời gian giải quyết của mình với chỉ số chuẩn của ngành không?

Chỉ ở mức độ tương đối. Các định nghĩa, hệ thống thời gian và cơ cấu kênh đều có thể cấu hình được, vì vậy một con số được công bố gần như chắc chắn đã được đo lường dựa trên các quy tắc khác với của bạn.