El flujo
Después del go-live empieza la operación
Diagrama animado de esta etapa: Cuatro tipos de solicitud (duda, soporte, bug y mejora) llegan por un canal a tres actores: ChatGPT analiza, Claude Code ejecuta y el equipo humano aprueba datos y código.
Así trabajamos con un cliente en WITS.
Cuando un sistema ya está en producción, el trabajo no termina: cada día llegan dudas, solicitudes de soporte, errores y mejoras.
ChatGPT analiza cada solicitud. Claude Code ejecuta dentro de nuestras herramientas. Y el equipo humano aprueba lo que toca datos o código.
Todo entra por un canal, se clasifica, se resuelve por la ruta correcta y se responde con historial.
E0 · Canales de entrada
Todo lo que pide el cliente entra por un canal
Diagrama animado de esta etapa: Cuatro canales (correo con IMAP y SMTP, ticket de Zoho Desk, chat de Zoho Cliq y chatbot web con la API de OpenAI) se marcan como leídos y cada uno entrega un documento a Claude Code, que lo convierte en una solicitud.
Correo, con IMAP y SMTP. Tickets en Zoho Desk. Mensajes en Zoho Cliq. Y el chatbot del sistema web, que responde con OpenAI.
Claude Code lee cada canal y convierte el mensaje en una solicitud con contexto: quién pide, de qué empresa y qué pasó.
Nada se pierde entre el correo, el chat y el ticket.
E1 · Clasificación
Cada solicitud se clasifica antes de tocar nada
Diagrama animado de esta etapa: Conversación entre el cliente y el clasificador: el cliente reporta que el visor no abre los documentos de julio; el clasificador responde «soporte, empresa 214, estatus activo», confirma el pre-flight de doble candado y asigna la ruta de datos en AWS.
Aclaración, soporte, bug o mejora. ChatGPT interpreta el mensaje y propone la categoría y la ruta.
Antes de tocar nada corre el pre-flight de doble candado: la empresa correcta y el estatus activo.
La clasificación decide el camino. Una duda va al conocimiento del sistema. Un dato va a AWS. Un error o una mejora van a código y sprint.
E2 · Conocimiento del sistema
Respuestas con fuente y con permisos
Diagrama animado de esta etapa: Dos filas de nodos. Arriba: documentación del sistema, OpenAI con RAG y respuesta con fuente. Abajo: chatbot web, API de OpenAI y consulta de permisos. Un puente indica que el chatbot consulta permisos antes de responder.
La documentación del sistema es nuestro knowledge: manuales, reglas y decisiones.
OpenAI, con RAG sobre esos documentos, responde las aclaraciones citando la fuente.
El chatbot del sistema web usa la misma base por API, pero antes consulta permisos: solo responde lo que ese usuario puede ver. Así el cliente obtiene respuestas correctas, seguras y en segundos.
E3 · Datos en AWS
La evidencia sale de AWS
Diagrama animado de esta etapa: Dos filas de nodos. Arriba, la evidencia en AWS: Aurora, S3, CloudWatch y Nginx. Abajo, el cambio: réplica local marcada como probada, base productiva por SQL vía SSM, y equipo y cliente.
La base de datos Aurora. El bucket S3. Los logs de EC2 y CloudWatch. Y las peticiones que registra Nginx.
El cambio se prueba primero en una réplica local: se modifican o insertan registros y se verifica el resultado.
Solo entonces se aplica en la base productiva, por un canal controlado. Y se responde al equipo y al cliente.
E4 · Código y sprint
Errores y mejoras, del issue a producción
Diagrama animado de esta etapa: Dos filas de nodos. Arriba: GitHub, issue en Zoho Sprint y agente de desarrollo. Abajo: sandbox con pruebas automatizadas aprobadas, despliegue a productivo, y equipo y cliente.
Si la solicitud es un error o una mejora, se crea un issue en Zoho Sprint, ligado al código en GitHub.
Un agente de desarrollo lo resuelve: escribe el cambio y lo prueba. El cambio pasa por el sandbox, con pruebas automatizadas.
Y si todo está en verde, sube a productivo. El cliente recibe la respuesta con el cambio ya en línea.
E5 · Respuesta y bitácora
La respuesta sale por el mismo canal
Diagrama animado de esta etapa: Una respuesta con plantilla WITS se reparte a cuatro destinos: Zoho Desk (ticket resuelto), Zoho Cliq (equipo avisado), correo (enviado) y bitácora del cliente (registrado).
El ticket se contesta y se cierra en Zoho Desk. Se avisa al equipo por Cliq. Se envía el correo cuando aplica.
Y todo queda registrado en la bitácora del cliente.
Así, la siguiente solicitud ya tiene historial: qué pasó, quién lo resolvió y cómo.
Agentes y criterio humano
Seis agentes autónomos, humano cuando hace falta
Diagrama animado de esta etapa: Anillo de seis agentes conectados en ciclo (capturador, clasificador, knowledge, operador de datos, agente de desarrollo y respondedor) con el equipo humano al centro. A un lado, tres compuertas donde decide el humano: base productiva, despliegue y caso escalado.
En cada solicitud trabajan seis agentes: el capturador de canales, el clasificador, el consultor de conocimiento, el operador de datos, el agente de desarrollo y el respondedor.
Operan solos, de punta a punta.
El equipo humano entra cuando hace falta: un cambio en la base productiva, un despliegue, o un caso que el agente escala. Autonomía por defecto. Criterio humano cuando importa.
Cierre
Un canal. Una clasificación. Una ruta. Una respuesta.
Diagrama animado de esta etapa: Cuatro frases grandes (un canal, una clasificación, una ruta, una respuesta) junto a los tres actores: ChatGPT analiza, Claude Code ejecuta y el equipo humano decide sobre datos y código.
ChatGPT analiza. Claude Code ejecuta. Y el equipo humano decide sobre datos y código.
Así operamos con un cliente en WITS: con evidencia, con historial y sin perder ninguna solicitud.
Analicemos tu flujo
¿Quieres este flujo en tu empresa?
Diagrama animado de esta etapa: Tres formas de contacto (WhatsApp, correo de ventas y wits.mx) con un código QR de WhatsApp y las etiquetas «sin costo» y «sin compromiso».
Márcanos, escríbenos por WhatsApp o mándanos un correo. Analizamos tu operación sin costo y sin compromiso.