Skip to main content
Guide
GuideTeamModeration

Creare un team di moderazione Discord: una struttura che regge a 2.000 membri

La maggior parte dei team non va in pezzi per colpa di persone sbagliate, ma per mancanza di regole su reclutamento, permessi e inattività. Una guida dalla pratica.

Pubblicato il di AlphaCloud4 min di lettura

Ogni server che cresce arriva al punto in cui una persona da sola non riesce più a moderare. Di solito succede questo: tre amici ricevono i permessi da moderatore perché sono spesso online. Sei mesi dopo due di loro sono inattivi, nessuno osa togliergli il ruolo, e il terzo è esaurito.

Non è un problema di personale. È un regolamento che manca.

Parti dai permessi, non dai ruoli

L'ordine abituale è al contrario. La maggior parte delle persone crea prima ruoli che suonano come gradi, e solo dopo pensa a cosa dovrebbero poter fare.

Rovescialo. Scrivi quali compiti esistono davvero:

  • Qualcuno deve eliminare lo spam e calmare le discussioni
  • Qualcuno deve rispondere alle richieste di supporto
  • Qualcuno deve decidere chi entra nel team
  • Qualcuno deve organizzare gli eventi

Solo dopo raggruppa i compiti in ruoli. Di solito ne escono meno ruoli di quanti ti aspettassi, e ognuno ha uno scopo chiaro.

I permessi minimi

Una regola che risparmia un sacco di guai: nessuno riceve Amministratore a meno che non debba davvero amministrare il server.

Per la moderazione quotidiana bastano questi:

Compito Permesso necessario
Eliminare lo spam Gestisci messaggi
Calmare qualcuno Metti membri in timeout
Allontanare qualcuno Espelli membri
Allontanare in modo permanente Banna membri

Tutto qui. Gestisci canali, Gestisci ruoli e Gestisci server spettano alla direzione, non alla moderazione. Il motivo non è la sfiducia ma il contenimento dei danni: se un account viene compromesso, è proprio questo elenco a decidere quanto andrà male.

Il reclutamento ha bisogno di un processo

Finché i membri del team vengono scelti a istinto, ogni rifiuto diventa personale. Un processo fisso protegge entrambe le parti.

Un processo che ha dato buona prova:

  1. Candidature tramite un modulo, non con un messaggio diretto. Così tutti nella direzione vedono le stesse informazioni.
  2. Pubblica prima i requisiti minimi. Per esempio: 30 giorni sul server, un'età minima, disponibilità a settimana.
  3. Un periodo di prova. Quattro settimane con permessi limitati, poi una decisione consapevole.
  4. Un rifiuto è un rifiuto con un motivo. Basta una frase, ma dovrebbe esserci.

Il punto 3 è il più importante ed è quello che si salta più spesso. Un periodo di prova ti dà un'uscita naturale in cui nessuno perde la faccia.

Regola l'inattività prima, non dopo

È la parte più sgradevole e quindi quella che quasi tutti rimandano.

Un membro del team che non fa nulla da tre mesi occupa un posto e demotiva chi lavora. Il problema è solo questo: senza una regola, ogni conversazione sull'argomento sembra un attacco personale.

Scrivi la regola prima che ti serva. Per esempio:

Ogni membro del team gestisce almeno 10 casi di supporto al mese. Chi sta sotto riceve un messaggio. Chi resta sotto anche il mese successivo restituisce il ruolo.

Due cose la rendono sopportabile:

Un modo vero per segnalare un'assenza. Vacanze, esami, malattia. Chi si assenta non conta come inattivo in quel periodo. Senza questa strada la regola è ingiusta e viene aggirata.

Un avvertimento invece della rimozione. La prima mancanza è un messaggio, non una sanzione. Quasi tutti dopo riprendono.

Se vuoi automatizzarlo: AlphaCloud tiene il conto tramite le voci di supporto o i ticket gestiti, e invia da solo l'avvertimento tramite il controllo attività. I membri che hanno segnalato un'assenza vengono saltati.

Gli avvertimenti hanno bisogno di una scadenza

La stessa logica vale all'interno. Se un membro del team sbaglia una volta e riceve un avvertimento, non dovrebbe restare per sempre.

Un avvertimento che non scade mai significa che qualcuno che ha sbagliato due anni fa è sempre a un passo dalla rimozione. Non è né giusto né utile.

Stabilisci un periodo, per esempio 90 giorni senza un nuovo avvertimento, e lascia che il livello scada dopo.

Rendi visibili le decisioni

Due canali log che vale la pena avere:

  • Pubblico: reclutamenti, promozioni, uscite. È un riconoscimento, e intanto risponde alla domanda "chi fa davvero parte dello staff".
  • Interno: avvertimenti, blocchi, note. Solo per la direzione.

La separazione è il punto. La community deve vedere una promozione, ma non ogni discussione interna che c'è stata intorno.

Una lista del team che si aggiorna da sola

Un messaggio fissato con l'elenco di tutti i membri del team è sbagliato dopo quattro settimane. O lo aggiorni a mano ogni settimana, o lo lasci generare da solo a partire dai ruoli.

La seconda è l'unica versione che resta corretta. Effetto collaterale: quando qualcuno lascia il team sparisce automaticamente dalla lista, e nessuno deve ricordarsene.

La parte che nessun software risolve

Un team funziona o fallisce su tre cose per cui non esiste un interruttore:

Chiarezza su chi decide. Quando due moderatori prendono decisioni contraddittorie, quasi mai il problema sono loro: è che nessuno ha mai detto chi ha l'ultima parola in caso di disaccordo.

Sostegno. Un moderatore che prende una decisione impopolare ma corretta e poi viene corretto pubblicamente dalla direzione, la prossima volta non prenderà proprio nessuna decisione.

Una via d'uscita. La maggior parte delle persone non lascia un team per rabbia, lo lascia perché la vita cambia. Se andarsene significa passare per traditori, le persone non se ne vanno, diventano semplicemente inattive. E allora sei di nuovo al problema dell'inizio.

Altri articoli