GTM: la plataforma de garantías, del correo al cierre

No es un CRM ni un Excel bonito. Es la interfaz humana de un sistema donde los agentes ejecutan el proceso y las personas entran cuando algo depende del mundo físico: ¿llegó el equipo?, ¿pasó la revisión?

GTM presta el servicio técnico y de garantía de marcas de celulares en Colombia. Las tiendas y los clientes pedían la recolección de los equipos por correo, y toda la operación se llevaba a mano en una hoja de cálculo compartida, sin trazabilidad ni alertas. Había correos que se respondían tarde o nunca, penalizaciones de la marca por incumplir el plazo de 30 días, y todo dependía de que una persona alcanzara a contestar.

Diseñé y construí la plataforma de punta a punta como design engineer: la arquitectura, la ingesta de correo, el agente de IA, la máquina de estados, la base de datos, la aplicación y el despliegue. Trabajé con agentes de IA y con una desarrolladora de frontend y QA, y del lado de GTM con la administración, la supervisión y la operación. Tomó unas siete semanas.

Del correo al ticket

Un caso puede entrar por tres puertas: el formulario web de cada marca, que es el camino preferente porque llega con los datos completos; el correo al buzón de la sede; o el mostrador, cuando alguien trae el equipo en persona. Todas terminan en el mismo ticket.

La bandeja muestra el correo que acaba de llegar, con el hilo completo a un lado. Sobre cada correo nuevo, el agente decide una de cuatro cosas: crear el ticket, anexarlo a un hilo que ya tiene caso, descartarlo por una regla o marcarlo para que lo revise una persona.

Las reglas del ticket son pocas y firmes. Un correo es un ticket y un ticket es un equipo: las respuestas se anexan al mismo caso, y si alguien manda varios equipos en un correo se le pide uno por caso. El IMEI se puede corregir, pero no es la llave del ticket, y cada cambio queda en el historial con su motivo.

Un tablero para el proceso, una cola para cada rol

El caso recorre ocho etapas: datos incompletos, garantía, recolección, ingreso, taller, salida, nota crédito y cierre. El tablero muestra dónde está cada ticket y cuánto le queda del plazo; la tabla sirve para buscar y filtrar.

Cada rol tiene su propia cola, porque cada uno mira el caso desde un lugar distinto: logística valida la garantía y carga la guía, ingreso registra el estado físico y la posición con escáner, el taller asigna y repara, bodega autoriza los repuestos, QA revisa y despacho entrega.

Cuando a un caso le faltan datos, el sistema los pide solo: un aviso al llegar, un recordatorio a las 24 horas y el archivo a las 36, con tres textos distintos. La primera versión recordaba cada 12 horas para siempre, y eso es spam. Ahora son tres avisos y para.

Un agente que no toca lo irreversible

El agente corre cada dos minutos, lee un correo por vez y tiene cuatro herramientas de negocio: identificar la tienda, registrar la solicitud, completarla o marcarla para revisión. No tiene acceso a la base. No escribe SQL, no lee otros correos, no ve otros tickets y no mueve estados: solo hace nacer el ticket. Las transiciones son siempre de una persona.

Lo irreversible lo gobierna el sistema, no el modelo. El agente nunca redacta un correo libre: las respuestas salen de plantillas que GTM edita, a una lista blanca de destinatarios. Si cita un dato, se comprueba contra el texto real del correo. Y si algo falla, falla cerrado: el correo nunca se pierde, pasa a revisión humana.

Lo que no admite otra lectura va en código antes de llegar al modelo: quién escribe, los buzones automáticos, una respuesta que trae exactamente un IMEI. Una revisión mostró que buena parte de lo que se le enviaba al modelo podía resolverse con reglas, más barato y más predecible.

La bitácora nació de un acierto que nadie pudo ver. El agente decidió bien sobre un correo, pero el motivo vivía en memoria y se perdió. Un acierto que no deja rastro es igual a no haber hecho nada.

Arquitectura

Algunas decisiones que definen el sistema:

• —Las reglas del dominio se validan en la base, no en la interfaz. Solo bodega toca repuestos, quien pide una nota crédito no la aprueba y quien repara no se audita a sí mismo. El supervisor puede saltarse una regla, pero queda registrado como excepción con su nombre.
• —Ninguna llave llega al navegador y ninguna tabla nace sin su política de seguridad en la misma migración.
• —La ingesta la dispara pg_cron desde la base, porque en una plataforma serverless no hay dónde mantener viva una conexión IMAP.
• —Dos ambientes, y el de desarrollo espeja producción sin mejorarla. Un ambiente más estricto da verde y deja pasar el problema; uno más permisivo falla donde producción funciona, y en dos semanas nadie le cree.
• —Privacidad en desarrollo: nada sale de producción. Los datos son sintéticos, y el ambiente no tiene credenciales de correo. Los interruptores ayudan, pero la protección real es que las credenciales no existan.
• —El acceso es con un código y no con un enlace mágico, porque los escáneres de enlaces del correo corporativo consumían el enlace de un solo uso antes que la persona.
• —La interfaz usa solo shadcn/studio y su plantilla de administración. Antes de diseñar una pantalla se busca la vista de la plantilla que ya tiene esa forma: se aprendió al rehacer dos pantallas armadas a mano.

Stack

Lo que aprendí

Que la plantilla debería ahorrar trabajo, no hacer reprocesar. Revisar el catálogo pieza por pieza no alcanza: hay que buscar la pantalla que ya resuelve la forma entera antes de empezar a componer.

Que con un agente en producción, lo que más vale no es lo que decide sino poder explicar por qué lo decidió. Y que conviene preguntarse, antes de mandarle algo al modelo, si esa decisión ya tiene una respuesta que se pueda escribir como regla.

Y que las reglas de un proceso con dinero y plazos de por medio deben vivir donde nadie las pueda saltar sin dejar rastro. La excepción es un permiso; el registro es la condición.