Usa esta plantilla
Un gran soporte empieza con una gran documentación de tickets. Con Trupeer, puedes ahorrar horas en la documentación de soporte empezando con un ticket de cliente y una plantilla de resolución gratuitas, personalizándola con tus directrices de marca y convirtiendo los tickets resueltos en casos de estudio en vídeo para la base de conocimiento de soporte.
La mayoría de los equipos de soporte tienen un sistema de tickets lleno de tickets y no tienen idea de qué está saliendo mal realmente. Todo se categoriza como Otros, las notas de resolución dicen "corregido" y el informe mensual muestra volumen y nada más.
Ese es un problema de diseño del campo, no de reporting. Esta plantilla cubre las dos mitades de un ticket: el registro que capturas, que determina lo que puedes aprender, y las respuestas que envías, que determinan lo que el cliente experimenta.
Descarga la plantilla de ticket y resolución
Formato | Ideal para |
|---|---|
Excel (.xlsx) | El registro de tickets, con categorías, códigos de resolución y pestañas de reporting |
Word (.docx) | El formulario de ticket, el informe de resolución y las plantillas de respuesta |
Formularios de ticket imprimibles y rellenables para atención presencial o servicio de campo | |
Google Sheets | Un registro compartido para equipos pequeños sin una herramienta de helpdesk |
Google Docs | Las plantillas de respuesta, para copiarlas en tus respuestas preparadas del helpdesk |
Gratis, editable y sin marca de agua. Si ya tienes una herramienta de helpdesk, usa la lista de campos y la redacción de las respuestas e ignora el registro.
Cómo personalizar esta plantilla en Trupeer
Paso 1: Abre la sección de plantillas
Ve a la sección de Plantillas desde la navegación principal.
Paso 2: Selecciona y abre una plantilla
Haz clic en cualquier plantilla con la que quieras trabajar para abrirla.
Paso 3: Amplía la vista de la plantilla
Si es necesario, amplía la vista de la plantilla para ver el diseño completo y los detalles con claridad.
Paso 4: Edita la plantilla
Haz clic en Editar para empezar a modificar la plantilla seleccionada.
Dentro del editor, puedes:
Añadir secciones nuevas
Definir o actualizar reglas de formato
Añadir un logotipo y ajustar su posición y la configuración relacionada
Paso 5: Guarda tu plantilla personalizada
Después de realizar todos los cambios necesarios, haz clic en Guardar para almacenar la plantilla actualizada como tuya.
Paso 6: Previsualiza y ajusta la plantilla
Cuando quieras ver cómo se ve tu plantilla personalizada, abre la Previsualización.
Desde la pantalla de previsualización, puedes seguir haciendo ajustes directamente si es necesario, asegurándote de que la plantilla aparezca exactamente como la quieres.
Con una plantilla de ticket de cliente y resolución puedes:
Ahorra horas al redactar: omite la página en blanco con una estructura pensada para la documentación de tickets.
Estandariza la calidad del soporte: los campos integrados garantizan que cada ticket capture información clave.
Mantente alineado con la marca: aplica tu logotipo, tipografías y colores usando el kit de marca de Trupeer.
Crea una KB más sólida: los tickets resueltos se convierten en futuros artículos de ayuda y runbooks.
Detecta tendencias: los tickets estandarizados facilitan identificar problemas recurrentes.
Llega a equipos globales: traduce plantillas de tickets a 65+ idiomas con un solo clic.
Las dos mitades de una plantilla de ticket
El registro. Lo que se captura: quién, qué, cuándo, qué tan urgente, qué categoría, qué se solucionó. Esta mitad es invisible para el cliente y determina todo lo que podrás aprender después.
Las respuestas. Lo que recibe el cliente en cada fase: acuse de recibo, actualizaciones, aviso de escalado, resolución y seguimiento. Esta mitad es en la que te evalúan.
Los equipos suelen invertir en la segunda mitad y descuidan la primera, por eso el reporting del soporte tan a menudo produce gráficos de volumen y ninguna información. Ambas están en esta plantilla.
Los campos del formulario del ticket
Cada campo debe ganarse su lugar. Cada uno que añades ralentiza la entrada, y los campos que nadie usa se rellenan con basura.
Capturado en la entrada
Campo | Por qué existe |
|---|---|
ID del ticket | Referencia para todo lo que viene después |
Fecha y hora de creación | Inicia el reloj del SLA |
Canal | Email, teléfono, chat, portal, atención presencial. Te indica dónde llega realmente la demanda |
Nombre del solicitante y contacto | A quién responder |
Cuenta u organización | Agrupa los tickets por cliente, donde aparecen los patrones |
Producto, servicio o sistema | Lo que no funciona |
Categoría | Ver abajo. El campo más importante |
Descripción | En palabras del cliente, sin parafrasear |
Prioridad | Derivada del impacto y la urgencia, no elegida libremente |
Asignado a | Un nombre, nunca un equipo |
Estado | Abierto, en progreso, en espera del cliente, resuelto, cerrado |
Capturado al cierre
Campo | Por qué existe |
|---|---|
Código de resolución | Lo que realmente lo solucionó. Ver abajo |
Notas de resolución | Lo suficiente para que la siguiente persona pueda repetirlo |
Causa raíz | Donde se conoce. Opcional por ticket, esencial en conjunto |
Tiempo hasta la primera respuesta | Medido, no estimado |
Tiempo hasta la resolución | Excluyendo el tiempo de espera del cliente |
Reabierto | Sí o no. Un ticket reabierto no se resolvió |
Artículo de conocimiento creado o actualizado | El campo que se multiplica |
Confirmación del cliente | ¿Estuvieron de acuerdo en que se solucionó? |
Estos dos últimos campos de entrada y de artículo de conocimiento son los más comúnmente ausentes, y ambos son los que marcan la diferencia entre una cola y un sistema que mejora.
Categorización que realmente funciona
La categoría es el campo que decide si los datos de tu ticket valen algo, y casi siempre está mal.
Dos niveles, no cuatro. Categoría y subcategoría. Las jerarquías más profundas producen etiquetado inconsistente, porque los agentes dejan de leer más allá del segundo desplegable.
Entre ocho y quince categorías principales. Menos y todo es Otros. Más y nadie puede encontrar la correcta.
Nombrar categorías según lo que vivió el cliente, no según la estructura interna del equipo. "No puedo iniciar sesión" en lugar de "Plataforma de identidad".
Sin Otros. O si necesitas uno, revísalo mensualmente y convierte los elementos recurrentes en categorías reales. Un grupo de Otros por encima del cinco por ciento significa que tu taxonomía está mal.
Catálogo en el primer contacto, y deja que el agente lo cambie al cierre si resulta ser otra cosa. La categorización retrospectiva siempre se hace con prisa y siempre sale mal.
Revisa la taxonomía trimestralmente. Las categorías se quedan obsoletas a medida que cambia el producto.
Un conjunto inicial viable para la mayoría de equipos de soporte: acceso e inicio de sesión, facturación y pagos, configuración y puesta en marcha, cómo lo hago, no funciona como se esperaba, problema de datos, integración, rendimiento, solicitud de función, error, cambio de cuenta, cancelación.
Códigos de resolución
El equivalente del lado del cierre, y aún más a menudo descuidado. Las notas de resolución escritas como texto libre no se pueden contar.
Código | Significa | Lo que te indica |
|---|---|---|
Corregido por soporte | El agente lo resolvió directamente | Resolución normal |
Corregido por ingeniería | Requirió un cambio de código o configuración | Volumen de defectos del producto |
Error del usuario o malentendido | El producto funcionó, pero no coincidió con la expectativa | Brecha de documentación o de UX |
Se proporcionó documentación | La respuesta ya existía | Problema de localización, no de conocimiento |
Se proporcionó un workaround | El problema subyacente sigue existiendo | Backlog oculto. Vigila este |
Duplicado | El mismo problema que otro ticket | Influye el volumen si no se controla |
No se encontró ningún fallo | No se pudo reproducir | Necesita un umbral antes de convertirse en un patrón |
Retirado por el cliente | Se resolvió por sí solo o ya no era necesario | A menudo significa respuesta lenta |
Fuera de alcance | No es algo que tú soportes | Comprueba si debería serlo |
Dos de esos códigos son oro para el diagnóstico. Un alto índice de documentación proporcionada significa que tu contenido existe y no se puede encontrar. Un alto índice de workaround proporcionado significa que estás acumulando problemas no resueltos que volverán.
Prioridad y cómo establecerla
La prioridad debe derivarse, no elegirse. Si los agentes pueden seleccionarla libremente, marcarán todo como alto, porque cada cliente es urgente para sí mismo.
Baja urgencia | Urgencia media | Alta urgencia | |
|---|---|---|---|
Bajo impacto | P4 | P4 | P3 |
Impacto medio | P4 | P3 | P2 |
Alto impacto | P3 | P2 | P1 |
El impacto es cuántas personas se ven afectadas y qué tan mal. Un usuario con molestias es bajo. Un equipo entero bloqueado es alto.
La urgencia es qué tan rápido debe resolverse. Un problema cosmético es bajo, independientemente de cuántas personas lo vean. Un plazo bloqueado es alto.
Publica la matriz y los objetivos de respuesta para cada nivel, para que la prioridad sea un cálculo y no una negociación.
El ciclo de vida del ticket
Fase | Qué ocurre | Qué recibe el cliente |
|---|---|---|
Creado | Se crea el ticket, se categoriza y se prioriza | Acuse de recibo con referencia y tiempo estimado |
Asignado | Se nombra un responsable | Nada, a menos que cambie el responsable |
En progreso | Se está trabajando | Actualización si se supera el plazo prometido |
En espera del cliente | Bloqueado hasta recibir información | Solicitud clara, más una ventana de auto-cierre indicada |
Escalado | Se pasa según la matriz | Aviso de quién lo gestionará ahora y cuándo responderá |
Resuelto | Se aplica la solución y se espera confirmación | Mensaje de resolución que describe lo que se hizo |
Cerrado | Confirmación del cliente o auto-cierre transcurrido | Encuesta opcional de satisfacción |
Reabierto | El problema reapareció o no se solucionó | Acuse de recibo de que no se resolvió |
El estado de espera del cliente necesita una ventana de auto-cierre definida, normalmente de cinco a diez días laborables con un recordatorio antes. Sin ella, los tickets permanecen abiertos para siempre y las métricas de tiempo de resolución dejan de tener sentido.
Plantillas de respuesta por fase
La redacción que realmente ven los clientes. Mantén cada respuesta breve y sustituye los marcadores por valores reales en lugar de dejarlos genéricos.
Acuse de recibo
Gracias por ponerte en contacto. Tu referencia es [ID] y ahora mismo estoy revisándolo. Te responderé antes de [time] con una actualización, incluso si para entonces no tengo una respuesta completa.
La última cláusula importa. Prometer una actualización en lugar de una resolución es una promesa que puedes cumplir.
Actualización de estado
Una actualización rápida sobre [ID]. He [what you have done] y ahora estoy [what is next]. Espero tener esto resuelto antes de [time]. No necesitas hacer nada en esta fase.
Envíala antes de que el cliente reclame. Una actualización sin que te la pidan vale más que una respuesta rápida a una reclamación.
Solicitud de información
Para avanzar necesito [specific thing]. Una vez lo tenga, debería poder [outcome]. Si no recibo respuesta antes de [date], cerraré el ticket y podrás responder en cualquier momento para reabrirlo.
Pide una sola cosa. Tres solicitudes en un mismo mensaje producen de forma fiable una sola respuesta.
Aviso de escalado
He escalado este caso a [name or team] porque [reason]. Se pondrán en contacto contigo antes de [time]. Tu referencia no ha cambiado en [ID] y me mantendré en copia.
Di el motivo. El escalado sin motivo se lee como si te lo hubieran pasado de un lado a otro.
Resolución
Ahora está resuelto. La causa fue [cause] y he [what you did]. Ahora deberías ver [expected outcome]. Si vuelve a ocurrir, responde a este mensaje y volverá directamente a mí.
Nombra la causa. "Ya está arreglado" deja a los clientes sin confianza en que se mantendrá resuelto.
Seguimiento de la resolución
Comprobando [ID] desde [date]. ¿Sigue funcionando todo como se espera? Si no, solo responde aquí.
Dos o tres días después, y solo para lo que fuera significativo o recurrente.
Interrupción o problema generalizado
Sabemos que [issue] está afectando a [scope] y estamos trabajando en ello ahora. Te actualizaré antes de [time] independientemente del progreso. No necesitas hacer nada.
Proactivo, para todos los afectados, antes de que te contacten.
Perdón tras un fallo del servicio
Tenías razón al crearlo y lo siento. [What went wrong], y eso es responsabilidad nuestra. He [action taken] y [what prevents recurrence]. Si hay algo más pendiente, dímelo y me encargo.
Específico, sin defensas, y explica qué evita que vuelva a ocurrir.
El informe de resolución
Para cualquier cosa significativa, el registro de cierre necesita algo más que una nota. La plantilla incluye un informe de resolución que cubre:
Referencia y fechas del ticket. Lo que informó el cliente, en sus palabras. Lo que estaba ocurriendo realmente, que a menudo es diferente. Causa raíz. Qué se hizo para solucionarlo. Si se utilizó un workaround y si el problema subyacente sigue existiendo. Tiempo hasta la primera respuesta y hasta la resolución. Si se repitió. Qué se cambió para evitar que vuelva a ocurrir, o una nota de que no se cambió nada. Artículo de conocimiento creado o actualizado.
Ese último par es lo que convierte un ticket resuelto en una mejora. La mayoría de las notas de cierre se quedan en lo que se hizo, lo que solo ayuda a la siguiente persona si encuentra el ticket.
Qué te permite hacer el dato del ticket
Suponiendo que los campos se rellenan correctamente:
Encuentra las cinco categorías principales por volumen y corrige la más grande. Normalmente, la mayor es un problema de documentación o de producto, no de soporte.
Compara el volumen con el código de resolución. Alto volumen con un código proporcionado por documentación es localización de contenido, no capacidad de soporte.
Observa la tasa de workaround, que es tu backlog oculto.
Revisa la tasa de reabertura por agente y por categoría. Las reaberturas altas significan que los tickets se están cerrando en lugar de resolverse.
Mira la mezcla de canales a lo largo del tiempo. El crecimiento del teléfono a menudo significa que el autoservicio se ha roto en algún punto.
Contrasta por cuenta. Un cliente que crea tickets en la misma categoría repetidamente es un problema de formación o de configuración, no mala suerte.
Registra la primera respuesta frente a la resolución por separado. Tienen causas distintas y soluciones distintas.
Nada de esto es posible sin una categorización disciplinada en la entrada, por eso ese campo recibe la mayor atención en esta plantilla.
Help desk, service desk y plantillas de tickets
Help desk | Service desk | Soporte al cliente | |
|---|---|---|---|
Sirve para | Personal interno, normalmente TI | Personal interno, catálogo de servicios más amplio | Clientes externos |
Enfoque | Solución de incidencias | Solicitudes, incidencias, cambios, problemas | Preguntas y problemas del producto |
Marco | Informal | A menudo alineado con ITIL | Varía |
Campos extra | Activo, dispositivo | Servicio, referencia de cambio, CI | Cuenta, suscripción, pedido |
La lista de campos y la redacción de las respuestas de esta página funcionan para los tres. Los service desks que siguen ITIL necesitarán añadir referencias de cambio y de problema, y la distinción entre incidencia y solicitud importa allí de una forma que no ocurre en el soporte al cliente.
Cómo configurarlo
Diseña las categorías primero, con las personas que las usarán. Ocho a quince, dos niveles, nombradas según lo que vivió el cliente.
Define los campos necesarios en la entrada, y mantén la lista corta. Cada campo ralentiza la primera respuesta.
Construye la matriz de prioridad y publícala con objetivos de respuesta.
Define los códigos de resolución antes del lanzamiento, no después de seis meses de texto libre.
Establece la ventana de auto-cierre para la espera del cliente.
Carga las plantillas de respuesta como respuestas preparadas y edita la redacción para que suene como tu equipo.
Entrena específicamente en categorización. Es el campo que más a menudo se hace mal y el que más importa.
Revisa el grupo de Otros mensualmente durante el primer trimestre.
Informa sobre categorías y códigos de resolución, no solo sobre volumen.
Vuelve a revisar la taxonomía trimestralmente.
Buenas prácticas
Catálogo en el primer contacto y corrige al cierre.
Mantén los campos de entrada obligatorios al mínimo que haga que el ticket sea gestionable.
Deriva la prioridad del impacto y la urgencia en lugar de dejar que los agentes la elijan.
Usa códigos de resolución, no texto libre, para todo lo que quieras contar.
Promete una actualización en lugar de una resolución.
Envía actualizaciones antes de que el cliente reclame.
Indica la causa en el mensaje de resolución.
Establece una ventana de auto-cierre para la espera del cliente.
Registra si se creó un artículo de conocimiento.
Informa por categoría y código de resolución.
Errores comunes
Una categoría de Otros que absorbe un tercio de los tickets.
Jerarquías de categorías de cuatro niveles que los agentes dejan de leer.
Categorías nombradas según equipos internos en lugar de síntomas del cliente.
Prioridad elegida libremente, así que todo es alto.
Notas de resolución en texto libre sin nada que se pueda contar.
Sin seguimiento de workaround, así que los problemas no resueltos desaparecen.
Espera del cliente sin auto-cierre, lo que infla indefinidamente el número de tickets abiertos.
Mensajes de resolución que dicen "corregido" sin decir qué estaba mal.
Sin seguimiento de problemas significativos.
Reporting solo de volumen, que muestra lo ocupado que estás y nada sobre el porqué.
Categorización retrospectiva al final del mes.
Convierte los tickets resueltos en cosas que los clientes pueden resolver por sí mismos
Abre la plantilla en Trupeer AI, aplica tu kit de marca para que todo lo orientado al cliente coincida y edita cualquier sección directamente. La configuración está en la guía de la plantilla.
Vuelve a mirar la tabla de códigos de resolución. Si se proporcionó documentación, significa que la respuesta existía y no se pudo encontrar. Si se corrigió por soporte, repetidamente, en la misma categoría, significa que la respuesta aún no existe. Ambos son problemas de contenido que aparecen como volumen de soporte, y ambos se solucionan de la misma manera.
Cuando un agente resuelva algo por cuarta vez, regístralo una vez. Trupeer AI genera el artículo escrito y una visita guiada en vídeo narrada a partir del mismo proceso, para que el siguiente cliente pueda ver la solución en lugar de crear un ticket. Tradúcelo a 65+ idiomas y mantén el conjunto en tu base de conocimiento para que se pueda encontrar en el momento en que alguien se quede atascado. Usa las mismas grabaciones para formación de agentes.
Regístralo. Ponle marca. Tradúcelo. Trupeer it.
Preguntas frecuentes
¿Hay una plantilla gratuita de sistema de tickets?
Sí. La versión de Excel funciona como un registro completo de tickets para equipos pequeños sin una herramienta de helpdesk, con categorías, prioridad, códigos de resolución y pestañas de reporting. Si ya tienes un sistema de helpdesk, toma la lista de campos y las plantillas de respuesta e ignora el registro.
¿Hay una plantilla de ticket de help desk en Word?
Sí. El archivo de Word contiene el formulario de entrada del ticket, el informe de resolución y todas las plantillas de respuesta, para que puedas imprimir el formulario o copiar la redacción en tus respuestas preparadas del helpdesk.
¿Hay una plantilla de ticket de servicio en Excel?
Sí, y Excel es la versión que la mayoría de equipos considera más útil. Una fila por ticket con campos de entrada y cierre, desplegables para categoría, prioridad y código de resolución, además de pestañas que resumen el volumen por categoría y tipo de resolución.
¿Hay una plantilla de ticket de servicio en Word?
Sí. La versión de Word incluye un ticket de servicio imprimible adecuado para servicio de campo o soporte presencial, con líneas de firma para el trabajo completado y la aceptación del cliente.
¿Hay una plantilla de formulario de ticket de servicio de TI?
Sí. La versión de TI del formulario de entrada añade una referencia de activo o dispositivo, el sistema afectado y un campo de referencia de cambio para service desks que ejecutan un proceso formal de cambios.
¿Hay una plantilla HTML o Bootstrap gratuita para un sistema de tickets de soporte?
No, y merece la pena ser directo al respecto. Estas consultas son para código de front-end para crear una interfaz de tickets, que es un recurso de desarrollo web y no un documento. Busca un tema de panel de administración de Bootstrap o usa una plataforma de helpdesk existente, ya que crear un sistema de tickets a partir de una plantilla suele ser más caro de lo que parece una vez que tienes en cuenta la autenticación, el enrutado de email y la lógica del SLA. Lo que ofrece esta página es el diseño de los campos y la redacción de las respuestas, que necesitarías independientemente de la interfaz que se construya.
¿Qué es una plantilla de resolución de tickets?
Dos cosas según el contexto. El mensaje de resolución enviado al cliente explicando qué estaba mal y qué se hizo, y el registro de resolución capturado internamente con el código de resolución, la causa raíz y el tiempo hasta resolver. Ambas cosas se incluyen aquí, y la segunda es la que hace que los datos del ticket sean utilizables.
¿Qué campos debe tener un ticket de soporte?
En la entrada: ID del ticket, fecha, canal, solicitante, cuenta, producto o servicio, categoría, descripción en palabras del cliente, prioridad, responsable y estado. Al cierre: código de resolución, notas de resolución, causa raíz cuando se conoce, tiempos de respuesta y resolución, si se reabrió y si se creó un artículo de conocimiento.
¿Cómo se deben categorizar los tickets de soporte?
Dos niveles, entre ocho y quince categorías principales, nombradas según lo que vivió el cliente en lugar de según la estructura interna del equipo. Categoriza en el primer contacto y permite corregir al cierre. Evita el grupo de Otros o revísalo mensualmente y promociona los elementos recurrentes a categorías reales.
¿Qué son los códigos de resolución y por qué importan?
Un conjunto fijo de valores que describen cómo se resolvió un ticket: corregido por soporte, corregido por ingeniería, documentación proporcionada, workaround proporcionado, error del usuario, duplicado, no se encontró ningún fallo. Importan porque las notas de resolución en texto libre no se pueden contar, y dos de esos códigos en particular te indican dónde están tus problemas reales.
¿Cómo se establece la prioridad de un ticket?
Derívala del impacto y la urgencia usando una matriz publicada en lugar de dejar que los agentes la elijan libremente. El impacto es cuántas personas se ven afectadas y qué tan mal. La urgencia es qué tan rápido debe resolverse. Publica la matriz con objetivos de respuesta para que la prioridad sea un cálculo y no una negociación.
¿Qué debería decir un mensaje de resolución de ticket?
Cuál fue la causa, qué hiciste, qué debería ver ahora el cliente y cómo volver a contactar contigo si vuelve a ocurrir. Nombrar la causa es la parte que más a menudo se omite, y es lo que da confianza al cliente de que la solución se mantendrá.
¿Cuánto tiempo deberías esperar antes de cerrar un ticket?
Cinco a diez días laborables en espera del cliente, con un recordatorio antes de cerrar y una declaración clara de que responder lo reabrirá. Sin una ventana de auto-cierre, el número de tickets abiertos se infla indefinidamente y las métricas de tiempo de resolución dejan de tener sentido.
¿Puedo personalizar esta plantilla de ticket y resolución?
Sí, todas las versiones se pueden editar completamente. Las categorías y los códigos de resolución son las partes que deben ser tuyas, y se entregan como un conjunto inicial para editar en lugar de adoptarlo tal cual. En Trupeer AI también puedes aplicar tu kit de marca para que los mensajes y artículos orientados al cliente coincidan.
