**Plan: CRM de mensajería masiva por WhatsApp con IA para tu plataforma ISP**

**1. Decisión clave: qué API de WhatsApp usar**

Es la decisión que más afecta el costo, el riesgo y el diseño.

|**Opción**|**Ventajas**|**Riesgos**|
| :- | :- | :- |
|**WhatsApp Business Platform (API oficial de Meta)**, directo o con un BSP (360dialog, Twilio, Gupshup, etc.)|Estable, legal, soporta imágenes, plantillas, botones y webhooks. Escala bien.|Cobro por conversación o mensaje. Los mensajes iniciados por ti requieren **plantillas aprobadas por Meta**. Exige opt-in del cliente.|
|**APIs no oficiales** (Baileys, whatsapp-web.js, Evolution API)|Gratis, rápidas de montar.|Violan los términos de WhatsApp. **Riesgo real de bloqueo del número**, y en un ISP eso corta tu canal de cobranza. Inestables.|

**Recomendación:** API oficial. Como tu sistema es SaaS multiempresa, cada empresa ISP conecta su propio número (WABA) y el costo se les traslada en el plan. Si necesitas prototipar rápido, usa la no oficial solo en pruebas internas, nunca en producción.

**2. Alcance funcional**

**Campañas masivas**

- Selección de audiencia con filtros que salen de tu base ISP: zona, plan de internet, estado del cliente (activo, suspendido, moroso), router/OLT, fecha de vencimiento, promesa de pago.
- Programación por **fecha y hora**, con zona horaria de la empresa (America/Guayaquil), envío recurrente (ej. recordatorio de pago cada mes) y envío inmediato.
- Plantillas con variables: {nombre}, {monto}, {fecha\_vencimiento}, {plan}, {link\_pago}.
- **Imágenes** en el mensaje (encabezado de plantilla o mensaje multimedia): promociones, avisos de corte, comprobantes, mapas de cobertura. Opcional: PDF de factura.
- Cola de envío con límite de velocidad, reintentos y pausa/cancelación de campañas.
- Reporte por campaña: enviados, entregados, leídos, fallidos, respondidos.

**Respuestas automáticas con IA**

- Bot que atiende mensajes entrantes: consulta de saldo, fecha de vencimiento, estado del servicio, promesa de pago, creación de ticket de soporte.
- Base de conocimiento por empresa (preguntas frecuentes, horarios, formas de pago) para respuestas con RAG.
- **Escalamiento a humano** cuando el bot no sabe, el cliente está molesto o lo pide explícitamente.
- Respuestas fuera de horario y palabras clave (BAJA, STOP, ASESOR).

**CRM / bandeja de conversaciones**

- Inbox unificado con historial por cliente, asignación a agentes, etiquetas y estados.
- Ficha del cliente enlazada al módulo CLIENTES, FINANZAS y SOPORTE del sistema.

**3. Arquitectura recomendada**

[Plataforma ISP] <-- API interna / eventos --> [Servicio CRM-WhatsApp]

`                                                  `|-- API REST

`                                                  `|-- Cola de mensajes (Redis + BullMQ / RabbitMQ)

`                                                  `|-- Scheduler (cron / jobs programados)

`                                                  `|-- Webhook receptor de Meta

`                                                  `|-- Motor IA (LLM + herramientas)

`                                                  `|-- Almacenamiento de imágenes (S3 / MinIO)

`                                                  `|-- MySQL

- **Módulo desacoplado** dentro del SaaS: comparte autenticación, empresa (tenant) y permisos, pero con su propio servicio para no frenar el sistema principal.
- **Multiempresa:** toda tabla lleva empresa\_id; cada empresa tiene su propia conexión WhatsApp, plantillas y base de conocimiento.
- **Integración con el ISP** de dos formas: consulta directa (el bot pide saldo/estado al API del sistema) y por eventos (factura emitida, pago registrado, servicio suspendido → dispara mensaje automático).
- **IA con herramientas (tool use):** el LLM no inventa datos; llama funciones como consultar\_saldo(cliente), crear\_ticket(...), registrar\_promesa\_pago(...). Eso evita respuestas erróneas sobre dinero.

**4. Modelo de datos (MySQL), tablas principales**

- wa\_cuentas (empresa\_id, número, WABA id, token cifrado, estado)
- wa\_plantillas (nombre, categoría, idioma, cuerpo, variables, imagen, estado de aprobación Meta)
- wa\_contactos (cliente\_id, teléfono, opt\_in, fecha\_opt\_in, opt\_out)
- wa\_campanas (plantilla, filtro de audiencia, programada\_para, zona\_horaria, recurrencia, estado)
- wa\_mensajes (campaña, contacto, dirección entrante/saliente, tipo, estado, id Meta, error)
- wa\_conversaciones (contacto, agente, estado bot/humano, etiquetas)
- wa\_medios (url, tipo, tamaño, hash)
- wa\_base\_conocimiento (empresa\_id, contenido, embeddings)
- wa\_reglas\_auto (disparador, condición, acción)

**5. Fases de desarrollo**

|**Fase**|**Contenido**|**Duración estimada**|
| :- | :- | :- |
|**0. Preparación**|Cuenta Meta Business, verificación de empresa, número, elegir BSP, definir plantillas base|1-2 semanas (la verificación de Meta puede tardar)|
|**1. Núcleo de envío**|Conexión API, webhooks, envío de texto e imagen, estados de entrega, cola|2-3 semanas|
|**2. Plantillas y campañas**|CRUD de plantillas con variables, subida de imágenes, audiencias con filtros del ISP, reportes|2-3 semanas|
|**3. Programación**|Scheduler por fecha/hora, recurrencia, zona horaria, pausa y cancelación|1-2 semanas|
|**4. Integración ISP**|Eventos (factura, pago, corte, ticket), consulta de saldo, vínculo con CLIENTES/FINANZAS/SOPORTE|2 semanas|
|**5. Bandeja CRM**|Inbox, asignación de agentes, etiquetas, historial|2-3 semanas|
|**6. IA y auto-respuestas**|LLM con herramientas, base de conocimiento, escalamiento a humano, reglas por palabra clave|3 semanas|
|**7. SaaS y cierre**|Límites por plan (mensajes/mes), facturación del consumo, roles y permisos, pruebas de carga, seguridad|2 semanas|

Total aproximado: **3 a 4 meses** con un desarrollador full-stack dedicado. Puedes lanzar un MVP al final de la fase 3 (envío masivo programado con imágenes) y agregar IA después.

**6. Casos de uso típicos para un ISP**

- Recordatorio de pago 3 días antes del vencimiento, con imagen o link de pago.
- Aviso de corte por mora y confirmación de reconexión.
- Aviso masivo de mantenimiento o falla en una zona específica.
- Promociones y cambios de plan.
- El cliente escribe “¿cuánto debo?” y el bot responde al instante.
- Encuesta de satisfacción al cerrar un ticket.

**7. Cumplimiento y riesgos**

- **Opt-in obligatorio:** guarda cuándo y cómo el cliente aceptó recibir mensajes (puede incluirse en el contrato de instalación). Sin esto, Meta puede restringir tu número.
- **Opt-out:** respeta las bajas de inmediato.
- **Calidad del número:** muchos reportes de spam bajan el límite de envío. Segmenta y no envíes lo que no corresponde.
- **Datos personales:** en Ecuador aplica la Ley Orgánica de Protección de Datos Personales; cifra tokens y teléfonos, y registra consentimientos.
- **IA:** que nunca prometa descuentos ni acciones que no estén definidas, y que registre todo lo que responde para auditoría.
- **Costos:** estima el gasto por mensaje de Meta antes de fijar los planes de tus empresas clientes.

**8. Stack sugerido**

Backend Node.js (NestJS) o el lenguaje que ya uses en el sistema, MySQL, Redis + BullMQ para colas y programación, S3/MinIO para imágenes, frontend en el mismo framework del panel ISP, y un LLM vía API (Claude, por ejemplo) con búsqueda sobre la base de conocimiento.

¿Quieres que lo deje en un archivo .md como tus otros planes, o que baje alguna fase al detalle (por ejemplo el modelo de datos completo o los endpoints de integración con el ISP)?