Profesional · 2026

Bot de solicitudes y reclamos

Asistente multi-agente por WhatsApp con puertas deterministas y derivación a un asesor.

Panel de operaciones con agenda, indicadores y salud de clientes — Captura real · datos de ejemploPanel principal con la agenda del equipo, los indicadores del día y el estado de la cartera de clientes.

Analítica de reclamos con indicadores y distribución por tipo — Captura real · datos de ejemploVista analítica de reclamos con indicadores clave, distribución por tipo y antigüedad de los casos.

Listado de casos con estado, tipo y antigüedad — Captura real · datos de ejemploListado de casos con búsqueda, filtros y seguimiento del estado y la antigüedad de cada reclamo.

Detalle de gestión de un caso de reclamo — Captura real · datos de ejemploFicha de gestión de un caso con historial del cliente, gestión con el aliado y cierre del reclamo.

Captura real · datos de ejemploMatriz de desempeño por transportadora con casos aceptados, declinados, pendientes y efectividad.

Tablero Kanban de compromisos — Captura real · datos de ejemploTablero de compromisos derivados de las actas, organizado por atrasados, por cumplir y completados.

01
Puertas deterministas antes de dejar actuar al modelo
02
Fotos como evidencia, analizadas con visión
03
Monitor en tiempo real por WebSocket

El problema

Las solicitudes de repuestos y los reclamos de garantía los atendía un asesor de forma manual: identificar al cliente, entender qué necesitaba, revisar la factura en el ERP, consultar inventario y registrar el caso en el CRM. Es un proceso repetitivo, con muchos datos que pedir y validar, y errores fáciles de cometer (datos faltantes, factura inválida, falta de evidencia del defecto).

La solución, de punta a punta

El cliente escribe por WhatsApp. En el primer mensaje de la sesión acepta la política de tratamiento de datos; si no la acepta, la sesión se cierra.
El bot lo identifica y entiende su necesidad. En una solicitud de repuesto pide los datos necesarios con validaciones deterministas, consulta existencias y ofrece una alternativa si hace falta.
En un reclamo de garantía pide la referencia del producto, valida la factura en el ERP, recoge la descripción del defecto y exige una foto, que se analiza con un modelo de visión.
Con los datos completos, un agente arma el caso y se registra en el CRM. Si el CRM falla, el caso queda en una cola de reintentos.
Las compras directas, las piezas fuera de catálogo, los reclamos sin factura o sin foto y los usuarios frustrados se derivan a un asesor. Mientras espera, el estado de la conversación intercepta los mensajes siguientes.

Arquitectura

El cliente escribe por WhatsApp a través de un proveedor; una API recibe el mensaje y lo pasa a un orquestador que funciona como máquina de estados y coordina agentes especializados que usan modelos de lenguaje y de visión. El orquestador consulta los sistemas de la empresa, registra el caso con reintentos y deriva a un asesor cuando corresponde. Un panel de monitoreo en tiempo real muestra lo que ocurre.

Decisiones de diseño

Multi-agente. Agentes especializados por tarea, coordinados por una máquina de estados explícita. Cada agente tiene una tarea acotada.
Puertas deterministas antes del modelo. El menú, las validaciones de datos y las reglas de derivación funcionan por reglas y palabras clave, sin LLM. El modelo se usa para extraer e interpretar información, no para decidir el flujo.
Derivación a humano. Por petición explícita, frustración repetida, compra, pieza fuera de catálogo o falta de requisitos. Es parte del diseño, no un fallo.
Imágenes y voz. Las fotos se analizan con visión como evidencia o referencia; las notas de voz se transcriben. Si la visión falla, el flujo continúa y se avisa al asesor.
Reclamos con evidencia. La foto es obligatoria, la factura se valida contra el ERP y, si el CRM no responde, el caso se conserva con reintentos y registro de fallos.
Lo verificado. El comportamiento descrito está leído en el código y la documentación de los repositorios. No hay medición de precisión del bot.

Ingeniería

Monitor en tiempo real. Un panel web (Next.js y React) muestra ejecuciones con línea de tiempo de pasos, sesiones con chat, casos creados y estadísticas, alimentado por WebSocket.
Pruebas. Suite de pruebas en el backend y pruebas con vitest en el frontend.
CI/CD y despliegue. GitHub Actions con flujos de integración y despliegue, imágenes Docker por servicio y orquestación con Docker Compose.
Datos. SQLAlchemy asíncrono con migraciones y bases separadas para la operación y el monitoreo.

Mi rol

Soy autor del backend y del monitor originales; lo verifiqué con el historial de git (131 commits sin merge entre ambos repositorios, todos míos). Hice la migración inicial desde un flujo de automatización a FastAPI multi-agente, las sesiones, los flujos, el monitor y una auditoría de casos. El desarrollo fue asistido por IA. Versiones posteriores del proyecto fueron mantenidas por otra persona y no las presento como mías.

Lo que aprendí y qué cambiaría

Separar lo determinista de lo probabilístico simplifica las pruebas y hace predecible el comportamiento.
Los orquestadores crecen rápido; dividiría el orquestador en módulos más pequeños y reduciría el código duplicado entre repositorios.
Añadiría una evaluación sistemática de conversaciones (casos de referencia y métricas por flujo) para medir calidad en lugar de depender de revisiones puntuales.
Como siguiente paso, incorporaría avisos proactivos con plantillas aprobadas, que hoy el bot no tiene: solo responde.

Estado: proyecto desarrollado; no afirmo clientes, volumen ni resultados medidos.