Checklist de lançamento de servidor RP: o que corrigir antes dos jogadores chegarem

O erro comum é tratar Discord como superfície de anúncio. O time lapida trailer, banner, lore, prints e data. Aí chega o launch e jogadores fazem as perguntas operacionais: onde aplico, por que não vejo as regras, quem resolve comp, onde reporto bug, por que meu ticket está aberto há 30 horas?

É assim que um lançamento deixa de parecer premium. Não porque a cidade é ruim. Porque o caminho para entrar na cidade é confuso.

Use este checklist antes do anúncio, não depois que a primeira onda se perde.

Duas semanas antes, pare de adicionar ideias e defina como o servidor vai operar.

1. Caminho do jogador. Convite - regras - aplicação - revisão - whitelist - suporte - fluxo de facção.
2. Caminho da staff. Entrada do ticket - triagem - decisão - escalonamento - fechamento - revisão semanal.
3. Donos claros. Uma pessoa para whitelist, uma para tickets, uma para facções, uma para incidentes técnicos.
4. Limites escritos. Se ban appeal não é por DM, diga. Se comp precisa de evidência, diga.

Isto não é branding. É teste de pressão. Se ninguém é dono do fluxo antes do launch, ninguém será dono quando 80 pessoas entrarem ao mesmo tempo.

Uma semana antes, convide 3 a 5 testers confiáveis que não viram o setup interno. Dê apenas o convite público.

Observe. Não ajude. A confusão é o sinal.

• Eles acham a aplicação sem perguntar?
• Conseguem explicar as regras depois de ler a área inicial?
• Sabem onde pedir suporte?
• Entendem quais canais são importantes e quais são conversa?
• Sabem o que acontece depois da aplicação?

Se um tester pergunta por DM, essa resposta pertence ao fluxo público. DM é onde operação de lançamento vai morrer.

Não teste como Owner. Owner vê tudo e mascara os erros que staff normal e jogadores vão encontrar.

Teste estes perfis:

• Applicant. Deve ver início e suporte de aplicação, não staff ops.
• Whitelisted. Deve ver comunidade e suporte, não sujeira de aplicação.
• Trial Staff. Deve resolver tickets comuns sem mexer em permissões.
• Moderator. Deve moderar e atender sem Administrator amplo.
• Faction Lead. Deve ver fluxo da facção sem estratégia interna da staff.

A pergunta operacional é simples: cada cargo consegue fazer exatamente o próprio trabalho, e nada além disso?

Na semana do launch, você precisa ver os mesmos números todos os dias:

1. Aplicações pendentes
2. Idade mediana dos tickets
3. Ticket aberto mais antigo
4. Staff ativo nas últimas 24 horas
5. Novas mudanças de cargo, canal ou permissão
6. Top 3 perguntas repetidas pelos jogadores

Se um indicador piora dois dias seguidos, trate como incidente de operações. Pequenos problemas da semana 1 viram decadência do mês 2 quando ninguém acompanha tendência.

Launch day cria ruído. Todo mundo estará ocupado. Por isso uma pessoa precisa ser deliberadamente operacional.

O dono de ops não roda evento e não fica fazendo hype no chat. Ele observa filas, permissões, picos de suporte, perguntas repetidas e handoffs da staff. A função é impedir que empolgação esconda quebra.

Dê autoridade para pausar aplicações, re-rotear tickets, fixar esclarecimentos e puxar líderes de staff. Se ele só pode observar, ele não é dono.

• Candidatos precisam chamar staff por DM para aplicar.
• Todos os tickets caem numa fila genérica.
• Staff não sabe SLA de resposta.
• Moderadores comuns têm Administrator porque permissões pareciam difíceis.
• Regras e exemplos de punição se contradizem.
• Ninguém sabe reverter uma mudança ruim de canal ou permissão.
• Líderes de facção não têm dono, docs ou caminho de escalonamento.

Nada disso significa que o servidor está condenado. Significa que a data está à frente do sistema operacional. Corrija primeiro.

A KeepGrid transforma isso em checklist de lançamento, pacote de docs e plano de instalação no Discord. Se o servidor já existe, rode o Ops Audit gratuito antes de anunciar a data. Se ainda está construindo, use o Launch OS para revisar canais, cargos, permissões e tickets antes do bot aplicar qualquer mudança.