Automatización de Correo Electrónico — Constructor de Sección de Administración
Construye un sistema de automatización de correo electrónico de clase mundial dentro del panel de administración existente del usuario. Observa el comportamiento del usuario, inscribe a las personas en la secuencia de ciclo de vida adecuada y envía correos recordatorios personales, uno a la vez a través de la conexión de correo configurada de la propia aplicación, respaldados por tiempos de embudo probados, no por envíos masivos.
Objetivo: aumentar el retorno, la compra y la retención de usuarios, sin spam y sin romper nada que ya funcione.
Lee esto primero: esta habilidad es no disruptiva por diseño. Estudia la aplicación antes de modificarla, agrega solo nuevas tablas/rutas (nunca reescribe flujos existentes), reutiliza la conexión de correo de la aplicación y se entrega en pausa. Nada se envía hasta que un administrador lo active explícitamente.
El flujo de trabajo
0. Descubrir ─▶ 1. Diseñar ─▶ 2. Construir ─▶ 3. Conectar eventos ─▶ 4. UI de Admin ─▶ 5. Verificar ─▶ 6. Entregar
estudiar modelo de datos nuevas tablas/ disparadores → panel + simulación + en pausa +
la app + + secuencias worker/cron inscripciones tablas + stats vista previa "¿activar?"
0. Descubrir (obligatorio, antes de cualquier código)
Estudia la aplicación a fondo y produce un breve plan de integración. Consulta references/discovery.md.
- Detecta el stack, framework, ORM/BD, autenticación, sesiones, el panel de administración (o nota su ausencia).
- Encuentra la conexión de correo existente (SMTP/SDK del proveedor) — reutilízala; nunca agregues una segunda.
- Mapea productos, carrito/checkout, pedidos, usuarios y los eventos necesarios.
- Comprende el propósito de la plataforma y su modelo de negocio (e-commerce, SaaS, fintech, reservas, …), su evento de activación y sus pasos críticos de cuenta — luego propón secuencias de recordatorio adicionales que encajen (verificación de correo, finalización de perfil, onboarding, KYC, prueba/facturación, reserva, renovación…).
- Si no hay panel de administración, pregunta al usuario si se debe crear uno mínimo.
1. Diseñar
- Define el modelo de datos (
examples/data-model.md): secuencias, pasos, inscripciones, correos programados, registro de envíos, configuraciones, supresiones. - Elige el conjunto de secuencias y sus tiempos (
references/sequences.md).
2. Construir (solo aditivo)
- Agrega nuevas tablas/colecciones, un trabajo de planificador y el trabajador de envío. No modifiques tablas existentes.
- Agrega un indicador de funcionalidad / interruptor maestro de pausa (por defecto APAGADO) y un interruptor de apagado global.
3. Conectar eventos
- Conecta los eventos existentes de la aplicación (registro, inicio de sesión, agregar al carrito, inicio de checkout, compra, inactividad) a la inscripción — sin cambiar su comportamiento (observa, no interceptes).
4. UI de Administración
- Agrega un menú de nivel superior "Automatización de Correo" con pestañas: Secuencias · Destinatarios · Estadísticas · Configuración. Consulta
references/admin-ui.md. - Agrega tablas solo para administradores de compras/abandonos al final de las páginas de producto y checkout.
5. Verificar
- Modo de simulación (dry-run), una herramienta de vista previa/envío de prueba, verificaciones de idempotencia y una auditoría de condiciones de parada.
6. Entregar
- El sistema se entrega en pausa. Notifica al administrador, muestra un botón de un clic "Activar" (o permite que el agente ayude) y documenta la reversión.
El catálogo de secuencias (tiempos de embudo probados)
Detalle completo, intención de copia y condiciones de parada: references/sequences.md. Resumen:
| # | Secuencia | Disparador | Tiempo (por defecto) | Se detiene cuando |
|---|---|---|---|---|
| 1 | Bienvenida / activar | Registro | 0h bienvenida → 24h valor → 72h prueba social | Inicio de sesión / compra |
| 2 | Registrado, nunca inició sesión | Registrado + sin inicio de sesión | 1h → 24h → 72h | Inicio de sesión |
| 3 | Inició sesión, sin compra/uso | Inició sesión, inactivo | 1h recordatorio → 24h → 5d | Compra / activación |
| 4 | Carrito / checkout / producto abandonado | Vista de carrito, checkout o producto, sin compra | 1h recordatorio (sin descuento) → 24h prueba social/objeciones → 48–72h urgencia + descuento | Compra |
| 5 | Reseña post-compra | Compra (sensible al tipo de producto) | Al día siguiente "¿cómo va todo?" → 2 semanas "experiencia + venta adicional" | Reseña / cancelar suscripción |
| 6 | Venta adicional / cruzada | Compra, existen otros productos | Después del momento de valor (3–7 días) | Compra del artículo promocionado |
| 7 | Recuperación / reenganche | Inactivo 30 / 60 / 90 días | Neutral → valor → final "dejaremos de enviar" | Actividad / cancelar suscripción |
| 8 | Reabastecimiento | Producto consumible | ~Día 45–60 | Recompra |
Descuentos: las ventas adicionales pueden incluir un descuento; los carritos abandonados llevan urgencia + descuento. Por defecto 0% — cuando es 0, el correo no debe mencionar ningún descuento. Una protección de carrito mínimo omite el incentivo en carritos de muy bajo valor. (references/sequences.md.)
Precedencia: un usuario está en como máximo una secuencia promocional — compra > carrito > navegación > bienvenida > sin inicio de sesión > inactivo > recuperación. Secuencias adicionales: abandono de navegación, reposición de stock, bajada de precio, dunning, referidos. Consulta references/sequences.md.
Además, secuencias derivadas de la plataforma descubiertas a partir del propósito de la aplicación — p. ej. verificación de correo, finalización de perfil, configuración de onboarding, KYC, facturación/finalización de prueba, recordatorios de reservas, renovaciones. Solo agrega aquellas que la plataforma pueda detectar y en las que pueda actuar (references/sequences.md).
Reglas no negociables
- Estudiar antes de construir. Nunca modifiques flujos existentes de autenticación, carrito, checkout, pedidos o usuarios. Agrega solo nuevas tablas/rutas.
- Reutilizar la conexión de correo existente. Sin segunda configuración de SMTP/proveedor. Sin envíos masivos — los correos son por usuario y basados en eventos.
- Se entrega en pausa. Interruptor maestro APAGADO; se notifica al administrador para que lo active (el agente puede ofrecer ayuda).
- Sin spam. Límites de frecuencia (por defecto ≤1 correo de marketing/usuario/24h, ≤4/semana), horas de silencio y una lista de supresión global (cancelados, rebotados, quejados). Respeta el consentimiento e interés.
- Las condiciones de parada siempre ganan. Vuelve a verificar el objetivo (compra/inicio de sesión/activación) antes de cada envío para que los compradores no reciban recordatorios de carrito.
- Copia personalizada, uno a uno. "De" una persona real (
Nombre de la Marca), redactada personalmente, que haga referencia al producto real, una CTA clara y un enlace "contactar administrador" en cada correo. - Capacidad de entrega + legal. SPF/DKIM/DMARC, dominio de envío con marca, HTML + texto plano, enlace para cancelar suscripción + dirección física, sin palabras de activación de spam. Consulta
references/sending-and-compliance.md. - Todo auditable. Cada envío se registra (quién, qué secuencia/paso, cuándo, por qué) y cada correo programado es visible en el panel de administración.
- Belleza + integración perfecta. Coincide con los tokens de diseño de la aplicación; la sección de administración debe verse nativa. Usa el rigor similar a
reviews-to-features: jerarquía clara, objetivos de 44px, contraste accesible. - Editor WYSIWYG gratuito para los cuerpos de correo. El administrador edita cada plantilla de correo en un editor WYSIWYG gratuito y auto-alojado (TinyMCE Community; o Quill / TipTap / Summernote / GrapesJS). La salida debe ser segura para correo (CSS en línea, tablas, ~600px, sin JS), sanitizada, con tokens de combinación, un bloque de descuento condicional y una versión de texto plano generada automáticamente.
Contrato de no disrupción (aplicado)
"No disruptivo" se verifica, no se asume. Lista de verificación completa: references/non-disruption.md. Mínimo:
- Hacer una copia de seguridad de la BD antes de migrar; las migraciones son aditivas + reversibles (sin modificar tablas existentes).
- Los hooks son de solo observación y están envueltos en
try/catch— un observador que falla nunca rompe el registro/inicio de sesión/checkout/pago. - Se entrega en pausa con un interruptor de apagado global; reutiliza la conexión de correo existente.
- Prueba de humo de los cinco flujos principales después de la instalación; ejecutar un ejercicio de reversión (deshabilitar → eliminar tablas → confirmar que no se modificó nada).
Superficie de administración (lo que obtiene el administrador)
- Diseño tranquilo y sin desorden — ≤4 pestañas, una acción principal por vista, detalles en un panel lateral, acciones secundarias/destructivas en un menú desplegable (
⋯), configuraciones avanzadas colapsadas, banners de salud solo cuando sea necesario. - Banners de salud en la parte superior de cada pestaña (solo cuando hay un problema): no hay transporte de correo configurado, planificador/cron no se está ejecutando (con un detalle del porqué + cómo solucionarlo), y automatización en pausa. Consulta
references/health-checks.md. - Menú Automatización de Correo (de nivel superior), con pestañas:
- Secuencias — por secuencia Iniciar / Pausar / Eliminar (eliminar se confirma + se marca como eliminada/restaurable, metido en
⋯), retrasos, descuentos, condiciones de parada, un editor WYSIWYG gratuito, y agregar / reordenar / eliminar pasos. - Usuarios y destinatarios — buscar un usuario por correo; expandir su secuencia de correos con el caret hacia abajo; cancelar un correo específico o excluir al usuario por completo; además, el registro completo de envíos paginado de 100 en 100 con cuándo y por qué.
- Estadísticas — de los usuarios que recibieron un recordatorio, cuántos convirtieron, ingresos, gráfico por día / semana / mes.
- Configuración — remitente (nombre-de/de-correo/responder-a/dirección física), pausa maestra, límites, horas de silencio.
- Secuencias — por secuencia Iniciar / Pausar / Eliminar (eliminar se confirma + se marca como eliminada/restaurable, metido en
- Tablas solo para administradores al final de las páginas de producto y checkout:
- Pestañas Comprado / Abandonado — claramente marcadas "Solo administrador".
- Columnas: correo (→ panel de usuario), fechas de registro/inicio de sesión/abandono, cantidad que habría pagado, teléfono (→
tel:llamada), y un caret que revela correos recibidos + programados que enlaza al panel de usuario para cancelar/excluir. - Se pueden deshabilitar desde Automatización de Correo → Configuración, con instrucciones bajo el título de la tabla + enlace.
Especificación completa de la UI: references/admin-ui.md.
Cuándo NO usar
- Sin base de consentimiento legal para correo de marketing (ofrecer primero un flujo de consentimiento).
- Bases de usuarios muy pequeñas donde el ruido de la automatización supera el valor — enviar manualmente.
- Productos donde el correo no es el canal (SMS/notificaciones push primero) — adaptar el motor, no forzar el correo.
- Contextos regulados (salud/finanzas) que necesitan revisión más estricta — obtener aprobación de la copia y los flujos de datos.
- Necesidades transaccionales de alta seguridad — nunca enrutar recibos/correos de seguridad a través de este sistema.
Entregables que produce el agente
references/discovery.md→ un plan de integración para la aplicación específica, que incluya una lista corta de secuencias propuestas derivada del propósito de la plataforma.- Nuevas tablas/migraciones + el planificador + el trabajador de envío (aditivo).
- Los hooks de eventos (solo observación).
- La página de "Automatización de Correo" en el panel de administración + pestañas + gráfico de estadísticas, que incluya un editor WYSIWYG gratuito, agregar / reordenar / eliminar pasos, una búsqueda de usuario + cancelación/exclusión por correo, y advertencias de salud (en pausa, cron no ejecutándose, sin transporte de correo).
- Las tablas solo para administradores de compras/abandonos.
- Una herramienta de vista previa/envío de prueba + simulación (dry-run) + notas de reversión.
- Un breve documento de entrega: qué se agregó, cómo activarlo, cómo pausarlo, cómo revertir.
Referencias
references/discovery.md— estudiar la aplicación, encontrar el panel de administración, elegir una ruta de integración.references/non-disruption.md— el contrato de no disrupción aplicado (copia de seguridad, migraciones reversibles, aislamiento de hooks, prueba de humo, ejercicio de reversión).references/triggers.md— reglas exactas de detección para cada disparador (abandono de carrito, inactividad, etc.).references/sequences.md— el catálogo completo de secuencias, precedencia, tiempos, intención de copia, condiciones de parada.references/email-copy.md— estándares de copia personal "de una persona", líneas de asunto, plantillas.references/sending-and-compliance.md— planificador, idempotencia, límites, verificación previa de entregabilidad.references/compliance.md— consentimiento, cancelación de suscripción firmada, centro de preferencias, webhooks de rebote/queja.references/admin-ui.md— el panel, pestaña de usuarios (buscar/cancelar/excluir), registro (100/página), estadísticas, tablas solo para administradores, WYSIWYG, agregar/editar pasos.references/health-checks.md— advertencias de pausa / cron-no-ejecutándose / sin-transporte con guía de solución.references/reference-implementation.md— el motor en pseudocódigo + SQL (bloqueo, recolector, atribución).examples/worker.mjs+examples/worker.test.mjs— núcleo de planificador/trabajador ejecutable y probado.examples/data-model.md— esquema de BD.examples/sequence-config.json— una configuración de secuencia concreta y editable.examples/email-templates.md— ejemplos de correos renderizados.