Saltar al contenido

Automatización · Atención y agendamiento

Registrar en GitHub el error que reporta un cliente por WhatsApp y avisarle en qué versión salió el arreglo

Un agente de IA registra en GitHub el error que reporta un cliente, evita duplicados y le avisa en qué versión publicada salió el arreglo.

¿Cómo le aviso a un cliente por WhatsApp en qué versión de mi app quedó arreglado su error?

Cuando un cliente reporta por WhatsApp un error en tu app o tu sitio, el Met busca en el repositorio si ya hay un issue con ese problema. Si existe, le agrega un comentario con el nuevo reporte; si no, crea el issue con lo que contó el cliente y le da el número. Cuando el cliente vuelve a preguntar, el Met lee el issue: si sigue abierto, se lo dice; si se cerró, revisa el pull request que lo cerró, busca en las notas de las versiones publicadas cuál incluye ese cambio y le responde en qué versión salió, o que el arreglo todavía no se publica.

Qué la pone en marcha

Cuando el cliente escribe

Empieza cuando un cliente escribe por WhatsApp para reportar un error o preguntar si ya lo arreglaron. No hay un trigger que configurar: el Met asignado a la línea lo resuelve en esa conversación.

No hace falta programar nada: el Met asignado al canal recibe la conversación y ejecuta el procedimiento dentro de ella.

Quién la ejecuta

Met de soporte que sigue errores en GitHub

Área de Atención al cliente

No tiene un nombre propio sembrado. Es el Met que ya atiende el WhatsApp del negocio, con GitHub conectado: termina cuando el cliente tiene el número de su reporte o sabe en qué versión salió el arreglo.

Lo ejecuta el Met de atención al cliente

Canales: WhatsApp

Qué hay que tener conectado

5 pasos · 7 herramientas

El procedimiento, paso a paso

Cada paso muestra la herramienta que se ejecuta. Son las del conector real: si una dejara de existir, esta página no compilaría.

  1. 1

    Buscar si el error ya está reportado

    El Met busca en el repositorio de la app, con una consulta en lenguaje natural, issues que describan el mismo error. Si encuentra uno, le agrega un comentario con el nuevo reporte.

  2. 2

    Crear el issue

    Si no hay uno parecido, el Met crea el issue con un título claro, la descripción del cliente y los pasos que contó, y le manda al cliente el número del issue por WhatsApp.

  3. 3

    Revisar el estado del issue

    Cuando el cliente pregunta si ya está arreglado, el Met lee el issue. Si sigue abierto, le dice que el equipo aún trabaja en eso; si está cerrado, mira qué pull request lo cerró.

  4. 4

    Ver cuándo entró el arreglo

    El Met abre ese pull request y revisa su detalle para saber si ya se fusionó y en qué fecha, antes de buscar la versión que lo incluye.

  5. 5

    Encontrar la versión publicada

    El Met trae la última versión publicada y lista las anteriores, y busca en sus notas el número del issue o del pull request. Le responde al cliente en qué versión salió el arreglo, o que todavía no está en ninguna versión publicada.

Antes de empezar

Qué necesitas tener listo

Ninguno de estos puntos lo resuelve el Met. Si falta uno, la automatización se detiene ahí.

Los límites

Qué NO resuelve esta automatización

Preferimos decirlo aquí que descubrirlo en la implementación.

Preguntas frecuentes

Preguntas sobre esta automatización

El Met igual puede decir si el issue está abierto o cerrado y si el pull request ya se fusionó. Lo que no puede es nombrar la versión, porque no existe en GitHub.

Solo si el repositorio es público. En un repositorio privado, el cliente se entera de todo por WhatsApp y nunca necesita una cuenta de GitHub.

El Met encuentra el issue existente y le agrega un comentario por cada reporte nuevo, así tu equipo ve cuántas personas tienen el problema sin issues duplicados.

Sigue por aquí

Otras automatizaciones con las mismas herramientas

¿Quieres esta automatización corriendo con tus datos?

Te la mostramos con tus cuentas conectadas, no con una demostración enlatada.