Tỷ lệ giảm thiểu ticket: công thức và cách đo lường
Tỷ lệ giảm thiểu ticket, được đo lường đúng cách: năm công thức chạy trên dữ liệu một tháng, danh sách kiểm tra thiết lập, và cách ghi nhận công lao cho các bài viết và video đã ngăn chặn ticket.
Berkay Akpolat21 phút đọc
Cập nhật ngày 3 tháng 11 năm 2026
Tỷ lệ giảm thiểu ticket là tỷ lệ phần trăm những người tìm kiếm sự trợ giúp trong trung tâm hỗ trợ của bạn mà không mở ticket. Một công thức hợp lý: các phiên tìm kiếm hỗ trợ không có ticket trong vòng 72 giờ, trừ đi các phiên thất bại rõ ràng, chia cho tất cả các phiên tìm kiếm hỗ trợ, × 100. Các công thức phổ biến cho ra những con số rất khác nhau, vì vậy hãy chọn một và giữ nguyên các quy tắc của nó.
Dưới đây: năm công thức chạy trên dữ liệu một tháng, danh sách kiểm tra thiết lập, ghi nhận bài viết và video, và những gì việc giảm thiểu mang lại.
Tỷ lệ giảm thiểu ticket là gì?
Tỷ lệ giảm thiểu ticket đo lường tần suất tự phục vụ (bài viết trợ giúp, video, trợ lý AI, câu trả lời cộng đồng) ngăn chặn một câu hỏi trở thành ticket. Đây là chỉ số tự phục vụ, không phải chỉ số của nhóm hỗ trợ: nó tăng lên khi khách hàng tìm thấy câu trả lời, không phải khi nhân viên làm việc nhanh hơn.
Ba thuật ngữ thường bị nhầm lẫn:
| Thuật ngữ | Nội dung đếm | Nguồn điển hình |
|---|---|---|
| Giảm thiểu | Người đã tìm kiếm trợ giúp và không mở ticket | Dữ liệu trung tâm trợ giúp và bộ phận hỗ trợ |
| Giải quyết | Người có vấn đề thực sự được giải quyết qua tự phục vụ | Khảo sát, bình chọn "Có hữu ích không?", không liên hệ lại |
| Kiểm soát | Các cuộc trò chuyện qua chatbot hoặc menu điện thoại không bao giờ gặp người thật | Báo cáo bot hoặc IVR |
Giảm thiểu là dễ đo lường nhất và cũng dễ bị thổi phồng nhất: một người bỏ cuộc và rời đi trong im lặng cũng "không mở ticket" (Gainsight gọi đây là giảm thiểu giả). Giải quyết mới là điều bạn thực sự muốn. Đo lường tốt sẽ thúc đẩy giảm thiểu hướng tới giải quyết.
Làm thế nào để tính tỷ lệ giảm thiểu ticket? So sánh năm công thức
Không có tiêu chuẩn chung. Các bộ phận hỗ trợ, nhà cung cấp chatbot và nhà phân tích đều sử dụng công thức riêng. Đây là năm công thức bạn sẽ gặp, cộng với kiểm soát chatbot:
1. Điểm tự phục vụ (được sử dụng bởi Zendesk, "còn được gọi là tỷ lệ tự phục vụ và tỷ lệ giảm thiểu ticket")
Điểm tự phục vụ = phiên trung tâm trợ giúp ÷ người dùng trong ticket
Ưu điểm: chỉ cần hai con số bạn đã có. Nhược điểm: đây là tỷ lệ (ví dụ 4:1), không phải phần trăm, và nó tăng theo lưu lượng truy cập ngay cả khi không ai được giúp đỡ.
2. Tỷ lệ dựa trên phiên (nhiều nhà cung cấp trung tâm trợ giúp và chatbot)
Tỷ lệ = (phiên trung tâm trợ giúp − phiên có ticket theo sau) ÷ phiên × 100
Ưu điểm: dễ giải thích dưới dạng phần trăm. Nhược điểm: mỗi lượt truy cập bị bỏ dở đều được tính là thành công, nên tỷ lệ này thường rất cao.
3. Tỷ lệ phiên đã điều chỉnh (các nhóm dựa trên phân tích; một bước thực tế hướng tới các định nghĩa nghiêm ngặt hơn như của Intercom và Metabase)
Tỷ lệ = (phiên tìm kiếm hỗ trợ − phiên có ticket theo sau − các phiên khác thất bại rõ ràng) ÷ phiên tìm kiếm hỗ trợ × 100
Ưu điểm: loại bỏ bot, nhân viên, duyệt web và thất bại rõ ràng, đồng thời sử dụng cửa sổ liên hệ lại. Nhược điểm: cần kết nối lượt truy cập với ticket, và vẫn tính cả những người rời đi trong im lặng.
4. Giảm thiểu qua biểu mẫu liên hệ (các nhóm gợi ý bài viết trên biểu mẫu ticket)
Tỷ lệ = người rời biểu mẫu sau khi xem bài viết gợi ý, không có ticket trong 72 giờ ÷ người bắt đầu biểu mẫu × 100
Ưu điểm: đếm những người định viết ticket. Nhược điểm: chỉ bao phủ một điểm truy cập.
5. Giảm thiểu cơ sở (các lãnh đạo hỗ trợ báo cáo cho bộ phận tài chính)
Giảm thiểu = (ticket trên 1.000 khách hàng trước − sau) ÷ trước × 100
Ưu điểm: đo lường kết quả mà doanh nghiệp quan tâm. Nhược điểm: bị ảnh hưởng bởi thay đổi sản phẩm, tính thời vụ và tăng trưởng.
Không phải giảm thiểu: kiểm soát chatbot (các nhà cung cấp chatbot)
Kiểm soát = (cuộc trò chuyện bot − cuộc trò chuyện chuyển cho người thật) ÷ cuộc trò chuyện bot × 100
Nó đo lường bot, không phải nội dung trợ giúp của bạn, và tính một người dùng thất vọng đóng chat là thành công.
Định nghĩa của Intercom là định nghĩa nghiêm ngặt nhất được công bố: "số phiên được giải quyết bởi hỗ trợ tự phục vụ chia cho tổng số phiên được giải quyết khi tìm kiếm hỗ trợ", trong đó "người dùng ngừng tìm kiếm hỗ trợ không được tính" và một phiên là khoảng thời gian 24 giờ. Công thức 3 không thể đạt mức đó nếu không hỏi mọi khách truy cập, vì vậy nó vẫn tính những người rời đi trong im lặng: hãy coi đó là mức trần. Để có mức sàn, chỉ đếm các phiên có tín hiệu tích cực (ví dụ: bình chọn Hữu ích) và không có ticket trong cửa sổ thời gian, như Metabase khuyến nghị. Hãy báo cáo cả hai nếu có thể; khoảng cách giữa chúng chính là sự bỏ dở trong im lặng.
Khuyến nghị của chúng tôi: báo cáo công thức 3 (với mức sàn tín hiệu tích cực) hàng tháng làm tỷ lệ giảm thiểu, và công thức 5 hàng quý làm kết quả kinh doanh. Sử dụng công thức 4 nếu bạn gợi ý bài viết trên biểu mẫu liên hệ. Chỉ giữ lại điểm số của Zendesk (công thức 1) nếu nhóm của bạn đã theo dõi nó, và đừng bao giờ đặt nó trên cùng biểu đồ với tỷ lệ phần trăm.
Một tháng, năm câu trả lời: ví dụ thực tế
Đây là dữ liệu giả định trong một tháng cho một công ty SaaS với 25.000 khách hàng, chạy qua cả năm công thức.
| Đầu vào | Giá trị |
|---|---|
| Phiên trung tâm trợ giúp | 20.000 |
| Phiên tìm kiếm hỗ trợ (đã tìm kiếm hoặc mở bài viết; đã loại bỏ bot và nhân viên) | 12.000 |
| Phiên tìm kiếm hỗ trợ có ticket theo sau từ cùng người đó trong 72 giờ | 1.400 |
| Các phiên tìm kiếm hỗ trợ khác thất bại rõ ràng (kết thúc tìm kiếm không có kết quả, hoặc bình chọn "Không hữu ích"; không có ticket theo sau) | 2.600 |
| Ticket tháng này | 2.400, từ 2.000 người |
| Lượt bắt đầu biểu mẫu liên hệ | 1.000 |
| Bỏ dở biểu mẫu sau khi mở bài viết gợi ý | 220, trong đó 40 người đã viết ticket trong 72 giờ |
| Ticket trên 1.000 khách hàng: cùng tháng năm ngoái → tháng này | 120 → 96 |
| Công thức | Tính toán | Kết quả |
|---|---|---|
| 1. Điểm tự phục vụ | 20.000 ÷ 2.000 | 10:1 |
| 2. Tỷ lệ dựa trên phiên | (20.000 − 1.400) ÷ 20.000 | 93% |
| 3. Tỷ lệ phiên đã điều chỉnh | (12.000 − 1.400 − 2.600) ÷ 12.000 | 67% |
| 4. Giảm thiểu qua biểu mẫu liên hệ | (220 − 40) ÷ 1.000 | 18% |
| 5. Giảm thiểu cơ sở | (120 − 96) ÷ 120 | ít hơn 20% ticket trên 1.000 khách hàng |
Cùng một công ty, cùng một tháng: 10:1, 93%, 67%, 18% và 20%. Không công thức nào sai cả. Chúng trả lời các câu hỏi khác nhau. Đây là lý do tại sao các dải điểm chuẩn của nhà cung cấp (ví dụ: máy tính của Chatling gắn nhãn 40–60% là "Tốt") không có nhiều ý nghĩa trừ khi bạn biết công thức nào tạo ra chúng, và tại sao bạn chỉ nên so sánh con số của mình với chính nó theo thời gian.
Làm thế nào để đo lường giảm thiểu ticket, từng bước một?
Xác định phiên tìm kiếm hỗ trợ
Đếm các phiên mà ai đó đã tìm kiếm trong trung tâm trợ giúp, mở bài viết, xem video trợ giúp hoặc hỏi trợ lý AI của trung tâm trợ giúp. Loại bỏ bot, nhân viên của bạn (lọc theo IP hoặc vai trò đăng nhập) và các lượt truy cập chỉ vào trang chủ. Đây là mẫu số của bạn.
Kết nối lượt truy cập trung tâm trợ giúp với ticket
Bạn cần biết liệu cùng một người có mở ticket sau lượt truy cập của họ hay không. Các cách thông thường: xác định người dùng đã đăng nhập trong công cụ phân tích và chuyển cùng ID người dùng đó sang bộ phận hỗ trợ, hoặc khớp theo email khi ai đó gửi biểu mẫu liên hệ. Ghi lại ít nhất: ID phiên, truy vấn tìm kiếm và số lượng kết quả, lượt xem bài viết, bình chọn hữu ích, lượt bắt đầu biểu mẫu liên hệ, lượt nhấp bài viết gợi ý, lượt bỏ dở biểu mẫu, và ticket với ID người yêu cầu và thẻ chủ đề. Những khách truy cập bạn không thể kết nối (thường là phần lớn trung tâm trợ giúp công cộng) thuộc về một ước tính riêng biệt, không trộn lẫn vào tỷ lệ đã kết nối. Nếu không có kết nối, bạn chỉ có thể báo cáo công thức 1 và 5.
Chọn cửa sổ liên hệ lại và cố định nó
Một phiên chỉ được tính là giảm thiểu nếu người đó không mở ticket trong một cửa sổ thời gian cố định. Các định nghĩa đã công bố sử dụng 24 giờ (phiên của Intercom), 48 giờ (quy tắc liên hệ lại của Helply) hoặc 72 giờ (Metabase); cửa sổ ngắn sẽ bỏ lỡ những người thử lại vào ngày hôm sau. Dù bạn chọn gì, hãy giữ cố định, nếu không đường xu hướng của bạn sẽ đo lường sự thay đổi quy tắc của bạn.
Trừ đi các thất bại rõ ràng
Loại bỏ các phiên kết thúc bằng tìm kiếm không có kết quả hoặc có bình chọn "Không hữu ích". Những người này đã không tìm thấy câu trả lời, ngay cả khi họ không gửi yêu cầu hỗ trợ. Đếm mỗi phiên một lần: một phiên thất bại dẫn đến một phiếu hỗ trợ đã nằm trong số lượng phiếu hỗ trợ rồi.
Báo cáo theo chủ đề, không chỉ tổng số
Nhóm các phiên và phiếu hỗ trợ theo cùng chủ đề: thanh toán, SSO, xuất dữ liệu, v.v. Tổng tỷ lệ 67% có thể che giấu một chủ đề chiếm 30% nhưng lại tạo ra một nửa số phiếu hỗ trợ của bạn. Sử dụng các thẻ phiếu hỗ trợ làm danh sách chủ đề và ánh xạ mỗi bài viết trợ giúp vào một thẻ.
Đặt cạnh khối lượng phiếu hỗ trợ
Báo cáo tỷ lệ giảm tải cùng với số phiếu hỗ trợ trên mỗi 1.000 khách hàng đang hoạt động. Nếu tỷ lệ giảm tải tăng nhưng số phiếu hỗ trợ trên mỗi khách hàng không giảm, bạn đang đếm sai các phiên.
Làm thế nào để quy đổi mức giảm tải cho bài viết và video?
Đây là nơi đưa ra các quyết định hữu ích. Ba phương pháp, từ đơn giản nhất đến nghiêm ngặt nhất:
1. Chủ đề trước và sau. Khi bạn xuất bản hoặc viết lại bài viết cho một chủ đề, hãy so sánh số phiếu hỗ trợ trên mỗi 1.000 khách hàng của chủ đề đó trong bốn tuần trước và bốn tuần sau. Kiểm tra xem các chủ đề khác có giữ nguyên trong cùng các tuần đó không; nếu mọi thứ đều giảm, có lẽ đó là do yếu tố mùa vụ.
2. Tỷ lệ điều chỉnh cấp bài viết. Chạy công thức 3 cho mỗi bài viết: các phiên đã xem bài viết này, trừ đi những phiên theo sau bởi một phiếu hỗ trợ về cùng chủ đề trong vòng 72 giờ, trừ đi các bình chọn "Không hữu ích". Xếp hạng các bài viết theo số phiếu hỗ trợ vẫn phát sinh sau khi xem. Đầu danh sách đó chính là hàng đợi cần viết lại của bạn.
3. Kiểm tra định dạng cho video. Để tìm hiểu xem việc thêm video hướng dẫn có làm giảm phiếu hỗ trợ hay không, hãy thêm video vào một nửa số bài viết tương tự (ví dụ: 10 trong số 20 bài viết hướng dẫn được xem nhiều nhất, chọn xen kẽ hoặc ngẫu nhiên) và để nguyên phần còn lại. Sau bốn đến sáu tuần, hãy so sánh số phiếu hỗ trợ theo chủ đề giữa hai nhóm và chỉ tin tưởng kết quả nếu mỗi nhóm có đủ số phiếu hỗ trợ để thấy sự khác biệt (vài chục mỗi tháng, không phải một vài cái). Hãy xem cả tỷ lệ hoàn thành video: một video mà hầu hết mọi người dừng lại ở 25% thì không hiệu quả. Nghiên cứu khả năng sử dụng của Nielsen Norman Group cho thấy mọi người sử dụng video như một nguồn thứ cấp, đặc biệt là cho các quy trình dài, nhiều bước, vì vậy hãy kiểm tra video trên các tác vụ nhiều bước trước.
| Câu hỏi | Phương pháp | Dữ liệu bạn cần |
|---|---|---|
| Bài viết mới có giảm phiếu hỗ trợ về chủ đề đó không? | Chủ đề trước và sau | Thẻ phiếu hỗ trợ, ngày xuất bản |
| Bài viết nào vẫn để lọt phiếu hỗ trợ? | Tỷ lệ điều chỉnh cấp bài viết | Lượt truy cập kết hợp với phiếu hỗ trợ |
| Video có làm giảm phiếu hỗ trợ cho các tác vụ của chúng ta không? | Kiểm tra định dạng | Bài viết tương tự, tỷ lệ hoàn thành video, thẻ phiếu hỗ trợ |
| Tự phục vụ có mang lại hiệu quả tổng thể không? | Giảm cơ sở | Phiếu hỗ trợ trên 1.000 khách hàng, theo quý |
Tỷ lệ giảm tải phiếu hỗ trợ bao nhiêu là tốt?
Không có tiêu chuẩn công khai đáng tin cậy nào, vì không ai sử dụng cùng một công thức. Các phạm vi bạn thấy trong các bài đăng của nhà cung cấp hiếm khi có nguồn gốc rõ ràng. Hãy đo lường dựa trên xu hướng của chính bạn.
Để hiểu rõ mức độ khó khăn của việc tự phục vụ, khảo sát của Gartner trên 5.728 khách hàng cho thấy chỉ 14% các vấn đề dịch vụ khách hàng được giải quyết hoàn toàn qua tự phục vụ, và ngay cả đối với các vấn đề mà khách hàng gọi là "rất đơn giản", con số này chỉ là 36% (Gartner, 2024). Trong cùng khảo sát đó, 73% khách hàng đã sử dụng tự phục vụ tại một thời điểm nào đó trong hành trình của họ. Hầu hết mọi người đều thử; hầu hết không kết thúc ở đó.
Cùng khảo sát đó nêu tên lý do phổ biến nhất gây thất bại: trong 43% trường hợp, khách hàng không thể tìm thấy nội dung liên quan đến vấn đề của họ. Các khảo sát trước đó của Gartner, với các mẫu khác nhau, cho thấy tỷ lệ giải quyết tự phục vụ hoàn toàn là 9% vào năm 2019 và 13% vào năm 2020: thấp, mỗi khi được đo lường (xem thêm trong thống kê tự phục vụ khách hàng của chúng tôi). Đó là vấn đề về nội dung mà bạn có thể đo lường trực tiếp thông qua các tìm kiếm không trả về kết quả.
Giảm tải phiếu hỗ trợ tiết kiệm được bao nhiêu?
Tiết kiệm mỗi tháng = số phiếu hỗ trợ được giảm tải × chi phí mỗi phiếu hỗ trợ. Phiếu hỗ trợ được giảm tải = số phiếu hỗ trợ hàng tháng × tỷ lệ là câu hỏi hướng dẫn × tỷ lệ mà tự phục vụ giải quyết được.
Đối với chi phí mỗi liên hệ, hãy sử dụng con số đầy đủ của riêng bạn nếu có. Để tham khảo, tiêu chuẩn chi phí tháng 2 năm 2024 của Gartner đưa ra mức trung bình là 1,84 đô la cho mỗi liên hệ tự phục vụ và 13,50 đô la cho mỗi liên hệ có hỗ trợ như điện thoại, trò chuyện và email (Gartner, 2024; báo cáo đầy đủ cho khách hàng). Tự phục vụ không miễn phí: để có con số ròng, hãy trừ đi chi phí của một liên hệ tự phục vụ. Với mức trung bình của Gartner, đó là 13,50 đô la − 1,84 đô la ≈ 11,66 đô la tiết kiệm được cho mỗi liên hệ được giảm tải.
Máy tính giảm tải phiếu hỗ trợ miễn phí của chúng tôi thực hiện việc này với các con số của bạn: số phiếu hỗ trợ mỗi tháng, tỷ lệ câu hỏi hướng dẫn, tỷ lệ giảm tải, thời gian xử lý mỗi phiếu hỗ trợ và chi phí mỗi phiếu hỗ trợ hoặc chi phí giờ làm việc của nhân viên. Nó trả về số phiếu hỗ trợ được giảm tải, giờ làm việc của nhân viên được tiết kiệm và số tiền tiết kiệm được mỗi tháng và mỗi năm. Ví dụ, 2.000 phiếu hỗ trợ một tháng, 40% là câu hỏi hướng dẫn và 30% được giải quyết bằng tự phục vụ sẽ mang lại 240 phiếu hỗ trợ được giảm tải một tháng; với 15 đô la một phiếu, đó là 3.600 đô la một tháng. Hãy sử dụng tỷ lệ dựa trên phiếu hỗ trợ ở đó, không phải tỷ lệ phiên: mức giảm số phiếu hỗ trợ trên 1.000 khách hàng trong công thức 5 là dữ liệu đầu vào thực tế tốt, trong khi 67% số phiên không phải là 67% số phiếu hỗ trợ.
Làm thế nào để tăng tỷ lệ giảm tải của bạn?
Hãy thực hiện theo các phép đo ở trên, theo thứ tự này:
- Viết các bài viết còn thiếu. Danh sách các tìm kiếm không có kết quả của bạn là một danh sách việc cần làm đã được xếp hạng. Khách hàng đã cho bạn biết những từ họ sử dụng. Đây là cách biến các tìm kiếm trong trung tâm trợ giúp thành danh sách bài viết cần viết.
- Sửa các bài viết để lọt phiếu hỗ trợ. Viết lại những bài có nhiều phiếu hỗ trợ nhất sau khi xem và có tỷ lệ hữu ích thấp nhất: tiêu đề rõ ràng hơn, trả lời trước, nhãn chính xác, điều kiện tiên quyết. Hướng dẫn của chúng tôi về viết bài cho trung tâm trợ giúp sẽ chỉ cho bạn cách làm.
- Thêm video vào các tác vụ nhiều bước. Sau đó kiểm tra bằng bài kiểm tra định dạng ở trên để xem nó có giúp ích không.
- Đặt câu trả lời ở nơi mọi người gặp khó khăn. Liên kết bài viết từ màn hình trong sản phẩm của bạn và đề xuất các bài viết trên biểu mẫu liên hệ của bạn.
- Giữ nội dung cập nhật. Một bài viết không còn khớp với giao diện người dùng sẽ tạo ra phiếu hỗ trợ thay vì ngăn chặn chúng. Đây là cách giữ tài liệu cập nhật khi giao diện người dùng của bạn thay đổi.
Đang xây dựng cơ sở kiến thức từ đầu? Hãy bắt đầu với cách xây dựng cơ sở kiến thức bằng AI.
Đo lường và tăng tỷ lệ giảm tải với Clevera
Clevera là một nền tảng AI biến bản ghi màn hình thành video hướng dẫn có thuyết minh, bài viết trợ giúp từng bước và một trang trên trung tâm trợ giúp được lưu trữ của bạn, bằng 74 ngôn ngữ. Trung tâm trợ giúp cung cấp cho bạn khía cạnh tự phục vụ của các phép đo ở trên; bộ phận hỗ trợ của bạn vẫn nắm giữ các phiếu hỗ trợ.
Thông tin chi tiết trên mọi gói. Mỗi trung tâm trợ giúp Clevera hiển thị Lượt xem trang, Khách truy cập, Thành công khi tìm kiếm, Tỷ lệ không có kết quả, Tỷ lệ nhấp, Tỷ lệ hữu ích trên mỗi trang và Trợ lý đã trả lời, tỷ lệ các câu hỏi Hỏi AI được trả lời từ các trang của bạn. Độc giả được đếm mà không cần cookie và bot bị loại bỏ. Bạn có thể xem lại 30 ngày trên gói Miễn phí, 90 ngày trên gói Starter và 12 tháng trên gói Pro và Custom.
Khoảng trống nội dung với nút Viết bài. Các tìm kiếm không tìm thấy gì được liệt kê cùng với số lượng người đã tìm kiếm và thời điểm. Viết bài mở trình soạn thảo với từ khóa tìm kiếm làm chủ đề và bài viết sẽ tham gia vào trung tâm trợ giúp cho lần xuất bản tiếp theo của bạn (nó tốn tín dụng như bất kỳ bài viết nào).
Đề xuất bài viết trên biểu mẫu liên hệ. Trên gói Starter trở lên, biểu mẫu liên hệ của trung tâm trợ giúp đề xuất tối đa ba trang của bạn trong khi độc giả nhập liệu và mỗi tin nhắn cho bạn biết những trang nào đã được đề xuất. Đó là thiết lập cho công thức 4; hãy đếm số lần bắt đầu và bỏ dở biểu mẫu trong phân tích của riêng bạn.
Gửi lượt xem trang đến phân tích của riêng bạn. Trên gói Starter trở lên, hãy thêm Google Analytics 4, Plausible, PostHog hoặc Segment để lượt xem trang trung tâm trợ giúp nằm cạnh dữ liệu sản phẩm của bạn. Việc kết hợp các lượt truy cập đó với phiếu hỗ trợ vẫn là công việc của bạn: nó cần ID người dùng hoặc email mà bộ phận hỗ trợ của bạn cũng có.
Lấp đầy khoảng trống nhanh hơn. Ghi lại tác vụ một lần và Clevera sẽ viết bài hướng dẫn kèm ảnh chụp màn hình, đồng thời có thể tạo video hướng dẫn có thuyết minh từ cùng bản ghi đó cho bài kiểm tra định dạng của bạn; phân tích video cho thấy tỷ lệ hoàn thành và mức độ theo dõi của người xem. Trên gói Pro và Custom, Autopilot có thể biến các câu hỏi bạn dán vào (tối đa 30) và các tìm kiếm không có kết quả thành các bài viết nháp chờ bạn phê duyệt.
Trung tâm trợ giúp được bao gồm trong mọi gói, kể cả gói Miễn phí. Gói Starter có giá 29 đô la mỗi tháng thanh toán hàng năm (36 đô la hàng tháng) và bổ sung tên miền riêng cùng các tích hợp phân tích; gói Pro bắt đầu từ 86,80 đô la mỗi tháng thanh toán hàng năm cho 2 người tạo (124 đô la hàng tháng). Giá áp dụng từ ngày 3 tháng 11 năm 2026; xem bảng giá.
Bắt đầu miễn phí hoặc đọc cách tính thông tin chi tiết về trang tài liệu.
Câu hỏi thường gặp
Bạn tính tỷ lệ chuyển đổi yêu cầu hỗ trợ như thế nào? Lấy các phiên truy cập trung tâm trợ giúp tìm kiếm hỗ trợ không dẫn đến yêu cầu hỗ trợ trong một khoảng thời gian cố định (thường là 72 giờ), trừ đi các phiên truy cập thất bại rõ ràng, chia cho tổng số phiên tìm kiếm hỗ trợ, và nhân với 100. Ví dụ: (12.000 − 1.400 − 2.600) ÷ 12.000 = 67%.
Sự khác biệt giữa điểm tự phục vụ của Zendesk và tỷ lệ chuyển đổi yêu cầu hỗ trợ là gì? Điểm tự phục vụ của Zendesk chia các phiên truy cập trung tâm trợ giúp cho số người dùng trong các yêu cầu hỗ trợ và đưa ra tỷ lệ như 4:1. Tỷ lệ chuyển đổi yêu cầu hỗ trợ là phần trăm các phiên kết thúc mà không có yêu cầu hỗ trợ nào. Chúng có thể di chuyển theo hướng ngược nhau: lưu lượng truy cập tăng làm tăng tỷ lệ ngay cả khi không có thêm yêu cầu hỗ trợ nào được tránh.
Tỷ lệ chuyển đổi yêu cầu hỗ trợ cao có phải lúc nào cũng tốt không? Không. Một tỷ lệ dựa trên các phiên bị bỏ dở có thể tăng lên trong khi khách hàng ngày càng thất vọng hơn. Hãy kiểm tra tỷ lệ này so với số lượng yêu cầu hỗ trợ trên 1.000 khách hàng, số lượt bình chọn hữu ích và các tìm kiếm không có kết quả. Trong B2B, một yêu cầu hỗ trợ được chuyển đổi từ một tài khoản chính cũng có thể là tín hiệu mà đội ngũ quản lý tài khoản của bạn không bao giờ thấy.
Khoảng thời gian liên hệ lại nên kéo dài bao lâu? Các định nghĩa được công bố sử dụng 24, 48 hoặc 72 giờ. Khoảng thời gian dài hơn sẽ nghiêm ngặt hơn. Khoảng thời gian này không quan trọng bằng việc giữ cố định nó, để xu hướng của bạn có thể so sánh được theo từng tháng.
Bạn có thể đo lường tỷ lệ chuyển đổi mà không cần liên kết lượt truy cập với yêu cầu hỗ trợ không? Một phần. Nếu không có sự kết nối, bạn có thể báo cáo tỷ lệ của Zendesk và sự thay đổi số lượng yêu cầu hỗ trợ trên 1.000 khách hàng, cộng với các tín hiệu nội dung như tìm kiếm không có kết quả và lượt bình chọn hữu ích. Báo cáo tìm kiếm của Zendesk cũng đếm "Yêu cầu hỗ trợ đã tạo": các tìm kiếm dẫn đến một yêu cầu hỗ trợ. Bạn không thể biết lượt truy cập nào đã tránh được yêu cầu hỗ trợ.
Video có chuyển đổi được nhiều yêu cầu hỗ trợ hơn bài viết không? Không có câu trả lời chung đáng tin cậy; điều đó phụ thuộc vào tác vụ. Hãy kiểm tra trên nội dung của chính bạn: thêm video vào một nửa số bài viết tương tự và so sánh số lượng yêu cầu hỗ trợ theo chủ đề sau bốn đến sáu tuần.
