Profesional
Asistente de cobranza | Estados de cuenta y pagos
El cliente consulta su saldo, reporta un pago o promete una fecha por WhatsApp. El modelo interpreta; el código decide la acción y qué datos revela.
- IA
- Full Stack
- Rol
- Desarrollo
- Periodo
- 2026-07 — Actualidad
Stack
- TypeScript
- Node.js
- MySQL
- Claude
- Docker
- Google Cloud Run
Contexto
Cobranza por WhatsApp para la operación de Intercargo en Panamá. El cliente escribe, consulta su estado de cuenta, reporta un pago o promete una fecha, y todo ocurre dentro de la conversación.
Problema
La cobranza se apoyaba en listas de clientes a los que había que contactar uno a uno. Cada comprobante de pago lo revisaba una persona antes de que el saldo quedara al día.
El cliente pidió automatizar ese ciclo. El deudor consulta su propio saldo y adjunta su propio comprobante, y el equipo interviene solo donde hace falta criterio.
Decisiones técnicas
Un asistente de cobranza expone saldos de terceros. Si el modelo decidiera a quién se los muestra, cada respuesta dependería de que no se equivoque, y un modelo de lenguaje no da esa garantía.
Por eso el modelo hace una sola cosa: convertir un mensaje en lenguaje natural en una intención y, cuando aplica, en una fecha.
Todo lo demás es código: validar identidad, consultar cartera, registrar una promesa de pago y decidir si corresponde recordar. La conversación se resuelve en una máquina de estados que devuelve acciones, y una capa separada las traduce al transporte de WhatsApp.
El servicio no usa framework web: levanta un servidor con node:http y trabaja sobre nueve tablas propias, separadas del resto de la plataforma corporativa. El proveedor de modelo es intercambiable, con dos implementaciones detrás de la misma interfaz.
Arquitectura
El modelo ocupa un solo tramo del recorrido. Lo que entra y lo que sale de él son estructuras que el código valida antes de seguir.
El número de teléfono no basta como identidad. Hasta que la identidad queda verificada, la conversación no revela ningún dato de la cartera.
El modelo devuelve una intención, no una orden. Las acciones disponibles son un conjunto cerrado definido en el código, así que una intención sin acción correspondiente no ejecuta nada.
Días hábiles, feriados y ventana de contacto se calculan en el servidor. Quien pide no recibir más mensajes deja de recibirlos. El recordatorio sale un día hábil antes del vencimiento.
Cada turno guarda el mensaje recibido, la intención resuelta y la acción ejecutada. Una respuesta inesperada se puede reconstruir después sin volver a consultar al modelo.
La máquina de estados devuelve acciones y una capa aparte las traduce al transporte, así que la conversación se puede ejecutar sin credenciales de Meta ni línea de WhatsApp.
Resultado
El servicio está en operación sobre nueve tablas propias, separadas del resto de la plataforma. Un comando reproduce un diálogo entero contra la lógica real, y con él se prueban los casos difíciles: una promesa con fecha ambigua, un pago reportado dos veces, un cliente que pide dejar de recibir mensajes.
Lo que aprendí
Ese simulador recorre la máquina de estados de extremo a extremo, y por eso detecta una regresión de flujo sin poder localizarla: cuando falla, señala el diálogo entero y no el módulo. Las pruebas sobre la capa de acciones son el siguiente paso.