Cómo configurar un sistema de tickets en Discord: qué decidir antes del primer clic

Un sistema de tickets resuelve un problema concreto: el soporte deja de hacerse en canales públicos, donde todos leen y nadie es responsable, y pasa a un canal privado entre la persona con el problema y tu equipo.

La parte técnica lleva diez minutos. Que los sistemas de tickets acaben a menudo en caos se debe a cuatro decisiones que conviene tomar de antemano.

Decisión 1: Cuántas categorías

El error más común es dividir demasiado. Un servidor empieza con ocho categorías porque todas suenan razonables de algún modo: General, Técnico, Solicitud, Queja, Alianza, Bug, Compra, Otros.

El resultado es previsible. Los miembros eligen la categoría equivocada, tu equipo tiene que mover tickets de un lado a otro y seis de las ocho nunca reciben nada.

Empieza con dos o tres. Una buena división sigue a quién es responsable, no a de qué trata:

• Soporte general para todo lo que responde tu equipo de soporte
• Solicitudes para todo lo que ve la dirección del equipo
• Reportes para todo lo que ve la moderación

Si una categoría se desborda con regularidad después de tres meses, divídela. La dirección contraria, retirar una categoría muerta, es más molesta, porque entonces tienes que mover tickets.

Decisión 2: Qué preguntar al abrir

La mayoría de los sistemas pueden mostrar un pequeño formulario antes de crear el ticket. Eso ahorra la primera ronda de preguntas, pero añade fricción.

La regla general: pregunta solo lo que tu equipo necesita para empezar. Todo lo demás sale en la conversación.

Bien:

¿De qué se trata? (obligatorio, párrafo) ¿Qué has probado ya? (opcional, párrafo)

Mal:

Nombre, edad, hora, sistema operativo, ID de Discord, leído las normas (sí/no), enlace de captura, urgencia del 1 al 5

De todos modos, Discord permite como máximo cinco campos por formulario. Usa dos.

Decisión 3: Quién ve qué ticket

Este es el punto del que te arrepientes a largo plazo si te equivocas.

Un sistema de tickets asigna permisos de canal por categoría. Así que la pregunta no es "quién está en el equipo", sino "quién puede leer solicitudes". Si tu equipo de soporte tiene acceso a la categoría de solicitudes, quince personas leen cuando alguien se presenta. Eso rara vez es lo que se pretende.

Define los roles por categoría, no de forma global. En AlphaCloud es el campo roles de soporte en cada categoría de tickets.

Decisión 4: Qué pasa con los tickets cerrados

Un servidor con soporte activo produce rápidamente cientos de canales de tickets. Hay tres enfoques habituales:

Enfoque	Ventaja	Inconveniente
El canal se queda, movido a una categoría de archivo	Todo se puede leer	Discord permite como máximo 500 canales por servidor
El canal se borra	Limpio	El historial desaparece
El canal se borra, pero antes se crea una transcripción	Las dos cosas	Hace falta un sistema que lo haga

La tercera es la correcta en cuanto tu soporte funciona con regularidad. Una transcripción es una copia buscable de la conversación que sigue ahí mucho después de que el canal haya desaparecido. La necesitarás, como muy tarde, en la primera discusión sobre lo que supuestamente se prometió en un ticket.

AlphaCloud guarda las transcripciones en una web propia, archivos adjuntos incluidos. Lo importante es que los adjuntos se guarden al cerrar, porque los enlaces de imágenes de Discord dejan de funcionar cuando se borra el canal.

La configuración en sí

Con los cuatro puntos decididos, el resto es mecánico:

1. Crea una categoría de Discord en la que aparezcan los canales de tickets
2. Crea las categorías en el bot y define los roles de soporte
3. Opcionalmente, una o dos preguntas por categoría
4. Publica un panel en un canal desde el que los miembros abran tickets
5. Define un canal de registros

Después, sin falta, abre tú mismo un ticket y recórrelo una vez. Ahí es donde te das cuenta de que el equipo no ve la nueva categoría o de que el mensaje de bienvenida sigue siendo el texto de ejemplo.

Dos cosas que merece la pena añadir más tarde

Valoraciones. Tras cerrar, el sistema puede pedir una valoración. Es menos útil para las estadísticas que para el único caso en que alguien da una estrella y escribe por qué. Esa opinión no la recibes de ninguna otra forma.

Cierre automático. Los tickets en los que nadie escribe desde hace días atascan la vista general. Un temporizador que cierra tras 48 horas de silencio, preguntando una vez antes, mantiene la lista limpia sin que nadie tenga que ordenar.

Lo que un sistema de tickets no resuelve

No hace el soporte más rápido. Solo lo hace localizable, con un responsable y legible después.

Si nadie responde, ningún sistema ayuda. Lo que ayuda: una notificación al equipo cuando se abre un ticket y una nota sincera en el panel sobre cuánto se está tardando ahora mismo. Las dos cosas dan mucho menos trabajo que disculparse después por el silencio.