Cách xử lý FUD crypto: quy trình kiểm tra thông tin

Những chi tiết nào cần có trong bản ghi khiếu nại cộng đồng đầu tiên?

Một bản ghi khiếu nại 5 trường cung cấp cho nhóm một điểm khởi đầu chung. Ghi lại chính xác khiếu nại, nguồn của nó, bất kỳ bằng chứng nào được cung cấp, chủ sở hữu xem xét và trạng thái hiện tại. Giữ nguyên văn trung lập. Một nhãn như FUD không xác định liệu một tin nhắn có chính xác hay không.

Sử dụng bản ghi để lưu giữ câu hỏi, không phải để phán xét người đã đưa ra nó. Thêm liên kết đến bài đăng gốc hoặc lưu một tham chiếu nội bộ được phép. Ghi lại thời điểm nhóm nhận được nó. Nếu khiếu nại đề cập đến một giao dịch, hợp đồng hoặc thông báo dự án, hãy đính kèm nguồn công khai có liên quan thay vì dựa vào bản tóm tắt.

Phân loại vấn đề vào 1 trong 4 nhóm làm việc:

• Có thể trả lời: thông tin công khai hiện có giải quyết được câu hỏi.
• Đang xem xét: chủ sở hữu chuyên môn phải kiểm tra thông tin trước.
• Ý kiến: một dự đoán hoặc quan điểm không phải là thông tin dự án có thể xác minh.
• Nhạy cảm: thông tin bảo mật, pháp lý, kho quỹ hoặc cá nhân cần xử lý hạn chế.

Việc phân loại này giúp moderators định tuyến một mối quan tâm mà không đưa ra phán xét công khai vội vàng. Đối với các hoạt động cộng đồng ngoài xử lý sự cố, hãy xem hướng dẫn về phát triển cộng đồng Telegram crypto.

Làm thế nào để nhóm kiểm tra một khiếu nại trước khi trả lời?

So sánh nguồn với khiếu nại cho thấy bằng chứng hiện có hỗ trợ điều gì. Chỉ định việc kiểm tra cho người có quyền truy cập vào các hồ sơ liên quan. Moderator không nên suy luận về hành vi hợp đồng, quyết định kho quỹ hoặc cam kết lộ trình từ thông tin không đầy đủ.

Sử dụng ghi chú xem xét 3 phần:

• Khiếu nại: diễn đạt lại khẳng định bằng thuật ngữ trung lập, đơn giản.
• Bằng chứng: liệt kê hồ sơ công khai hoặc tài liệu dự án đã được kiểm tra.
• Phát hiện: đánh dấu những gì đã được xác nhận, chưa được giải quyết hoặc bị mâu thuẫn.

Sau đó thêm hành động tiếp theo và người chịu trách nhiệm. Đối với câu hỏi trên chuỗi, hãy mô tả chính xác những gì hồ sơ được trích dẫn hiển thị. Đừng coi một giao dịch là bằng chứng cho một giải thích rộng hơn. Đối với một tuyên bố dự án, hãy so sánh khiếu nại với tài liệu chính thức hiện tại và xác định bất kỳ sự khác biệt nào.

Các câu hỏi về listing cần một kiểm tra riêng biệt với hồ sơ hiển thị và chi tiết đã xác minh của dự án. Hướng dẫn listing CoinGecko và Hướng dẫn listing CoinMarketCap bao gồm các nhiệm vụ cụ thể cho nền tảng đó. Giữ phản hồi công khai trong phạm vi bằng chứng đã xem xét. Nếu nguồn không giải quyết được vấn đề, hãy nói rõ điều gì còn bỏ ngỏ và ai đang kiểm tra nó.

Phản hồi công khai đầu tiên nên chứa những gì?

Một phản hồi 4 phần thừa nhận mối quan tâm, nêu thông tin đã kiểm tra, xác định các điểm còn bỏ ngỏ và chỉ định hành động tiếp theo. Cấu trúc này cho phép nhóm phản hồi mà không giả vờ rằng mọi chi tiết đã được giải quyết.

Viết câu trả lời theo thứ tự này:

1. Xác định vấn đề mà không lặp lại cách diễn đạt kích động.
2. Nêu thông tin đã xác nhận và liên kết nguồn của nó.
3. Đánh dấu chi tiết vẫn cần xác minh.
4. Nói ai đang kiểm tra nó và bản cập nhật tiếp theo sẽ xuất hiện ở đâu.

Sử dụng ngôn ngữ trực tiếp. Tránh chỉ trích cá nhân, trấn an mơ hồ và khẳng định không có nguồn. Nếu câu trả lời tồn tại trong tài liệu dự án, hãy liên kết đến đoạn có liên quan. Nếu tài liệu gây nhầm lẫn, hãy sửa đổi nó cũng như trả lời cuộc trò chuyện.

Phản hồi đầu tiên không cần chứa mọi chi tiết. Nó cần cho thấy rằng mối quan tâm có chủ sở hữu và một lộ trình xem xét có thể theo dõi. Làm cho điểm cập nhật tiếp theo đủ cụ thể để moderators có thể lặp lại một cách nhất quán. Khi bằng chứng mới thay đổi câu trả lời, hãy xuất bản một chỉnh sửa ở cùng nơi thực tế và cập nhật tham chiếu được liên kết. Điều đó giữ cho cuộc trò chuyện gắn với phiên bản hiện tại thay vì với một phản hồi lỗi thời.

Làm thế nào để các phản hồi trên Telegram, Discord và X được đồng nhất?

Một ghi chú thông tin chung giữ cho 3 kênh của nhóm được đồng nhất. Lưu trữ các điểm đã xác nhận, câu hỏi chưa giải quyết, chủ sở hữu phê duyệt và bản cập nhật công khai chuẩn ở một vị trí nội bộ. Moderators có thể điều chỉnh từ ngữ cho từng cuộc trò chuyện trong khi vẫn giữ thông tin cơ bản nhất quán.

Giao cho mỗi kênh một mục đích sử dụng rõ ràng:

• Telegram: trả lời trong cuộc thảo luận đang diễn ra và chỉ vào nguồn.
• Discord: định tuyến các câu hỏi chuyên môn đến đúng kênh hoặc chủ sở hữu.
• X: giữ phản hồi công khai tập trung và liên kết đến ngữ cảnh đầy đủ hơn.

Đây là những lựa chọn giao tiếp thực tế, không phải các phiên bản riêng biệt của thông tin. Nói với moderators những tuyên bố nào họ có thể đưa ra trực tiếp và những tuyên bố nào cần phê duyệt. Nếu giải thích thay đổi, hãy cập nhật ghi chú chung trước, sau đó phân phối từ ngữ đã sửa đổi cho những người đang phản hồi công khai.

Một ghi chú nội bộ hữu ích cũng xác định vị trí cập nhật chuẩn. Điều đó ngăn những người phản hồi khác nhau liên kết đến tài liệu không liên quan hoặc lỗi thời. Đối với thiết lập vai trò và kênh máy chủ, hãy xem hướng dẫn về thiết lập máy chủ Discord crypto. Đối với các mối quan tâm cần truyền thông công khai rộng rãi hơn, hãy xem xét Crisis PR.

Những mối quan tâm cộng đồng nào moderators nên leo thang?

Một quy tắc định tuyến 2 cấp phân biệt các phản hồi thông thường với các quyết định cần thẩm quyền chuyên môn. Moderators có thể trả lời từ các tài liệu đã được phê duyệt. Họ nên leo thang các vấn đề đòi hỏi quyền truy cập, chuyên môn hoặc phê duyệt mà họ không có.

Định tuyến một mối quan tâm đến một trưởng nhóm được chỉ định khi nó liên quan đến bảo mật, rủi ro pháp lý, hành động kho quỹ hoặc thay đổi quan trọng đối với kế hoạch dự án. Trưởng nhóm nên xác nhận thông tin và phê duyệt bất kỳ tuyên bố công khai nào thay mặt cho dự án về những vấn đề đó. Chỉ định một chủ sở hữu dự phòng cho các trường hợp khi người ra quyết định thông thường không có mặt.

Các quy tắc kiểm duyệt nên mô tả hành vi có thể quan sát được, không phải liệu một bình luận có ủng hộ dự án hay không. Một câu hỏi phê bình, tự nó, không phải là lý do để xóa một tin nhắn. Áp dụng các quy tắc đã công bố cho việc đăng bài lặp đi lặp lại, thông tin cá nhân, mạo danh và các vi phạm đã nêu khác. Ghi lại lý do cho một can thiệp để moderator khác có thể xem xét quyết định.

Trước khi có sự cố, hãy cung cấp cho moderators:

• Thông tin dự án hiện tại và liên kết đến tài liệu nguồn.
• Một đầu mối liên hệ được chỉ định cho các câu hỏi kỹ thuật, pháp lý và lãnh đạo.
• Các quy tắc rõ ràng về thông tin cá nhân và mạo danh.
• Một lộ trình cho các báo cáo khẩn cấp và một đầu mối liên hệ dự phòng.

Sự chuẩn bị này cho phép nhân viên cộng đồng xử lý các câu hỏi thông thường trong khi chuyển các vấn đề rủi ro cao hơn đến các chủ sở hữu chịu trách nhiệm.

Một bản ghi sự cố nên lưu giữ những gì sau mỗi lần cập nhật?

Một tệp sự cố 6 mục làm cho phản hồi có thể theo dõi được. Giữ khiếu nại gốc, bằng chứng đã kiểm tra, chủ sở hữu xem xét, ghi chú phê duyệt, phản hồi công khai và bất kỳ chỉnh sửa nào sau đó. Bản ghi này giúp người phản hồi tiếp theo hiểu nhóm đã biết gì tại mỗi thời điểm.

Thêm một ghi chú có ngày tháng khi một thông tin đã xác nhận thay đổi. Giữ quyền truy cập tài liệu nội bộ hạn chế khi nó chứa thông tin nhạy cảm. Các phản hồi công khai không nên tiết lộ chi tiết cá nhân. Nếu bằng chứng hỗ trợ một chỉnh sửa, hãy xác định điểm không chính xác một cách rõ ràng và liên kết nguồn mới.

Đặt một nhịp độ cập nhật mà nhóm chịu trách nhiệm có thể duy trì. Nếu việc xem xét mất nhiều thời gian hơn dự kiến, hãy đăng một ghi chú trạng thái xác định câu hỏi chưa được giải quyết và vị trí cập nhật tiếp theo. Đừng ngụ ý rằng một vấn đề chưa được trả lời đã được giải quyết. Nói với moderators phiên bản câu trả lời nào là hiện tại và thay thế các liên kết cũ trong tài liệu tham khảo do dự án kiểm soát.

Xem xét tệp sau khi sự cố kết thúc. Kiểm tra xem tài liệu nguồn có rõ ràng không, chủ sở hữu có thể liên lạc được không và lộ trình leo thang có hoạt động không. Chuyển đổi bất kỳ khoảng trống nào thành một chỉnh sửa sổ tay cụ thể. Việc xem xét đó làm cho phản hồi tiếp theo dễ định tuyến hơn và giảm khả năng xảy ra các tuyên bố công khai mâu thuẫn.

Các kiểm soát phản hồi cộng đồng kết thúc ở đâu?

Một dự án có thể kiểm soát bằng chứng, phê duyệt và từ ngữ đã xuất bản của mình; nó không thể kiểm soát cách Telegram, Discord hoặc X hiển thị, kiểm duyệt hoặc phân phối bài đăng. Giữ các giải thích quan trọng trong một tài nguyên công khai do dự án kiểm soát và liên kết đến chúng từ các cập nhật cộng đồng.

Một quy trình không thể làm cho bằng chứng không đầy đủ trở nên kết luận. Nêu những gì một hồ sơ công khai hiển thị, sau đó xác định những gì nó không thiết lập. Sự phân biệt đó cung cấp cho các thành viên đủ ngữ cảnh để đánh giá giải thích mà không phóng đại phát hiện.

Trước khi có sự cố, hãy kiểm tra sổ tay với 3 trường hợp mẫu: một câu hỏi thông thường, một thông tin dự án bị tranh chấp và một mối quan tâm bảo mật. Đối với mỗi trường hợp, hãy kiểm tra bản ghi khiếu nại, chủ sở hữu, lộ trình phê duyệt và nguồn công khai. Sau đó xác nhận moderators biết thông tin hiện tại ở đâu và cách liên hệ với người ra quyết định dự phòng.

Để được xem xét từ bên ngoài, hãy gửi cho GeoMarketing Experts khiếu nại gốc, các liên kết liên quan, tài liệu công khai hiện tại và những người được ủy quyền phê duyệt phản hồi. GeoMarketing Experts có thể xem xét đường dẫn bằng chứng và vai trò phản hồi, sau đó trả lại các chỉnh sửa thực tế và khuyến nghị leo thang. Bắt đầu với một mối quan tâm hiện tại hoặc đại diện và các tài liệu mà nhóm của bạn đã sử dụng.

Cách hoạt động

1. Ghi lại khiếu nạiGhi lại chính xác từ ngữ, nguồn, thời gian và bằng chứng được cung cấp. Giữ mô tả trung lập.
2. Định tuyến việc kiểm tra thông tinChỉ định người có thể xác minh hồ sơ công khai, quyết định dự án hoặc chi tiết kỹ thuật liên quan.
3. Phê duyệt từ ngữChia sẻ thông tin đã xác nhận, xác định các điểm còn bỏ ngỏ và yêu cầu phê duyệt từ trưởng nhóm liên quan.
4. Xuất bản kèm nguồnTrả lời trong cuộc trò chuyện liên quan và liên kết đến tham chiếu công khai đầy đủ nếu hữu ích.
5. Ghi lại và cập nhậtLưu phản hồi và sửa đổi nó nếu thông tin đã xác nhận thay đổi. Nói với moderators phiên bản nào là hiện tại.