Thói quen hỗ trợ Discord tốt không phụ thuộc vào bạn dùng bot nào - mà phụ thuộc vào việc đóng ticket kèm lý do, khóa hoặc thêm người một cách có chủ đích thay vì mặc định, và yêu cầu đóng thay vì cứ im lặng. Một hệ thống ticket cung cấp công cụ; cách nhân viên thực sự sử dụng chúng quyết định việc hỗ trợ có vẻ ngăn nắp hay hỗn loạn. Đây là danh sách kiểm tra thực tế cho nhân viên vận hành ticket hằng ngày trên Noxyr, dựa trên các lệnh và thiết lập có sẵn ngay bây giờ, không phải lời khuyên mang tính lý tưởng.

A support ticket opens, gets claimed by staff, closes, and produces an archived transcript. Open ticket #ticket-0042 Open Claimed Closed Staff assigned Transcript

Luôn ghi lý do đóng

Mọi lần đóng (/close now reason:... hoặc /ticketadmin close) đều chấp nhận một lý do, và bạn có thể bắt buộc điều này với require_close_reason để nhân viên không thể bỏ qua. "Đã giao, đơn NX-0198" hay "Đã giải quyết - vấn đề phương thức thanh toán" chỉ mất mười giây để gõ và biến danh sách bản ghi của bạn thành thứ có thể tìm kiếm được nhiều tháng sau đó, thay vì một bức tường các kênh đã đóng trông giống hệt nhau. Điều này quan trọng nhất đúng vào lúc bạn ít cần nó nhất: một tranh chấp, một chargeback, hoặc câu hỏi "chúng ta đã thống nhất điều gì" sáu tuần sau sự việc. Xem hướng dẫn bản ghi hội thoại của chúng tôi để biết những gì khác được lưu cùng với lý do.

Dùng yêu cầu đóng thay vì cứ im lặng

Nếu một ticket có vẻ đã được giải quyết nhưng bạn không hoàn toàn chắc chắn, /close request reason:"looks resolved, let us know if not" sẽ đăng một yêu cầu trong kênh với nút Đóng và Hủy, tùy chọn có bộ hẹn giờ tự đóng tính bằng phút nếu không ai phản hồi. Cách này tốt hơn hai thói quen xấu phổ biến: đóng một ticket mà thành viên thực ra chưa xong việc, và để một ticket có lẽ đã xong cứ mở vô thời hạn vì không ai muốn là người bấm nút. Nó đưa quyết định ra trước thành viên với thời hạn tích hợp sẵn, thay vì dựa vào việc ai đó nhớ theo dõi.

Nhận trước khi cam kết, bỏ nhận trước khi rời đi

/ticketadmin claim đánh dấu một ticket là của bạn để đồng đội không trả lời trùng với câu bạn đang viết. Nếu Nhận ticket sẽ khóa được bật, việc nhận còn hạn chế quyền truy cập của các vai trò nhân viên khác - và đó chính là lý do việc bỏ nhận quan trọng khi bạn xong việc hoặc chuyển giao: một ticket đã nhận nhưng bị quên có thể âm thầm chặn phần còn lại của đội không chạm vào được. Xem hướng dẫn nhận ticket của chúng tôi để biết đầy đủ thiết lập này.

Khóa ticket thay vì chỉ yêu cầu ai đó ngừng lại

/ticketadmin lock ngăn người mở ticket gửi thêm tin nhắn trong khi nhân viên xử lý việc gì đó - một tranh chấp đang nóng, một khoản thanh toán đang được xác minh, một tình huống mà thêm tin nhắn từ thành viên chỉ làm thêm nhiễu trước khi có điều mới để nói. /ticketadmin unlock đảo ngược thao tác này. Điều này bình tĩnh hơn việc yêu cầu ai đó "làm ơn đừng nhắn nữa" giữa một cuộc trò chuyện căng thẳng, và có thể hoàn tác ngay khi bạn sẵn sàng tiếp tục.

Thêm đúng người, không phải tất cả mọi người

/ticketadmin add user:@someone đưa một người cụ thể vào ticket - một nhân viên thứ hai có bối cảnh liên quan, hoặc một tài khoản khác mà thành viên nói là có liên quan đến cùng vấn đề - và /ticketadmin remove đưa họ ra ngoài. Hãy thêm người một cách có chủ đích, vì một lý do bạn có thể giải thích nếu được hỏi, không phải theo phản xạ kéo vào "cho chắc". Một ticket có sáu người mà không phải ai cũng cần có mặt sẽ khó theo dõi hơn, chứ không kỹ lưỡng hơn.

Đặt kỳ vọng trước khi nhân viên offline

Nếu đội của bạn không trực 24/7, giờ hỗ trợ sẽ đặt một thông báo ngoài giờ trung thực trước bất kỳ ai mở ticket ngoài lịch của bạn, thay vì để họ thắc mắc vì sao không ai trả lời. Kết hợp điều đó với tự động đóng được đặt ở mức hợp lý (48 giờ là mặc định an toàn) để các ticket bị bỏ rơi không mở mãi chỉ vì không ai đóng thủ công.

Trả lời từ bảng điều khiển khi bạn không ngồi ở bàn làm việc

Thành viên có thể xem và trả lời các ticket đang mở của chính họ từ bảng điều khiển web nếu ticket trên web được bật, và nhân viên có quyền truy cập có thể làm điều tương tự - hữu ích để trả lời nhanh từ điện thoại mà không cần mở chính Discord. Dù thế nào thì đó vẫn là cùng một ticket và cùng một bản ghi hội thoại; chế độ xem web chỉ là một điểm truy cập thứ hai, không phải một hệ thống riêng.

Đừng bỏ qua FAQ và trả lời tự động

Nếu cùng ba câu hỏi xuất hiện mỗi tuần, đó là dấu hiệu nên viết một mục FAQ hoặc một trả lời tự động, thay vì tiếp tục trả lời bằng tay. Thời gian nhân viên tiết kiệm được cho các câu hỏi lặp lại là thời gian nhân viên có thể dành cho những ticket thực sự cần một người suy nghĩ về chúng.

Xem các con số, không chỉ cảm tính

Phân tích ticket (khối lượng mở/nhận/đóng, thời gian phản hồi trung bình, bảng xếp hạng nhân viên) biến "hỗ trợ gần đây có vẻ chậm hơn" thành một con số cụ thể bạn có thể hành động theo thay vì tranh cãi. Hãy kiểm tra định kỳ, không chỉ khi có chuyện gì đó đã có vẻ không ổn - xem hướng dẫn phân tích ticket của chúng tôi để biết cách đọc nó mà không phản ứng thái quá với một ngày tồi tệ.

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

Thói quen có tác động lớn nhất ở đây là gì? Lý do đóng. Chúng gần như không tốn gì và có lợi mỗi lần bạn cần tra cứu lại sau này.

Mọi ticket có nên nhận yêu cầu đóng thay vì chỉ đóng luôn không? Không - dùng yêu cầu đóng khi bạn không chắc nó thực sự đã được giải quyết, và đóng trực tiếp khi rõ ràng là đã xong. Yêu cầu cho mọi ticket chỉ thêm độ trễ mà không có lý do.

Một ticket thông thường nên thêm bao nhiêu nhân viên? Càng ít càng tốt theo đúng nhu cầu thực tế - thường là người đã nhận cùng với bất kỳ ai có bối cảnh liên quan cụ thể.

Có phần đào tạo nhân viên nào được tích hợp trong bot không? Không, đây là thói quen xoay quanh các lệnh và thiết lập hiện có; bot sẽ bắt buộc lý do đóng nếu bạn yêu cầu, nhưng không dạy phần còn lại.

Làm sao để biết nhân viên có thực sự làm theo các thói quen này không? Phân tích ticket và nhật ký bản ghi hội thoại là hai nơi thể hiện hành vi thực tế, không chỉ ý định.

Thiết lập các mục này từ bảng điều khiển, hoặc xem toàn bộ mô-đun ticket trên trang bot ticket.