Cómo escribir un ticket de soporte eficaz

Un ticket bien escrito aporta al equipo los detalles necesarios para investigar sin hacer suposiciones. No garantiza un tiempo de respuesta ni un resultado, pero aclara el siguiente paso. Esta guía explica qué incluir y ofrece plantillas para las categorías habituales.

Para saber cómo enviar un ticket, incluidos los campos y dónde hacer clic, consulta Usar el Centro de soporte. Este artículo trata del contenido.

Estructura básica de un buen ticket

Todo ticket útil responde cuatro preguntas:

1. Qué intentaba hacer: indica tu objetivo, no solo qué salió mal.
2. Qué ocurrió realmente: incluye el error, estado o comportamiento exactos.
3. Qué probé ya: evita repetir una comprobación básica.
4. Información identificativa: dominio, buzón, número de factura o marcas de tiempo que identifican el caso.

Cuanto más contexto aportes, más fácil será revisar el área correcta del producto. Nunca incluyas una contraseña, un código 2FA ni un token de API.

Qué incluir según la categoría

Tickets de facturación

• Número de factura o referencia de pago mostrado en Billing o en el recibo.
• El cargo esperado y el cargo real, si son distintos.
• Si el problema trata de una renovación, activación de complemento, solicitud de reembolso, etc.
• Últimos 4 dígitos de la tarjeta para problemas de una tarjeta concreta, pero nunca el PAN completo ni el CVV.
• Moneda e importe de la disputa.

Ejemplo:

Ayer me cobraron $52, pero esperaba $39. Incluyo abajo el número de factura de mi página Billing. Últimos 4 dígitos: 4242. Expliquen si la diferencia corresponde a otro concepto o a impuestos. Adjunté una captura del panel que muestra el cargo.

Tickets técnicos o de envío

• Dirección del buzón remitente.
• Dirección del destinatario o patrón, por ejemplo, "todos los destinatarios @gmail.com".
• Mensaje de error exacto, con el texto completo y códigos como 550 o 421.
• Cuándo comenzó: fecha, hora y zona horaria cuando sea posible.
• Si el mismo buzón puede enviar a otras direcciones: indica si el problema se limita a un destinatario o proveedor.
• Si webmail puede enviar el mismo correo: ayuda a distinguir una configuración de la aplicación de correo de un problema de cuenta o entrega.

Ejemplo:

El buzón alice@mycompany.com no puede enviar a ninguna dirección de gmail.com desde esta mañana. Otros destinatarios (yahoo.com, outlook.com) funcionan. El rebote dice "550 5.7.1 [2026-05-15.05] Our system has detected an unusual rate of sending. Please try again later." Webmail muestra el mismo error. Comenzó aproximadamente a las 09:00 UTC del 2026-05-15. Otros buzones del mismo dominio tampoco llegan a gmail.com.

Tickets de DNS

• Nombre de dominio.
• El estado que TrekMail muestra y el registro exacto sin verificar.
• El resultado de una consulta DNS, si lo tienes, como la salida de dig para un registro MX o TXT de SPF.
• Tu proveedor DNS (Cloudflare, GoDaddy, etc.).
• El registro concreto que no se verifica.
• Si cambiaste el DNS recientemente y la hora aproximada.

Ejemplo:

Dominio: mycompany.com. El registro DKIM sigue en rojo en la página Domains. Ayer añadí el registro en Cloudflare y lo configuré como solo DNS, sin proxy. dig +short TXT dkim._domainkey.mycompany.com devuelve el valor esperado v=DKIM1; k=rsa; p=.... TrekMail aún lo marca como ausente. También comprobé la propagación desde otro servicio de consulta DNS.

Tickets de entregabilidad o spam

• Dominio y buzón remitentes.
• Tasa de rebote del panel Domain Email Stats.
• Destinatarios de ejemplo cuyos mensajes rebotan o van a spam, sin compartir la lista completa.
• Origen de la lista: formulario de consentimiento, proveedor anterior u otra fuente.
• Patrón reciente de envío: si cambiaron el volumen o la audiencia.

Ejemplo:

La tasa de rebote de mycompany.com subió de 0.5% a 8% durante los últimos siete días. Adjunté una captura de Email Stats. Envío a una lista de boletín con consentimiento de unos 2,000 suscriptores. Los rebotes incluyen "user unknown" y "mailbox over quota". Eliminé unos 200 suscriptores inactivos hace dos semanas, el único cambio reciente. ¿Debo verificar la lista restante antes de volver a enviar?

Tickets de API

• Nombre del token de API, sin pegar el token real.
• El endpoint al que llamas.
• El cuerpo de la solicitud, ocultando los datos sensibles.
• La respuesta, con código de estado y cuerpo.
• Comportamiento esperado y comportamiento observado.

Ejemplo:

Llamo a POST /api/v1/verify/bulk con un array emails ocultado y mode: quick. Recibo HTTP 422; adjunto abajo el cuerpo de respuesta sin las direcciones de correo. Esperaba que se creara una tarea de verificación. Nombre del token: "production-verify-token". Comenzó hoy aproximadamente a las 13:00 UTC y ayer funcionaba la misma solicitud.

Tickets de cuenta o acceso

• Correo de la cuenta, tu dirección de acceso.
• Qué ocurre, como no poder entrar, no recibir el restablecimiento de contraseña o que 2FA no funcione.
• Navegador y sistema operativo.
• Si accedes mediante un proveedor social (Google, Microsoft y servicios similares).
• Fecha aproximada del último acceso correcto.

Para recuperar 2FA, describe el problema de acceso y proporciona solo los datos solicitados en el proceso oficial de soporte. Nunca envíes una contraseña actual, código 2FA, código de recuperación ni documento de identidad en un ticket normal, salvo que un proceso verificado de TrekMail lo pida expresamente.

Qué NO incluir

No compartas:

• Contraseñas en texto sin formato. Nunca: ni la del panel, ni las de buzones, ni las de servicios externos.
• Números completos de tarjeta, CVV o datos bancarios completos. Los últimos 4 dígitos sirven para identificar.
• Tokens de API en texto sin formato; podemos identificarlos por nombre.
• Direcciones o datos de otros clientes en adjuntos. Anonimiza u oculta esa información.
• Datos personales sensibles de destinatarios, salvo que sean imprescindibles para investigar.

Si compartes un secreto por error, revócalo o rótalo cuando sea posible y avisa enseguida a soporte para recibir instrucciones sobre el siguiente paso.

Recomendaciones para adjuntos

• Capturas de pantalla: solo imágenes (JPEG, PNG, GIF, WebP), máximo 5 MB. Muestra la página y el error pertinentes, pero recorta u oculta las URL con tokens, direcciones de buzón u otros datos privados.
• Salida de consultas DNS: pégala como texto, con comillas invertidas para facilitar la lectura, no como captura.
• Registros de errores: pega las líneas pertinentes, no el registro completo.
• Texto de rebote: incluye el informe completo, especialmente la línea Diagnostic-Code:.
• Capturas del navegador: evita mostrar otras pestañas, notificaciones, contraseñas guardadas o datos no relacionados de clientes.

Los adjuntos de imagen del ticket se programan para eliminarse 30 días después de cerrar el ticket. Conserva una copia local de todo lo importante.

Un problema por ticket

Si tienes dos problemas independientes, abre dos tickets. Así cada conversación se mantiene centrada y el historial resulta más fácil de seguir.

Si están relacionados, por ejemplo, "falló la facturación Y se detuvo el envío", pueden ir en un ticket siempre que expliques claramente la relación.

Actualizar un ticket

Si el problema se resuelve antes de que responda soporte, por ejemplo, termina la propagación DNS o vuelve un servicio externo, añade una actualización breve como "Resolved: DNS finished propagating. Please close this ticket." También puedes cerrar un ticket activo desde su página.

Si una solución provisional sirve pero no es la solución que querías, indícalo: "I worked around it by doing X, but I would still like to understand why the original way did not work."

Plantillas que puedes copiar

Para un ticket genérico de "algo no funciona":

Subject: <one-line summary of the issue>

What I was trying to do:
  <your goal>

What happened:
  <exact error or behaviour, including error messages>

Started:
  <timestamp or "always", "since yesterday", etc.>

What I tried:
  - <attempt 1>
  - <attempt 2>

Identifying info:
  - Domain: <domain.com>
  - Mailbox: <user@domain.com>
  - <Invoice number if billing, API token name if API, and similar identifiers>

Para solicitar una función:

Subject: Feature request: <one-line description>

What I'd like to do:
  <user story: "as a <type of user>, I'd like to <action> so that <benefit>">

Current workaround:
  <if any>

Why this would help:
  <use case, frequency, scale>

Similar in other tools:
  <if any reference example>

Para disputar un cobro:

Subject: Billing dispute: <one-line summary>

Invoice number or payment reference: <from Billing or the payment receipt>
Charge amount: $X.XX
Expected amount: $Y.YY
Account email: alice@mycompany.com

What I was expecting:
  <explanation of what your subscription should have charged>

What was actually charged:
  <explanation of the actual invoice / charge>

Resolution requested:
  <refund / credit / explanation / something else>