Skip to main content
Guias
GuiasTeamModeration

Montar uma equipe de moderação no Discord: uma estrutura que aguenta 2.000 membros

A maioria das equipes não desmorona por causa de pessoas ruins, mas pela falta de regras sobre recrutamento, permissões e inatividade. Um guia tirado da prática.

Publicado em por AlphaCloud4 min de leitura

Todo servidor em crescimento chega ao ponto em que uma pessoa sozinha não consegue mais moderar. O que costuma acontecer então: três amigos ganham permissões de moderador porque ficam muito online. Seis meses depois, dois estão inativos, ninguém tem coragem de tirar o cargo deles, e o terceiro está esgotado.

Isso não é um problema de pessoal. É a falta de um conjunto de regras.

Comece pelas permissões, não pelos cargos

A ordem habitual está invertida. A maioria cria primeiro cargos que soam como patentes e só depois pensa no que eles devem poder fazer.

Inverta. Anote quais tarefas realmente existem:

  • Alguém precisa apagar spam e acalmar discussões
  • Alguém precisa responder pedidos de suporte
  • Alguém precisa decidir quem entra na equipe
  • Alguém precisa organizar eventos

Só então agrupe tarefas em cargos. Geralmente isso gera menos cargos do que você esperava, e cada um tem um propósito claro.

As permissões mínimas

Uma regra que poupa muita dor de cabeça: ninguém recebe Administrador a menos que realmente precise administrar o servidor.

Para a moderação do dia a dia, estas bastam:

Tarefa Permissão necessária
Apagar spam Gerenciar mensagens
Acalmar alguém Castigar membros
Remover alguém Expulsar membros
Remover de vez Banir membros

Só isso. Gerenciar canais, Gerenciar cargos e Gerenciar servidor são da liderança, não da moderação. O motivo não é desconfiança, e sim controle de danos: se uma conta for comprometida, é exatamente essa lista que decide o tamanho do estrago.

O recrutamento precisa de um processo

Enquanto membros da equipe forem recrutados no feeling, cada recusa vira algo pessoal. Um processo fixo protege os dois lados.

Um processo que já provou funcionar:

  1. Candidaturas por formulário, não por mensagem direta. Assim todos na liderança veem as mesmas informações.
  2. Publique os requisitos mínimos antes. Por exemplo: 30 dias no servidor, uma idade mínima, disponibilidade por semana.
  3. Um período de experiência. Quatro semanas com permissões limitadas e depois uma decisão consciente.
  4. Uma recusa é uma recusa com motivo. Uma frase basta, mas ela precisa estar lá.

O ponto 3 é o mais importante e o mais esquecido. Um período de experiência dá uma saída natural em que ninguém fica mal.

Defina a inatividade antes, não depois

Esta é a parte mais desagradável e, por isso, a que quase todo mundo adia.

Um membro da equipe que não faz nada há três meses ocupa uma vaga e desmotiva quem trabalha. O problema é só este: sem uma regra, toda conversa sobre isso parece um ataque pessoal.

Escreva a regra antes de precisar dela. Por exemplo:

Todo membro da equipe atende pelo menos 10 casos de suporte por mês. Quem ficar abaixo disso recebe uma mensagem. Quem ficar abaixo de novo no mês seguinte devolve o cargo.

Duas coisas tornam isso suportável:

Uma forma decente de se ausentar. Férias, provas, doença. Quem avisa que vai se ausentar não conta como inativo durante esse período. Sem esse caminho, a regra é injusta e acaba sendo contornada.

Um aviso em vez de remoção. O primeiro deslize é uma mensagem, não uma punição. Quase todo mundo volta ao ritmo depois disso.

Se quiser automatizar: o AlphaCloud vai contando pelos registros de suporte ou pelos tickets atendidos e envia o aviso sozinho pela verificação de atividade. Membros que avisaram ausência são ignorados.

Advertências precisam de prazo de validade

A mesma lógica vale internamente. Quando um membro da equipe erra uma vez e recebe uma advertência, ela não deve valer para sempre.

Uma advertência que nunca expira significa que alguém que vacilou há dois anos fica permanentemente a um passo da remoção. Isso não é justo nem útil.

Defina um prazo, por exemplo 90 dias sem nova advertência, e deixe o nível expirar depois disso.

Torne as decisões visíveis

Dois canais de log que valem a pena:

  • Público: recrutamentos, promoções, saídas. Isso é reconhecimento e, de quebra, responde à pergunta "afinal, quem é da equipe".
  • Interno: advertências, bloqueios, anotações. Só para a liderança.

A separação é o objetivo. A comunidade deve ver uma promoção, mas não cada discussão interna sobre ela.

Uma lista da equipe que se mantém sozinha

Uma mensagem fixada com todos os membros da equipe está errada depois de quatro semanas. Ou você a atualiza à mão toda semana, ou deixa que ela seja gerada a partir dos cargos.

A segunda opção é a única que continua correta. Efeito colateral: quando alguém sai da equipe, some da lista automaticamente, e ninguém precisa lembrar.

A parte que nenhum software resolve

Uma equipe funciona ou fracassa por três coisas para as quais não existe botão:

Clareza sobre quem decide. Quando dois moderadores tomam decisões contraditórias, quase nunca o problema são eles, e sim que ninguém nunca disse quem dá a palavra final numa disputa.

Respaldo. Um moderador que toma uma decisão impopular mas correta e depois é corrigido publicamente pela liderança não vai tomar decisão nenhuma da próxima vez.

Uma saída. A maioria das pessoas não sai de uma equipe com raiva, sai porque a vida muda. Se sair significa ser tratado como traidor, as pessoas não saem, só ficam inativas. E aí você volta ao problema do começo.

Mais artigos