Dashboard del día
La primera pantalla del sistema: tarjetas con las métricas del día (recordatorios enviados, clientes pendientes, respuestas recibidas, pedidos pendientes de revisión y errores) junto a los pedidos y mensajes más recientes.
Preventa de productos frescos con recordatorios por WhatsApp y Telegram, IA que interpreta cada respuesta y revisión humana antes de confirmar el pedido.
2025 · En producción
2025
Internal tool
En producción
Full-stack developer & architect
3 meses
Privado
Stack aplicado //
Capturas reales del sistema en marcha. Sin mocks, sin renders.
Recorrido por el ciclo de preventa: recordatorios automáticos por WhatsApp y Telegram, respuesta del cliente, interpretación con IA y bandeja de revisión humana antes de aprobar el pedido.
La primera pantalla del sistema: tarjetas con las métricas del día (recordatorios enviados, clientes pendientes, respuestas recibidas, pedidos pendientes de revisión y errores) junto a los pedidos y mensajes más recientes.
El corazón operativo: todos los pedidos interpretados por IA desde WhatsApp y Telegram en tarjetas con su mensaje original, resumen de IA, estado y fuente, con filtros por estado, fechas, cliente, revisor y origen.
La pantalla de decisión: mensaje original del cliente junto al resumen de la IA con intención y confianza, el pedido interpretado con items y notas editables, y las acciones de aprobar, marcar como dudoso o descartar.
Ficha completa del cliente recurrente: nombre, teléfono, día de visita, pedido habitual, consentimiento y estado, con el historial de mensajes y pedidos que da contexto a la IA en cada interpretación.
Gestión de la cartera con búsqueda y filtros avanzados por día de visita, consentimiento y estado activo o inactivo. Cada fila muestra el pedido habitual, el canal y el estado de consentimiento del cliente.
Alta masiva sin errores: subida de CSV o Excel, vista previa de los datos, detección de duplicados por teléfono, validación de campos con registro de errores por fila y descarga de un CSV de ejemplo generado con IA.
Historial de mensajes con filtros por proveedor, dirección, estado y cliente. Cada respuesta recibida por webhook queda registrada junto a su interpretación, cerrando el ciclo de trazabilidad.
Panel centralizado para recordatorios, mensajería e IA: horarios de envío, plantillas, proveedor activo y parámetros del modelo, con los valores sensibles (tokens y claves de API) enmascarados.
Gestión de usuarios con roles de administrador y operador, activación y desactivación de cuentas y protección del admin principal, que no puede eliminarse ni desactivarse desde la interfaz.
Los distribuidores de productos perecederos gestionan a diario pedidos recurrentes de clientes fijos (restaurantes, bares, panaderías, tiendas). El proceso implica recordar a cada cliente por teléfono o mensajería, anotar los pedidos manualmente, interpretar cambios o solicitudes especiales y transferir la información al sistema de facturación. Con 20-50 clientes por distribuidor, es un proceso manual y propenso a errores, dependiente de la memoria del equipo, de escalabilidad limitada y sin trazabilidad de qué se pidió, cuándo ni cómo se interpretó cada mensaje.
Automatizar el primer contacto con el cliente (recordatorio y recepción de la respuesta) y la primera interpretación del pedido, manteniendo intacto el control humano: toda propuesta debe ser revisada y confirmada por un operador antes de procesarse.
Construir una aplicación web interna que envíe recordatorios automáticos por WhatsApp o Telegram según el día de visita de cada cliente, reciba las respuestas por webhook, las interprete con IA en pedidos estructurados y prepare una bandeja de revisión humana para aprobar, dudar o descartar cada operación.
Para quién es //
Dos componentes principales: un scheduler envía recordatorios automáticos en dos rondas (09:00 y 14:00) según el día de visita de cada cliente, y un servicio de IA interpreta cada respuesta recibida por webhook convirtiéndola en un pedido estructurado. Un panel web centraliza clientes, pedidos, mensajes, importación y configuración, y ninguna interpretación se confirma sin pasar por la bandeja de revisión humana.
Recordatorios en dos rondas según el día de visita de cada cliente.
IA que interpreta y propone, nunca decide: toda interpretación genera un pedido pendiente de revisión.
Validación JSON robusta con fallback degradado ante cualquier error del modelo.
Multi-proveedor de mensajería con una interfaz común: WhatsApp y Telegram intercambiables.
Panel centralizado: clientes, pedidos, mensajes, importación y configuración en una sola web.
Importación desde Excel/CSV para arrancar sin depender de ERP ni catálogo de productos.
Tradeoff honesto //
Es un área que requiere mantenimiento constante: cada exportación nueva o variación de formato entre proveedores exige ampliar la normalización.
Monolito Laravel 13 con Blade, Tailwind CSS y Alpine.js en la presentación y MariaDB 11.4 como persistencia. Seis capas con responsabilidades separadas: presentación, HTTP, acciones, servicios, dominio e infraestructura. Los webhooks de WhatsApp y Telegram entran por la capa HTTP, las acciones orquestan el flujo (registrar mensaje, interpretar, crear pedido, revisar) y la bandeja de revisión humana es el punto de control obligatorio antes de cerrar un pedido.
Flujo de datos //
Autenticación //
Autenticación por sesión con Laravel Breeze y dos roles: administrador (clientes, usuarios, configuración y logs) y operador (bandeja de revisión y consulta de clientes), con middleware de usuario activo y comprobación de rol. Los webhooks no usan sesión: se autentican con validación HMAC-SHA256 (WhatsApp) y secret_token (Telegram).
Notas técnicas //
Análisis del proceso manual de preventa: recordar clientes por teléfono o mensajería, anotar pedidos a mano, interpretar cambios y transferirlos al sistema de facturación. Manual, dependiente de la memoria, sin trazabilidad y de escalabilidad limitada.
Diseño de las entidades (clients, messages, orders, reminder_logs, ai_interpretations) y de las decisiones clave: interfaz MessagingService para desacoplar la mensajería, AIJsonValidator para validar la salida del LLM y revisión humana obligatoria por diseño.
Autenticación con Breeze, controladores por dominio, servicios de mensajería, IA, importación y dashboard, y comandos de recordatorios (preventa:reminders) con registro idempotente en reminder_logs.
Vistas server-rendered con la paleta slate + indigo y Figtree: dashboard operativo, bandeja de pedidos con filtros, importación con vista previa, configuración y gestión de usuarios.
Implementación de WhatsApp Business Cloud API (plantillas y validación HMAC) y Telegram Bot API (webhook con secret_token), ambas bajo la misma interfaz MessagingService con proveedor activo configurable.
Prompt de sistema con reglas estrictas (no confirmar, no inventar, dudar si es ambiguo), cliente HTTP OpenAI-compatible y AIJsonValidator que normaliza intents, valida confianza y acciones, y aplica fallback a unclear ante cualquier error.
Pantalla de detalle con el mensaje original del cliente, el resumen de la IA con confianza, el pedido interpretado editable y el historial de mensajes. Acciones de aprobar, dudoso o descartar con registro de revisor y timestamp.
Métricas del día en tarjetas, panel de settings con horarios, plantillas y parámetros de IA con valores enmascarados, y CRUD de usuarios con roles y protección del admin principal.
Carga desde CSV y Excel con vista previa, detección de duplicados por teléfono y registro de errores por fila. Generador de CSV de ejemplo con IA para preparar datos de prueba y verificar la importación.
33 archivos de tests con PHPUnit 12 cubriendo controladores, servicios, acciones, webhooks, parsers y comandos, con mocks específicos (FakeAiClient, FakeMessagingService) para pruebas aisladas.
Problemas reales durante el desarrollo, soluciones aplicadas y compromisos asumidos.
Problema //
Los teléfonos llegan en formatos muy distintos (+34612345678, 612345678, 612 345 678) y cada proveedor de mensajería puede devolver el número con variaciones propias, lo que rompe la búsqueda del cliente al recibir una respuesta.
Cómo se resolvió //
Implementación de un value object PhoneNumber que normaliza, compara y persiste los números en un formato único, usado tanto en la importación masiva como en el parseo de webhooks para localizar al cliente por teléfono o chat_id.
Tradeoff //
Es un área que requiere mantenimiento constante: cada exportación nueva o variación de formato entre proveedores exige ampliar la normalización.
Problema //
El modelo puede devolver texto envuelto en bloques markdown, JSON malformado o campos faltantes. En preventa, un fallo de interpretación se traduce en un pedido equivocado al cliente.
Cómo se resolvió //
AIJsonValidator y OpenAiCompatibleClient implementan varias capas de parsing: extracción del JSON, validación de intents permitidos, confianza en rango 0-1 y acciones válidas (add/remove/replace/keep), con normalización de datos inconsistentes.
Tradeoff //
El parsing sigue siendo inherentemente frágil: la robustez se construye con capas de validación y fallback, no eliminando la posibilidad de que el modelo devuelva algo inesperado.
Problema //
Los webhooks de WhatsApp y Telegram pueden llegar en ráfagas: varios mensajes del mismo cliente o de clientes distintos en el mismo segundo, con riesgo de estados de recordatorio inconsistentes o pedidos duplicados.
Cómo se resolvió //
Manejo de la concurrencia en la actualización de estados de recordatorios (MessageObserver dispara MarkReminderResponsesAction) y en la creación de pedidos, apoyándose en el registro idempotente de reminder_logs y en la asociación de cada pedido a la interpretación de su mensaje.
Tradeoff //
No se introdujo una cola de procesamiento externa en el MVP: los webhooks se procesan de forma síncrona, lo que simplifica la infraestructura pero exige handlers idempotentes y rápidos.
Problema //
El scheduler depende de la zona horaria configurada (Europe/Madrid): las rondas de 09:00 y 14:00 se calculan sobre ese huso. Cambiar de zona o soportar clientes en varias zonas requeriría modificaciones significativas.
Cómo se resolvió //
La zona horaria se centraliza en la configuración del sistema y el segundo recordatorio se calcula por umbral sent_at + gap configurable en lugar de por horario fijo, lo que mantiene la lógica estable ante reinicios o ejecuciones manuales.
Tradeoff //
El sistema asume una única zona horaria para toda la cartera: el soporte multi-zona queda fuera del alcance actual y exigiría rediseñar la selección de candidatos de los recordatorios.
Archivos de test
33
controladores, servicios, acciones, webhooks, parsers y comandos
Proveedores de mensajería
2
WhatsApp Business y Telegram, intercambiables por configuración
Rondas de recordatorio
2
09:00 y 14:00 según el día de visita del cliente
Intents de IA
6
confirmar, modificar, cancelar, preguntar, unclear e irrelevante
Capas de arquitectura
6
presentación → HTTP → acciones → servicios → dominio → infraestructura
Revisión del pedido
Sin confirmación automática
ningún pedido se cierra sin pasar por revisión humana
Otros puntos de la web donde se aplica este mismo enfoque o se profundiza en temas cercanos.
Añadir IA al software que ya usas: chat con tus documentos y datos (RAG), clasificación, extracción y resúmenes.
Clientes, proyectos, comunicación y agentes de IA en un solo lugar.
Si tus clientes piden por WhatsApp y anotas pedidos a mano, pierdes tiempo y dinero. Preventa con recordatorios, IA y revisión humana en producción.
Flujos que ejecutan acciones reales (WhatsApp, email, CRM, RAG) combinando n8n con código a medida.