Xây dựng đội kiểm duyệt Discord: Cấu trúc trụ vững ở mức 2.000 thành viên
Hầu hết đội ngũ không tan rã vì người tệ, mà vì thiếu quy tắc về tuyển chọn, phân quyền và tình trạng không hoạt động. Hướng dẫn từ thực tế.

Mọi máy chủ đang lớn lên đều đến lúc một người không thể kiểm duyệt một mình nữa. Điều thường xảy ra khi đó: ba người bạn được cấp quyền người kiểm duyệt vì họ hay online. Sáu tháng sau, hai trong số họ không còn hoạt động, chẳng ai dám lấy lại vai trò, còn người thứ ba thì kiệt sức.
Đó không phải vấn đề nhân sự. Đó là thiếu một bộ quy tắc.
Bắt đầu từ quyền hạn, không phải vai trò
Thứ tự thông thường bị ngược. Hầu hết mọi người tạo vai trò nghe như cấp bậc trước, rồi sau đó mới tính xem chúng được phép làm gì.
Hãy đảo ngược lại. Viết ra những nhiệm vụ thực sự tồn tại:
- Cần có người xóa spam và dập tắt tranh cãi
- Cần có người trả lời yêu cầu hỗ trợ
- Cần có người quyết định ai được vào đội ngũ
- Cần có người tổ chức sự kiện
Chỉ sau đó mới gom nhiệm vụ thành vai trò. Thường thì số vai trò sẽ ít hơn bạn tưởng, và mỗi vai trò có một mục đích rõ ràng.
Quyền tối thiểu
Một quy tắc giúp tránh được nhiều rắc rối: không ai được nhận quyền Quản trị viên trừ khi họ thực sự phải quản trị máy chủ.
Cho việc kiểm duyệt hằng ngày, chừng này là đủ:
| Nhiệm vụ | Quyền cần thiết |
|---|---|
| Xóa spam | Quản lý tin nhắn |
| Làm ai đó bình tĩnh lại | Hạn chế thành viên |
| Loại ai đó ra | Đuổi thành viên |
| Loại vĩnh viễn | Cấm thành viên |
Chỉ vậy thôi. Quản lý kênh, Quản lý vai trò và Quản lý máy chủ thuộc về ban lãnh đạo, không phải đội kiểm duyệt. Lý do không phải là thiếu tin tưởng mà là kiểm soát thiệt hại: nếu một tài khoản bị chiếm, chính danh sách này quyết định hậu quả tệ đến mức nào.
Tuyển chọn cần một quy trình
Chừng nào thành viên đội ngũ còn được tuyển theo cảm tính, mỗi lần từ chối đều trở thành chuyện cá nhân. Một quy trình cố định bảo vệ cả hai bên.
Một quy trình đã được chứng minh hiệu quả:
- Ứng tuyển qua biểu mẫu, không qua tin nhắn riêng. Như vậy mọi người trong ban lãnh đạo đều thấy cùng một thông tin.
- Công bố yêu cầu tối thiểu từ trước. Ví dụ: 30 ngày trên máy chủ, độ tuổi tối thiểu, số giờ có mặt mỗi tuần.
- Một giai đoạn thử việc. Bốn tuần với quyền hạn hạn chế, rồi đưa ra quyết định có cân nhắc.
- Từ chối là từ chối kèm lý do. Một câu là đủ, nhưng phải có.
Điểm 3 quan trọng nhất và cũng hay bị bỏ qua nhất. Giai đoạn thử việc cho bạn một lối ra tự nhiên mà không ai bị mất mặt.
Giải quyết chuyện không hoạt động từ trước, đừng để sau
Đây là phần khó chịu nhất và vì thế là phần gần như ai cũng trì hoãn.
Một thành viên đội ngũ không làm gì suốt ba tháng chiếm một chỗ và làm nản lòng những người đang làm việc. Vấn đề chỉ là: nếu không có quy tắc, mọi cuộc nói chuyện về điều đó đều giống như một đòn tấn công cá nhân.
Hãy viết quy tắc ra trước khi bạn cần đến nó. Ví dụ:
Mỗi thành viên đội ngũ xử lý ít nhất 10 trường hợp hỗ trợ mỗi tháng. Ai dưới mức đó sẽ nhận một tin nhắn. Ai tiếp tục dưới mức đó vào tháng sau sẽ trả lại vai trò.
Hai điều khiến quy tắc này dễ chấp nhận:
Một cách báo vắng đàng hoàng. Kỳ nghỉ, kỳ thi, ốm đau. Ai đã báo vắng thì không bị tính là không hoạt động trong thời gian đó. Không có con đường này, quy tắc trở nên bất công và sẽ bị lách.
Cảnh báo thay vì loại bỏ. Lần thiếu chỉ tiêu đầu tiên là một tin nhắn, không phải hình phạt. Gần như ai cũng bắt nhịp lại sau đó.
Nếu bạn muốn tự động hóa: AlphaCloud đếm song song qua lượt hỗ trợ hoặc số ticket đã xử lý, và tự gửi cảnh báo qua kiểm tra hoạt động. Thành viên đã báo vắng sẽ được bỏ qua.
Cảnh cáo cần có ngày hết hạn
Logic tương tự áp dụng trong nội bộ. Khi một thành viên đội ngũ mắc lỗi một lần và nhận cảnh cáo, cảnh cáo đó không nên tồn tại mãi mãi.
Một cảnh cáo không bao giờ hết hạn nghĩa là ai đó lỡ tay hai năm trước sẽ mãi chỉ cách việc bị loại một bước. Điều đó vừa không công bằng vừa chẳng có ích.
Hãy đặt một thời hạn, chẳng hạn 90 ngày không có cảnh cáo mới, và để mức cảnh cáo hết hạn sau đó.
Làm cho các quyết định hiển thị
Hai kênh nhật ký đáng có:
- Công khai: tuyển chọn, thăng chức, rời đội. Đó là sự ghi nhận, và tiện thể trả lời luôn câu hỏi "ai thực sự là thành viên đội ngũ".
- Nội bộ: cảnh cáo, khóa, ghi chú. Chỉ dành cho ban lãnh đạo.
Sự tách biệt chính là mấu chốt. Cộng đồng nên thấy một lần thăng chức, nhưng không phải mọi cuộc thảo luận nội bộ về nó.
Một danh sách đội ngũ tự duy trì
Một tin nhắn ghim liệt kê mọi thành viên đội ngũ sẽ sai sau bốn tuần. Hoặc bạn cập nhật nó thủ công mỗi tuần, hoặc bạn để nó tự tạo ra từ các vai trò.
Cách sau là phiên bản duy nhất luôn đúng. Tác dụng phụ: khi ai đó rời đội ngũ, họ tự động biến mất khỏi danh sách, và không ai phải nhớ.
Phần không phần mềm nào giải quyết được
Một đội ngũ thành hay bại dựa vào ba thứ mà không có công tắc nào bật được:
Sự rõ ràng về việc ai quyết định. Khi hai người kiểm duyệt đưa ra quyết định trái ngược, gần như không bao giờ là do bản thân họ, mà là vì chưa ai từng nói ai có tiếng nói cuối cùng khi bất đồng.
Sự hậu thuẫn. Một người kiểm duyệt đưa ra quyết định không được lòng nhưng đúng, rồi bị ban lãnh đạo sửa sai công khai, thì lần sau sẽ chẳng đưa ra quyết định nào nữa.
Một lối ra. Hầu hết mọi người không rời đội ngũ vì tức giận, họ rời đi vì cuộc sống thay đổi. Nếu rời đi đồng nghĩa với bị coi là kẻ phản bội, người ta sẽ không rời đi, họ chỉ ngừng hoạt động. Và thế là bạn quay lại đúng vấn đề lúc đầu.
Bài viết khác
Thiết lập xác minh Discord: Phương thức nào chặn vấn đề nào
Nút bấm, bài toán, đăng nhập Discord hay liên kết ngoài: mỗi kiểu xác minh chặn một thứ khác nhau. Cách chọn đúng kiểu, và hai lỗi làm hỏng gần như mọi thiết lập.
Hướng dẫnAnti Nuke: Điều gì xảy ra khi một tài khoản admin bị chiếm quyền
Raid đến từ bên ngoài, nuke đến từ bên trong. Lớp bảo vệ hoạt động thế nào, vì sao nó chấm điểm mối đe dọa thay vì dùng quy tắc cố định, và nó không làm được gì.
Hướng dẫnThiết lập AutoMod: Sáu bộ lọc và cơ chế leo thang phía sau
Kiểm duyệt tự động hiếm khi thất bại ở khâu phát hiện, nó thất bại ở khâu phản ứng. Sáu bộ lọc hoạt động thế nào và hình phạt nào hợp với vi phạm nào.