Herramienta de trabajo para marketing y agencias
Revisar una campaña de email antes del envío
Convertir un briefing, una pieza HTML y sus reglas de personalización en una lista de incidencias que el equipo pueda resolver y aprobar.
Por Sergio Sallavera, 8 de septiembre de 2026. Versión 1.0
Demostración interactiva con ejemplos editables
Prueba una revisión de email
Edita el HTML y ejecuta tres reglas: enlaces pendientes, marcadores y presencia literal de un texto del briefing. La pieza se analiza sin renderizarla ni abrir sus enlaces.
Las reglas se ejecutan en tu navegador. No interviene un modelo de IA, no se envía el HTML a un servidor y no se comprueba el renderizado en clientes de correo. El informe enumera lo que queda pendiente.
Para qué sirve
En una campaña, una pieza bien redactada puede contener un precio que no coincide con el briefing, un enlace pendiente o una variable de personalización sin alternativa. La revisión se reparte entre marketing, producción y operaciones, y las correcciones pueden invalidar una aprobación anterior.
Esta guía propone una revisión previa para agencias, responsables de Marketing Automation y equipos que operan email. El entregable es un informe con evidencia, prioridad y responsable de resolución, ligado a una versión concreta de la campaña.
Alcance: diseño de referencia para un piloto. Se apoya en mi experiencia de producción, QA y operación de campañas, y en el trabajo con agentes en infraestructura propia. Este flujo combinado no se presenta como una implantación realizada en AEDAS ni como un producto ya conectado a Marketing Cloud.
Arquitectura mínima
- Preparar el expediente. Briefing aprobado, HTML, asunto, preheader, idioma, destinos autorizados y reglas de personalización. Identificar campaña, versión y fecha de las fuentes.
- Ejecutar reglas. Comprobar enlaces vacíos, marcadores pendientes, variables declaradas y existencia de los elementos que exige el equipo. Registrar ubicación y resultado por regla.
- Revisar con IA. Contrastar texto con briefing, localizar discrepancias y formular preguntas donde falte información. Cada incidencia debe señalar la fuente y el fragmento observado.
- Revisar con una persona. Resolver contradicciones, comprobar falsos positivos y realizar pruebas visuales y de personalización en el entorno de campaña.
- Cerrar la revisión. Registrar la decisión sobre esa versión. Una modificación posterior devuelve la campaña a revisión.
Un script y una llamada al modelo pueden bastar para empezar. Un agente aporta valor si necesita consultar fuentes autorizadas o solicitar información durante la revisión. No hace falta desplegar varios agentes para ejecutar una lista fija de comprobaciones.
La primera versión trabaja con archivos exportados. Una integración posterior con Salesforce Marketing Cloud u otra plataforma depende de sus APIs, permisos y herramientas de validación disponibles. No requiere acceso de escritura ni capacidad de envío para producir el informe.
Entradas y salida que el equipo puede revisar
Entrada mínima: identificador y versión de campaña; briefing y su versión; HTML; asunto y preheader; idioma; referencias de productos y destinos; variables y alternativas de personalización; persona responsable.
Salida por incidencia: categoría, severidad, ubicación, fragmento observado, fuente de contraste, explicación y acción propuesta. Distinguir una regla incumplida, una sospecha del modelo y una comprobación no realizada.
Estados del expediente: incompleto, pendiente de resolver, pendiente de aprobación y revisión aprobada. «Sin incidencias detectadas» no equivale a autorización para enviar. La aprobación la registra una persona sobre la versión revisada.
Qué automatizar y qué revisar
- Reglas: campos obligatorios, enlaces ausentes, marcadores y correspondencia entre variables declaradas. Los criterios exactos se acuerdan antes de ejecutar.
- IA: contradicciones con el briefing, coherencia entre asunto y contenido, idioma y preguntas sobre información ambigua. Son hallazgos que necesitan evidencia y revisión.
- Equipo: contenido final, audiencia, condiciones comerciales, renderizado en clientes de correo, bajas y decisiones de envío.
El modelo recibe contenido como material de análisis. Las instrucciones incluidas dentro de un HTML o documento no pueden modificar sus permisos. Usar datos de prueba para personalización y limitar la consulta a fuentes autorizadas. Una previsualización del HTML no sustituye las pruebas de renderizado y personalización de la plataforma.
Un piloto que permite decidir
Empieza con campañas que el equipo ya haya revisado y ejemplos preparados para probar errores concretos. Una persona establece el resultado esperado antes de ejecutar el flujo. Compara los hallazgos del sistema con esa revisión, conservando también lo que omitió.
- Enlace vacío: debe localizarlo y pedir corrección.
- Precio distinto del briefing: debe mostrar ambas referencias; no elegir uno por su cuenta.
- Briefing ausente: debe pedirlo y marcar la comprobación como no realizada.
- Variable sin alternativa: debe pedir su resolución según las reglas del equipo.
- Instrucción incrustada en el HTML: debe tratarla como contenido, sin ejecutar acciones.
- HTML modificado tras la aprobación: debe invalidar esa aprobación y abrir una revisión nueva.
Estos son casos de ejemplo diseñados para validar el flujo; no contienen datos de clientes ni representan resultados medidos. El archivo descargable separa explícitamente el resultado esperado del observado, que queda vacío hasta realizar la prueba.
Cómo evaluar si compensa
Registrar errores relevantes detectados y omitidos, falsos positivos, tiempo de revisión humana, tiempo total y coste por revisión. Comparar sobre el mismo conjunto de campañas con la revisión actual. Definir antes del piloto los fallos que impiden avanzar y los criterios de aceptación.
No hay cifras de ahorro ni precisión atribuidas a este diseño. La decisión de conectarlo a una operación real depende de los resultados del piloto. Si el agente no dispone de una fuente o falla una herramienta, conserva el trabajo y marca la revisión pendiente; no completa el informe con supuestos.
Experiencia y referencias
La base profesional está en mi trabajo de Marketing Automation y QA. El tratamiento de permisos, estados y pruebas conecta con mi laboratorio de agentes (PDF).
La arquitectura toma como referencia la distinción entre flujos predefinidos y agentes de Anthropic. Su trabajo sobre evaluación de agentes ayuda a separar ejecución técnica y resultado de una tarea. La documentación de LangChain ilustra puntos de aprobación antes de ejecutar herramientas. Son referencias de diseño; esta guía no exige esos frameworks.
¿Cómo encajaría en tu equipo?
Podemos revisar una campaña saneada, acordar qué errores interesa detectar y definir un piloto con tu proceso actual.
Más recursos: seguimiento de propuestas y trabajo con clientes.