Thiết lập hệ thống ticket Discord: Những điều cần chốt trước cú nhấp đầu tiên

Hệ thống ticket giải quyết một vấn đề cụ thể: hỗ trợ không còn diễn ra trong các kênh công khai, nơi ai cũng đọc nhưng không ai chịu trách nhiệm, mà trong một kênh riêng giữa người gặp vấn đề và đội của bạn.

Phần kỹ thuật mất mười phút. Lý do hệ thống ticket vẫn thường kết thúc trong hỗn loạn nằm ở bốn quyết định tốt nhất nên đưa ra từ trước.

Quyết định 1: Bao nhiêu danh mục

Sai lầm phổ biến nhất là chia quá nhỏ. Một máy chủ bắt đầu với tám danh mục vì nghe cái nào cũng có vẻ hợp lý: Chung, Kỹ thuật, Ứng tuyển, Khiếu nại, Hợp tác, Lỗi, Mua hàng, Khác.

Kết quả dễ đoán. Thành viên chọn sai danh mục, đội của bạn phải chuyển ticket qua lại, và sáu trong tám danh mục chẳng bao giờ nhận được gì.

Hãy bắt đầu với hai hoặc ba. Cách chia tốt dựa trên ai chịu trách nhiệm, không phải nội dung là gì:

• Hỗ trợ chung cho mọi thứ đội hỗ trợ của bạn trả lời
• Ứng tuyển cho mọi thứ ban lãnh đạo đội xem
• Báo cáo cho mọi thứ đội kiểm duyệt xem

Nếu một danh mục thường xuyên quá tải sau ba tháng, hãy tách nó ra. Chiều ngược lại, bỏ một danh mục chết, khó chịu hơn vì khi đó bạn phải chuyển ticket.

Quyết định 2: Hỏi gì khi mở ticket

Hầu hết hệ thống có thể hiện một biểu mẫu nhỏ trước khi ticket được tạo. Nó giúp bỏ qua vòng hỏi lại đầu tiên nhưng thêm ma sát.

Nguyên tắc: chỉ hỏi những gì đội của bạn cần để bắt đầu. Mọi thứ khác sẽ lộ ra trong cuộc trò chuyện.

Tốt:

Chuyện này về việc gì? (bắt buộc, đoạn văn) Bạn đã thử những gì? (tùy chọn, đoạn văn)

Tệ:

Tên, tuổi, giờ, hệ điều hành, Discord ID, đã đọc nội quy (có/không), liên kết ảnh chụp màn hình, mức khẩn cấp từ 1 đến 5

Dù sao Discord cũng chỉ cho tối đa năm trường mỗi biểu mẫu. Hãy dùng hai.

Quyết định 3: Ai thấy ticket nào

Đây là điểm bạn hối hận lâu dài nếu làm sai.

Hệ thống ticket cấp quyền kênh theo từng danh mục. Vì vậy câu hỏi không phải "ai thuộc đội" mà là "ai được đọc đơn ứng tuyển". Nếu đội hỗ trợ của bạn có quyền vào danh mục ứng tuyển, mười lăm người sẽ cùng đọc khi có ai đó ứng tuyển. Điều đó hiếm khi là chủ ý.

Hãy đặt vai trò theo từng danh mục, không phải toàn cục. Trong AlphaCloud, đó là trường vai trò hỗ trợ trong mỗi danh mục ticket.

Quyết định 4: Ticket đã đóng thì sao

Một máy chủ có hỗ trợ sôi nổi nhanh chóng sinh ra hàng trăm kênh ticket. Có ba cách thường gặp:

Cách	Ưu điểm	Nhược điểm
Giữ kênh, chuyển vào danh mục lưu trữ	Mọi thứ vẫn đọc được	Discord cho tối đa 500 kênh mỗi máy chủ
Xóa kênh	Gọn gàng	Lịch sử mất
Xóa kênh, nhưng tạo bản ghi trước	Cả hai	Cần một hệ thống làm được việc đó

Cách thứ ba là đúng ngay khi hỗ trợ của bạn diễn ra đều đặn. Bản ghi là một bản sao có thể tìm kiếm của cuộc trò chuyện, vẫn còn đó rất lâu sau khi kênh đã biến mất. Muộn nhất bạn sẽ cần nó trong lần tranh cãi đầu tiên về việc được cho là đã hứa gì trong một ticket.

AlphaCloud lưu bản ghi trên trang riêng, kèm cả tệp đính kèm. Điều quan trọng là tệp đính kèm được lưu khi đóng ticket, vì liên kết ảnh của Discord ngừng hoạt động khi kênh bị xóa.

Bản thân việc thiết lập

Khi bốn điểm trên đã chốt, phần còn lại là cơ học:

1. Tạo một danh mục Discord để các kênh ticket xuất hiện trong đó
2. Tạo các danh mục trong bot và đặt vai trò hỗ trợ
3. Tùy chọn một hoặc hai câu hỏi cho mỗi danh mục
4. Đăng một bảng điều khiển vào một kênh để thành viên mở ticket từ đó
5. Đặt một kênh nhật ký

Sau đó, nhất định tự mở một ticket và đi qua nó một lần. Đó là lúc bạn nhận ra đội của mình hoàn toàn không thấy danh mục mới, hay tin nhắn chào mừng vẫn còn là văn bản giữ chỗ.

Hai thứ đáng thêm về sau

Đánh giá. Sau khi đóng, hệ thống có thể xin một lượt đánh giá. Nó ít hữu ích cho thống kê hơn là cho đúng một trường hợp, khi ai đó cho một sao và viết lý do. Bạn sẽ không bao giờ nhận được phản hồi đó theo cách khác.

Tự động đóng. Những ticket mà nhiều ngày không ai viết gì làm tắc nghẽn phần tổng quan. Một bộ hẹn giờ đóng ticket sau 48 giờ im lặng, hỏi trước một lần, giữ danh sách gọn gàng mà không ai phải dọn.

Điều hệ thống ticket không giải quyết

Nó không làm hỗ trợ nhanh hơn. Nó chỉ làm cho hỗ trợ có thể tìm thấy, có người chịu trách nhiệm và đọc lại được về sau.

Nếu không ai trả lời, không hệ thống nào giúp được. Điều giúp được: một thông báo cho đội khi có ticket mở, và một ghi chú trung thực trong bảng điều khiển về việc hiện tại mất bao lâu. Cả hai đều ít công sức hơn nhiều so với việc xin lỗi vì im lặng về sau.