Del chat del cliente a la incidencia de Jira y de vuelta: un proceso de escalación de errores en el que confían soporte y desarrollo

Escalas un error y nadie te responde. El equipo de desarrollo se queja de que soporte le manda preguntas que nunca fueron errores. Luego se acumulan 3 incidencias de Jira para un solo fallo, y nadie puede decirle al cliente cuándo llega la solución.

Esta guía te da un proceso de 4 etapas con un traspaso claro en cada una, además de 5 preguntas de clasificación, una plantilla de informe de error y un mensaje para el día en que sale la corrección.

Cómo se pierde un error entre soporte y desarrollo

Una clienta escribe en el chat de tu sitio web: el PDF de la factura que exporta desde tu app para iPad se corta antes de la última página. Tu agente lo prueba, ve lo mismo y publica en el canal de desarrollo: “¿Exportar PDF falla en iPad?”. Alguien reacciona con un emoji.

En las 2 semanas siguientes, 4 clientes más lo reportan, 2 agentes abren 3 incidencias de Jira entre los dos y nadie en soporte sabe decir si viene una solución. Cuando por fin sale, los clientes se enteran al volver a probar.

Tray.ai, que vende software de automatización, describe ese final en su guía para escalar a desarrollo: “el cliente se entera igual por las notas de la versión, o preguntando”, porque “nadie se encargaba de avisarle”.

Desarrollo tiene la queja contraria. Zenatta, una consultora que implementa mesas de ayuda con Zoho, escribe en un caso de estudio de su sitio web que “un backlog de Jira lleno de preguntas de soporte que nunca fueron fallos se vuelve ruido que desarrollo aprende a ignorar”.

Cada una de las 4 etapas de abajo termina en un traspaso claro, y funcionan con cualquier mesa de ayuda que se conecte a Jira.

Etapa 1: demuestra que es un fallo antes de que lo vea desarrollo

Muchas escalaciones que molestan a los desarrolladores salen mal justo aquí: el cliente no encontró una opción o quiere algo que el producto nunca hizo.

El propio equipo de soporte de Atlassian tiene una regla simple en su política de corrección de errores de Cloud: “Intentaremos reproducir el error para comprobarlo y, si lo logramos, registraremos el reporte por ti”. Cópiala. Si nadie en soporte puede reproducir el problema, todavía no está listo para Jira.

5 preguntas antes de escalar

Antes de escalar, el agente responde 5 preguntas en el ticket:

1. ¿Puedo reproducirlo? ¿En qué dispositivo, navegador, versión de la app o cuenta?
2. ¿Es un comportamiento documentado, según el centro de ayuda o las notas de la versión?
3. ¿Ya está en Jira? Busca el texto del error y el nombre de la función.
4. ¿A quién le pasa? ¿A una cuenta, a un plan, a todos los que usan Android?
5. ¿Qué bloquea y hay una forma de sortearlo?

A dónde va cada reporte

Luego clasifica el reporte según lo que resulte ser:

La prioridad en los términos de desarrollo

Para la prioridad, usa la escala de desarrollo. Si no hay ninguna, toma prestada la de Atlassian:

• Prioridad 1 cuando “los usuarios no pueden hacer su trabajo y no hay ninguna forma de sortearlo”.
• Prioridad 3 cuando una función “no funciona como se espera, pero hay una forma de sortearlo”.

Soporte describe el impacto con esos términos, y desarrollo decide el orden del trabajo a partir de ahí.

Etapa 2: una incidencia de Jira por error, con cada ticket afectado vinculado

Busca en Jira antes de crear nada. Una segunda incidencia para el mismo fallo reparte los comentarios y el conteo de clientes en 2 lugares, y alguien tiene que cerrar una como duplicada.

La guía de Tray.ai resume la meta así: “Una incidencia por error, con cada ticket afectado vinculado a ella”. Esos vínculos también son tu argumento: la guía dice que el número de clientes y los ingresos que hay detrás “es lo que hace que se le dé prioridad a un error”.

Un informe de error con el que desarrollo puede trabajar

Un estudio que vale la pena conocer aquí es “What Makes a Good Bug Report?” de Zimmermann y sus colegas (IEEE Transactions on Software Engineering, 2010). Se basa en 466 respuestas de una encuesta a desarrolladores y personas que reportan errores en Apache, Eclipse y Mozilla.

• De los desarrolladores que habían usado pasos para reproducir, el 83% los puso entre los 3 elementos que más les ayudaron.
• De quienes se habían topado con reportes incompletos, el 74% lo nombró entre los 3 problemas que más retrasaron las correcciones.

Los elementos que los desarrolladores más valoraban eran también los más difíciles de dar para quien reporta. Soporte puede cerrar esa brecha, porque el agente todavía puede preguntarle al cliente mientras el chat sigue abierto.

Usa siempre las mismas secciones:

Deja los datos del cliente fuera de Jira

No pongas el nombre, la dirección de correo, el número de teléfono ni el número de pedido del cliente, salvo que un desarrollador necesite alguno para reproducir el error. Si tu mesa de ayuda pone en Jira un enlace al ticket con el título del ticket, nombra los tickets por el problema, nunca por el cliente.

Jira suele leerlo más gente que tu herramienta de soporte. Además, la copia que queda ahí está fuera del lugar donde gestionas las solicitudes de eliminación y de acceso.

Si te aplica el RGPD, esto también es su principio de minimización de datos del artículo 5(1)(c). El resumen de la Comisión Europea dice que los datos personales deben ser “adecuados, pertinentes y limitados a lo necesario para el fin”. Esto es información general, no asesoría legal.

Etapa 3: deja que el estado de Jira vuelva a soporte

Una vez creada la incidencia, soporte nunca debería tener que preguntar “¿hay novedades?” en un chat del equipo. El estado tiene que llegar al ticket por sí solo.

En Zendesk, esto requiere una post function agregada al flujo de trabajo de Jira. El artículo de ayuda de Zendesk describe el resultado: “Jira puede agregar automáticamente una nota interna al ticket vinculado de Zendesk para avisar al agente. Luego, el agente puede avisar al cliente”.

Uses lo que uses, pruébalo una vez con una incidencia de prueba.

Done no siempre significa publicado

Acuerda con desarrollo qué estado de Jira significa que los clientes ya tienen la corrección. En muchos equipos, Done significa fusionado o probado, y la versión sale días después.

Si tu flujo de trabajo tiene un estado Released o Deployed, ese es tu disparador para la etapa 4, y soporte necesita su nombre exacto. Done y Released suelen estar los dos en la categoría Done de Jira, así que una regla que solo mira la categoría no detecta el paso de Done a Released.

Lleva el conteo a la planificación

Una vez por semana, el responsable de soporte debería llevarle a desarrollo el número de tickets abiertos que esperan cada incidencia. En la planificación, “14 cuentas reportaron APP-482” llega más lejos que “los clientes siguen preguntando por esto”.

Etapa 4: avisa a cada cliente afectado cuando la corrección esté disponible

Espera a que la corrección esté en manos de los clientes y luego compruébala tú mismo con la configuración de la etapa 1.

Escríbeles a todos los que reportaron el error, incluidos los clientes que solo dijeron “a mí también”. Describe el problema con sus palabras y diles qué hacer ahora:

Hola, una actualización rápida sobre los PDF de facturas de la app para iPad que se cortaban antes de la última página. Lo corregimos en la versión 4.2.2, que ya está en el App Store.

Después de actualizar, exporta la factura de nuevo y estarán todas las páginas. Si algo sigue viéndose mal, responde aquí con una captura de pantalla.

La ventana de 24 horas de WhatsApp

Meta permite texto libre solo dentro de las 24 horas siguientes al último mensaje del cliente (la ventana de atención al cliente). Después, una empresa solo puede enviar mensajes con plantillas aprobadas.

La mayoría de las correcciones tardan más de un día, así que consigue que te aprueben una plantilla para anunciar correcciones antes de necesitarla.

Cómo llevar el proceso en Deskwoot

Deskwoot es nuestra mesa de ayuda, y lleva las etapas 2 a 4 desde el ticket: la tarea interna que tu equipo separa de un chat con un cliente (consulta cómo crear un ticket desde un chat). El cliente nunca ve el ticket ni la incidencia de Jira.

Un informe de error redactado desde el chat

Redactar informe de error con Copilot escribe el título y la descripción a partir del ticket, su chat y los comentarios de tu equipo. Copilot lee el chat con “nombre oculto” en lugar del nombre del cliente y tiene la instrucción de dejar fuera los datos de contacto y los números de pedido, salvo que un desarrollador necesite alguno.

Nada llega a Jira hasta que el agente revisa el borrador y hace clic en Crear incidencia, y la incidencia sale con su propia cuenta de Atlassian. Cada borrador cuenta para tus conversaciones de IA.

Líneas de estado y 2 reglas listas

Cada cambio de estado en Jira escribe una línea en cada ticket vinculado, por ejemplo “La incidencia de Jira APP-482 pasó a In Progress”. Si buscas APP-482 en la lista de tickets, encuentras cada ticket vinculado para tu conteo semanal.

La página de configuración de Jira ofrece 2 reglas listas para revisar y guardar:

Si en tu Jira Done llega antes de la publicación, cambia las condiciones de categoría de la segunda regla por el nombre del estado, por ejemplo El estado de la incidencia es Released. El artículo de ayuda de Jira tiene los detalles.

Una sola actualización para todos los clientes afectados

Con 2 o 3 clientes afectados, usa Responder al cliente en cada ticket. Con más, usa un ticket colectivo, un ticket sin cliente para un problema que comparten muchos clientes, y vincúlale los chats afectados, los tickets y la incidencia de Jira.

Cuando la corrección esté disponible, Actualizar clientes vinculados envía tu texto a cada cliente en su propio chat, hasta 500 clientes a la vez. En el mismo paso puede resolver los chats y tickets vinculados.

Las actualizaciones de un ticket colectivo nunca se envían como plantillas de WhatsApp. En una bandeja de entrada de WhatsApp Cloud API, abre los chats que están fuera de la ventana de 24 horas y envía una plantilla aprobada desde el cuadro de respuesta.

Cuánto cuesta y por dónde empezar

Los tickets, los tickets colectivos y la integración con Jira vienen con el plan Enterprise: $12 por agente al mes, o $9.60 si pagas al año (precios).

Empieza poco a poco:

1. Conecta Jira.
2. Crea un estado de ticket para el trabajo que espera a desarrollo.
3. Guarda las 2 reglas listas.

El próximo error que llegue por el chat será tu prueba. Crea tu cuenta y tu nuevo espacio de trabajo tendrá 7 días de Enterprise sin tarjeta de crédito, para hasta 30 puestos, incluido el tuyo.

Cuando terminen los 7 días, eliges un plan o sigues trabajando con el plan gratis Hacker para 1 agente.