Cómo llevar las postulaciones de staff en un servidor de Discord

La mayoría de los servidores recogen las postulaciones de staff con un formulario de Google o un bot de tickets. Recogerlas es la parte fácil. El lío viene después: ¿qué postulaciones ha leído alguien?, ¿quién entrevista a quién?, ¿alguien llegó a contestar a la persona que se postuló en marzo?

Esta guía monta un registro de postulaciones que tu equipo de staff usa desde Discord. No sustituye al formulario que rellenan los miembros (más sobre eso abajo). Es el proceso de revisión que viene después.

Cómo es el registro

Una fila por postulación, con:

• candidato (miembro de Discord, obligatorio)
• puesto al que se postula (texto, obligatorio)
• estado (Submitted, Under Review, Interview, Accepted, Rejected; obligatorio)
• fecha de envío
• revisor (miembro de Discord)
• notas

Esa es la plantilla Control de postulaciones de CordBase, que hacemos nosotros. Esta guía la monta a mano, con una columna extra, por un motivo que se explica en el paso 1.

Paso 1: Crea la tabla

1. Inicia sesión en cordbase.gg con Discord, elige tu servidor y añade el bot cuando te lo pida.
2. Crea una tabla llamada "Apps" con una columna de texto nombre del candidato primero y después las seis columnas de arriba. El comando será /apps.

Por qué la columna extra: cuando el staff elige una fila para actualizarla, CordBase busca y lista las filas por la primera columna de texto de la tabla. En la plantilla es "puesto al que se postula", así que diez postulaciones a Moderator aparecerían como diez entradas "Moderator" idénticas. Con una columna de nombre al principio, cada fila es fácil de encontrar.

Paso 2: Restríngela al staff

Las postulaciones son más o menos privadas, así que configura los permisos antes de que nadie la use:

• Tu rol de staff recibe Escritura (añadir y actualizar filas).
• Tu rol de admin o de jefe de moderación recibe Admin (también borrar).
• No le des ningún nivel a ningún otro rol. En cuanto una tabla tiene algún rol asignado, los miembros que no tengan uno de esos roles ya no pueden usarla, que es justo lo que quieres aquí.

Asegúrate también de que el canal donde el staff ejecuta estos comandos sea solo para el staff. Los resultados de query, view, add y update se publican en el canal donde se ejecuta el comando, así que cualquiera que vea ese canal puede verlos. Solo los errores y las confirmaciones de borrado son privados.

Paso 3: Registra las postulaciones según llegan

Cuando llega una postulación, alguien del staff la registra:

/apps add applicant_name:Rin applicant:@Rin role_applied:Moderator status:Submitted submitted_date:2026-10-08

Paso 4: Trabaja la cola

• /apps query status:Submitted muestra todo aquello de lo que nadie se ha encargado todavía.
• /apps query reviewer:@Sam muestra la cola de Sam.
• /apps update row:Rin status:Interview reviewer:@Sam notes:Interview Fri 8pm hace avanzar una postulación. Empieza a escribir el nombre del candidato en row y elígelo de la lista.

Como la cola vive en una tabla, nada depende de que alguien recuerde qué respuestas del formulario ha leído.

Dónde encaja el formulario

CordBase no recoge las respuestas de las postulaciones; los miembros no rellenan ningún formulario a través de él. Sigue usando lo que ya recoge las respuestas (un formulario de Google, un bot de tickets o un bot de postulaciones que hace las preguntas por mensaje directo) y usa el registro para el estado. La columna de notas es un buen sitio para pegar un enlace a la respuesta completa.

Después del proceso

• Exporta la tabla a CSV o JSON, algo práctico para hacer balance al final de un periodo.
• Las filas rechazadas y aceptadas pueden quedarse como historial, o un admin puede borrarlas. Las filas borradas se eliminan definitivamente a los 30 días.
• El plan Free admite 100 filas por tabla, lo que cubre muchos procesos de selección en la mayoría de los servidores. Pro lo amplía a 10 000.