Linear para atención al cliente: convierte tickets en reportes de bugs y avisa a los clientes cuando esté corregido

Un cliente reporta un bug el lunes. Tu agente lo publica en el canal de los desarrolladores, alguien abre un issue en Linear y el ticket se queda estancado. Para el viernes, 20 clientes más ya reportaron el mismo bug.

La corrección salió el miércoles y nadie les avisó. Esta guía muestra cómo pasar bugs a Linear, mantener los duplicados en un solo issue y avisar a los clientes cuando la corrección ya esté disponible.

En resumen

• Busca antes de crear. Primero busca un issue que ya exista en Linear, por su clave o por palabras del título.
• Escribe el reporte para un desarrollador. Pasos para reproducirlo, resultado esperado y real, entorno, impacto. Nada de nombres ni datos de contacto de clientes.
• Un bug, un issue, muchos tickets. Cada ticket sobre el mismo bug se vincula al mismo issue. La cantidad de tickets vinculados le dice a ingeniería qué tan grande es.
• Deja que el estado vuelva al ticket. Los agentes no deberían tener que revisar Linear ni pegar actualizaciones a mano.
• Avisa al cliente cuando la corrección ya esté disponible. Done en Linear y disponible para tus clientes pueden ser 2 días distintos.

Deskwoot, la mesa de ayuda que creamos, se encarga de los vínculos y del estado con su integración con Linear. Todo lo demás de esta guía funciona con las herramientas que ya usas.

Por qué los bugs se pierden entre la mesa de ayuda y Linear

Soporte vive en la mesa de ayuda e ingeniería vive en Linear. Un reporte de bug pasa de un lado al otro una sola vez, y después los 2 registros se van separando.

Nadie se encarga del camino de vuelta

El agente que creó el issue sigue con los próximos 40 tickets. El desarrollador cierra el issue y también sigue adelante. Si nada lleva el estado de vuelta al ticket, el cliente se entera cuando lo intenta de nuevo.

Linear cuenta cómo su propio equipo de soporte evita esto en un artículo sobre cómo trabaja su equipo de Customer Experience en Linear. Cuando un issue se marca como Done, la conversación de soporte vinculada se vuelve a abrir con una nota, y el equipo de soporte contacta al cliente para contarle de la corrección y confirmar que funciona.

Actualizar el estado a mano

Sin un vínculo, alguien de soporte abre Linear cada mañana, revisa una lista de issues y pega el estado en los tickets. Toma tiempo, se salta en los días con mucho trabajo y por la tarde ya está desactualizado.

El mismo bug, 20 veces

Cuando los agentes no ven lo que ingeniería ya sabe, cada uno crea su propio issue. Luego los desarrolladores pierden tiempo uniendo duplicados, y el tamaño real del problema queda escondido en 5 issues que muestran 1 o 2 reportes cada uno.

Antes de crear un issue

No todo ticket que dice “no funciona” es un bug. Ingeniería deja de confiar muy rápido en los reportes de soporte si la mitad resultan ser preguntas sobre cómo funciona algo.

3 preguntas para hacerte primero

1. ¿Puedes reproducirlo? Pruébalo tú mismo, con el mismo plan, navegador o versión de la app que usa el cliente.
2. ¿Así es como debe funcionar? Revisa tu centro de ayuda y la documentación del producto. Si ese comportamiento está documentado, es una pregunta sobre la función, y quizá el cliente necesita una mejor explicación.
3. ¿Ya existe un issue? Busca en Linear con las palabras que un desarrollador usaría en un título, como “exportación” o “CSV”, y por la pantalla donde pasa.

Si la tercera respuesta es sí, vincula el ticket a ese issue y agrega lo nuevo como comentario. Crea un issue nuevo solo cuando nada coincida.

Qué hace que un reporte de bug sirva a los desarrolladores

Las pautas de Mozilla para escribir reportes de bugs se escribieron para Firefox, y sirven para cualquier equipo de software. El resumen debe explicar el problema, no la corrección que tú sugieres, y el reporte debe separar los hechos de las suposiciones.

Una plantilla que tus agentes pueden copiar

• Título: qué falla y dónde. “La exportación CSV pierde la última fila cuando hay un filtro” es mejor que “Exportación rota”.
• Pasos para reproducirlo: numerados, lo más cortos posible, y si pasa siempre o solo a veces.
• Resultado esperado: lo que debía pasar.
• Resultado real: lo que pasó de verdad, con el texto exacto del error o una captura de pantalla.
• Entorno: plan, navegador o versión de la app, dispositivo y la hora en que pasó, para que los desarrolladores lo encuentren en los registros.
• Impacto: cuántos clientes lo reportaron, si están bloqueados y cualquier solución temporal que encontraste.
• Lo que soporte ya probó: borrar la caché, otro navegador, otra cuenta.

En el propio artículo de CX de Linear, los bugs que su equipo de soporte registra desde Slack llevan las palabras exactas del cliente y un enlace a la conversación original. Agrega las dos cosas a tus reportes también. La cita muestra a los desarrolladores lo que vio el cliente, con sus propias palabras.

Deja fuera los datos personales

Todo lo que pegas en Linear se queda en Linear. Cuando más adelante un cliente te pide borrar sus datos, tu mesa de ayuda no puede llegar a esa copia.

Así que escribe “un cliente del plan anual” en lugar de un nombre, y deja fuera correos, teléfonos y números de pedido que los desarrolladores no necesitan. Si tienen que revisar la cuenta, pueden seguir el enlace de vuelta al ticket.

Un bug, un issue, muchos tickets

El hábito más útil de toda esta guía: cada ticket sobre el mismo bug se vincula al mismo issue de Linear. Los desarrolladores tienen un solo lugar donde trabajar, y tú tienes un solo lugar donde mirar cuando llega la corrección.

Que hablen los números

Un issue con 20 tickets vinculados se defiende solo en una reunión de planificación. Pide a los agentes que dejen un comentario corto en el issue cuando un reporte nuevo aporte algo nuevo, como otro navegador o un cliente totalmente bloqueado.

Evita los comentarios que solo dicen “+1”. El ticket vinculado ya cuenta.

Duplicados que se cuelan de todos modos

Algunos se van a colar. En Linear, un desarrollador marca un issue como duplicado del otro. Desde mayo de 2026, eso le da al issue su propio estado Duplicate, y Linear pasa sus archivos adjuntos y las solicitudes de clientes al original, como explica el changelog de Linear.

Cuando veas que el issue de un ticket pasa a Duplicate, vincula ese ticket también al issue original. Si no, el ticket sigue a un issue en el que nadie volverá a trabajar.

Dónde llegan los reportes nuevos en Linear

Un equipo de Linear puede activar Triage, una bandeja de entrada especial para ese equipo. Los issues creados por una integración, o por alguien de fuera del equipo, llegan primero ahí. Alguien del equipo acepta, rechaza, marca como duplicado o pospone cada uno.

Pregunta a tus desarrolladores si usan Triage y quién la revisa. Un reporte limpio, con el impacto arriba, se acepta más rápido.

Clientes informados sin pegar actualizaciones

Los clientes no necesitan cada cambio de estado. Necesitan saber que confirmaste el bug, que alguien está trabajando en él y que les vas a escribir cuando esté corregido.

Une los estados de Linear con lo que hace el ticket

Los estados predeterminados de Linear son Backlog, Todo, In Progress, Done y Canceled, y cada equipo puede agregar los suyos. Una correspondencia sencilla para el lado del ticket:

• Triage, Backlog o Todo: el ticket espera a desarrollo. Pausa su reloj de SLA, para que no se incumpla mientras ingeniería trabaja.
• In Progress: todavía no hay nada que contarle al cliente.
• Done: el ticket vuelve a un agente, que revisa que la corrección ya esté disponible.
• Canceled o Won't fix: el agente escribe una respuesta honesta, con una solución temporal si existe.
• Duplicate: vincula el ticket al issue original y sigue esperando.

Done no siempre significa disponible

Linear lo dice sin rodeos en su documentación de Releases: que un issue esté en Done no siempre significa que la corrección ya llegó a tus clientes. El pull request puede seguir en staging, o una corrección para el celular puede esperar la próxima versión de la app.

Así que quien recibe el ticket de vuelta revisa la corrección en producción, o le pregunta al desarrollador, antes de escribirle al cliente.

Cuánto podrían esperar los clientes

Pide a tus desarrolladores sus metas y compártelas con tu equipo. Linear publica las suyas en un artículo sobre su política de cero bugs: 48 horas para los bugs de alta prioridad y 7 días para el resto.

Los números de tu equipo serán otros. Ayudan a los agentes a dar expectativas honestas, pero una meta no es una fecha para darle a un cliente.

El mensaje cuando confirmas el bug

“Gracias por la descripción tan clara. Pudimos reproducirlo y nuestros desarrolladores ya lo tienen en su lista. Te escribo por aquí en cuanto la corrección esté disponible, así no tienes que estar revisando.”

Da una fecha solo cuando tus desarrolladores se hayan comprometido con una. Una fecha que no se cumple cuesta más confianza que no dar ninguna.

El mensaje el día de la corrección

“Buenas noticias: desde esta mañana, la exportación CSV vuelve a incluir todas las filas, también con filtros. ¿Podrías probar una vez más y contarme si te funciona? Gracias por reportarlo, tu descripción nos ayudó a encontrarlo rápido.”

Nombra el problema que reportó el cliente y pídele que lo confirme. Una respuesta de “ya funciona” cierra el ticket de verdad.

Cómo funciona en Deskwoot

Deskwoot es la mesa de ayuda que creamos. Con Linear conectado, los agentes crean o vinculan issues desde el ticket, y el estado del issue vuelve solo al ticket.

Configúralo

1. Activa los tickets en Configuración > Tickets. Los tickets y Linear vienen con el plan Enterprise.
2. Haz clic en Conectar Linear en Configuración > Integraciones > Linear. Necesitas el permiso Gestionar integraciones.
3. Un administrador del espacio de trabajo de Linear autoriza a Deskwoot y elige los equipos que puede ver. Después elige el Equipo para issues nuevos.

Los agentes no necesitan una cuenta de Linear, porque Deskwoot se une como app. La guía de ayuda de Linear muestra cada paso.

Lo que reciben tus agentes

• Crear o vincular desde el ticket. Vincula un issue por su clave, como ENG-123, o haz clic en Crear issue. Redactar reporte de bug con Copilot escribe el reporte. Copilot tiene la instrucción de dejar fuera el nombre y los datos de contacto del cliente, y el agente lo revisa.
• El estado en el ticket. Cada cambio de estado escribe una línea en cada ticket vinculado. Una búsqueda por la clave encuentra todos los tickets vinculados: tu lista para el día de la corrección.
• 2 reglas listas. Una define un estado del ticket cuando se crea o se vincula un issue, por ejemplo un estado que pausa el SLA. La otra devuelve el ticket con una nota a quien vinculó el issue una vez que está terminado.
• Bugs conocidos. Cuando un cliente reporta un problema, Copilot busca entre los issues abiertos del equipo para issues nuevos y de los equipos a los que se vinculan tus tickets. Tiene la instrucción de dar una fecha de corrección solo cuando el issue tiene una que todavía no llegó.

Los clientes nunca ven el issue ni sus líneas de estado.

Cuánto cuesta

Enterprise cuesta $12 por agente al mes, o $9.60 con facturación anual, así que 10 agentes pagan $120 al mes. Conectar Linear no cuesta nada extra (consulta los precios). Hacker, Startup y Business no lo incluyen, y cada espacio de trabajo de Deskwoot conecta un espacio de trabajo de Linear.

Pruébalo con un bug

Elige el bug abierto con más tickets detrás. Crea tu cuenta, conecta Linear, vincula esos tickets a su issue y guarda la regla lista para issues terminados. La prueba gratis de 7 días de Enterprise no pide tarjeta, cubre hasta 30 puestos, incluido el tuyo, e incluye Linear.