Cómo entregar un correo HTML a un cliente: archivos, imágenes, ZIP y vista previa

El diseño está listo, pero el cliente necesita saber qué archivo importar, dónde seguirán alojadas las imágenes y qué depende todavía de su cuenta de envío. Entregar únicamente un ZIP llamado “final” deja ocultas esas decisiones. Una entrega organizada identifica la versión, el archivo principal y las responsabilidades de cada persona.

En esta guía, preparas el correo en Mailvex y entregas el HTML para el sistema que ya utiliza el cliente. Un archivo de imágenes y una referencia visual pueden acompañarlo cuando sean útiles. El resultado esperado es un paquete comprensible y verificable, con una fuente editable conservada para futuras revisiones.

1. Acuerda el destino antes de elegir la exportación

Pregunta qué plataforma enviará el correo y cómo recibe código propio: archivo HTML, código pegado o un ZIP con requisitos específicos. Confirma el formato con quien realizará la importación. No supongas que el cliente quiere editar por bloques únicamente porque pidió “el HTML”.

• Define el idioma, la versión y cuál será el único archivo principal para enviar.
• Acuerda quién mantendrá las imágenes públicas y durante cuánto tiempo deben permanecer disponibles.
• Registra quién conserva el proyecto visual, quién solicita cambios y cómo se entregarán las nuevas versiones.
• Define quién configura asunto, remitente, respuesta, variables y pie en el sistema del cliente.
• Acuerda las comprobaciones y qué significa la aprobación: diseño, configuración o autorización para enviar.

Si el cliente necesita seguir editando bloques, trátalo como una necesidad independiente. HTML y ZIP no transfieren automáticamente el proyecto nativo de Mailvex, su historial, brandbook ni el acceso a la cuenta. Registra también quién proporciona imágenes y fuentes y quién confirma sus derechos de uso.

2. Elige el formato que sirve para el trabajo

El ZIP que organiza una entrega no necesariamente es el ZIP admitido por el importador del cliente. Conserva el paquete de trabajo y genera otro archivo específico para el sistema de envío solo cuando sea necesario.

3. Finaliza la versión en Mailvex

Utiliza una cuenta con el correo confirmado y revisa la cuota de exportación disponible. Abre el proyecto de la campaña y comprueba contenido, destinos de botones, texto alternativo de imágenes, preheader y pie. Revisa también la vista previa con los iconos de monitor y teléfono. Conserva la firma exigida por el plan.

Detén los cambios de contenido mientras generas los archivos de una misma versión. Elige un nombre como coleccion-escritorio-es-v03. La exportación recompila el proyecto actual; si modificas el diseño entre HTML y ZIP, puedes entregar archivos diferentes con el mismo número de versión.

Abre Exportar HTML. Para una muestra estática, utiliza mailvex en Formato de variables (ESP) y elimina variables de demostración y condiciones innecesarias. En Condición de visibilidad (ESP), desactiva Mostrar según condición en los bloques de la muestra estática. En una campaña real, comprueba la sintaxis exigida por el sistema del cliente. El perfil no conecta la cuenta de envío ni proporciona datos de destinatarios.

En la ruta sencilla, mantén el modo de imágenes Mailvex y selecciona Descargar HTML. Identifica el archivo como coleccion-escritorio-es-v03-send.html. Copiar HTML es una alternativa si el cliente prefiere código. No necesitas utilizar ambas acciones para obtener la misma entrega.

4. Si necesitas el ZIP, comprueba su contenido

Con el modo de imágenes Mailvex, utiliza Descargar ZIP (HTML + imágenes) solo si también forma parte del acuerdo. HTML y ZIP son dos acciones de exportación. EML o nuevos intentos pueden consumir otras; una falla al construir el paquete no demuestra que no se haya contabilizado una exportación.

Extrae una copia del ZIP. El paquete puede incluir email.html, la carpeta images/ y un README.txt cuando hay dependencias externas o fallas que registrar. Las imágenes de Mailvex descargadas correctamente pasan a tener rutas relativas en el HTML del archivo. Las imágenes externas o no disponibles pueden seguir apuntando a internet.

• Abre README.txt cuando exista y registra los recursos que siguen remotos o no se descargaron.
• Comprueba las imágenes presentes y las referencias del HTML, incluidos logotipo, fondos y elementos pequeños.
• No interpretes la ausencia de README.txt como aprobación; registra tus propias comprobaciones.
• Identifica este ZIP como recursos y referencia local, separado del HTML principal con URLs alojadas.

Una ruta como images/foto.jpg puede funcionar al abrir el archivo junto a la carpeta, pero no publica la imagen para quien recibe el correo. El operador debe utilizar un importador compatible o alojar los archivos y generar referencias válidas. No pegues el HTML local del ZIP en el sistema como si ya estuviera listo.

5. Define quién mantiene el alojamiento

Si el HTML principal utiliza URLs de Mailvex o de otro host, documenta esas dependencias. No borres los archivos después de entregar el ZIP: los mensajes enviados siguen apuntando a las URLs anteriores. Tener una copia de los recursos no modifica la dirección que utilizan esos mensajes.

Si el cliente alojará las imágenes, acuerda primero los destinos y sube los archivos. En modo Propio, la base configurada reescribe URLs, pero no carga archivos al servidor. Revisa direcciones finales, enlaces y firma antes de exportar esa versión. Evita sustituciones indiscriminadas de src, CSS o VML.

Abre las imágenes finales sin depender de la sesión del editor y registra quién podrá sustituirlas o eliminarlas. La decisión incluye continuidad y mantenimiento; este procedimiento no establece alojamiento permanente. Una entrega con migración pendiente debe indicarlo claramente.

6. Entrega una referencia visual con límites claros

Para una vista previa pública, utiliza el menú …, Más, y Compartir. En Enlace público de vista previa, copia la URL y mantén desactivado Permitir comentarios por el enlace en este proceso. Quien tiene el enlace puede verlo y reenviarlo; no obtiene edición del proyecto ni un portal cerrado de aprobación.

La misma URL puede recibir otra versión al compartir nuevamente; una exportación con la visualización en el navegador activada también puede actualizar esa copia. Por eso, el enlace no es un registro inmutable de la versión aprobada. Conserva los archivos identificados y una captura fechada, indicando si proviene del navegador o de un mensaje recibido.

Una imagen PNG de referencia puede acompañar el paquete, como captura realizada con funciones del navegador o del sistema. No demuestra pruebas en todos los clientes. Registra la aprobación mediante el proceso acordado con el cliente, vinculada a la versión de los archivos y sin depender de comentarios en la vista previa.

Si el cliente solicitó EML, utiliza Descargar .eml como salida adicional. Puede incorporar imágenes de Mailvex obtenidas correctamente y conservar otros recursos remotos. Sus encabezados de ejemplo no autorizan el envío en nombre del cliente. Abrirlo no equivale a instalar una plantilla ni a obtener un borrador editable en cualquier aplicación.

7. Incluye un README breve y utilizable

Tú redactas el README de entrega; complementa cualquier informe técnico del ZIP. El ejemplo siguiente utiliza una campaña ficticia. Sustituye nombres, responsables, fecha y estados por lo que realmente se acordó y observó. No incluyas credenciales.

Entrega: colección para escritorio. Idioma: es-LATAM. Versión: v03. Fecha: 2026-10-25, utilizada como ejemplo. Archivo principal: coleccion-escritorio-es-v03-send.html. Sistema de envío: COMPLETAR. Responsable de importar: COMPLETAR.

Asunto sugerido: Conoce la colección para tu escritorio. Preheader: Descubre organizadores y soportes en la tienda. Remitente y dirección de respuesta: configurar y confirmar en el sistema de envío.

Recursos opcionales: coleccion-escritorio-es-v03-assets.zip; referencia: preview-escritorio-es-v03.png. El ZIP es material de apoyo, no el archivo principal de envío. Alojamiento y mantenimiento de imágenes: COMPLETAR responsable y dependencias. Proyecto editable Mailvex y próximos cambios: COMPLETAR responsable.

Personalización: muestra estática. Variables, baja y pie obligatorio: validar en el sistema acordado. Pruebas de este modelo de README: no realizadas. Registrar después archivos, clientes de correo y resultados observados. Aprobación y siguiente paso: PENDIENTES.

Guarda este documento como README-entrega-es-v03.txt. Si creas un archivo exterior que reúne HTML, recursos y referencias, identifícalo como paquete de entrega. Conserva el contenido del ZIP original; puede incluir sus propias instrucciones sobre archivos que no se incorporaron.

8. Cierra la entrega con comprobaciones y responsables

El operador autorizado debe importar el HTML principal en el sistema real y enviar una prueba a un buzón propio controlado. Revisa el mensaje recibido en celular y computadora, en los clientes utilizados por el público. Algunos modos de prueba no completan datos individuales; registra por separado la validación de variables y valores ausentes con las herramientas apropiadas de la plataforma.

Registra los ajustes antes de dar la entrega por terminada. Si modificas el proyecto, crea otra versión, exporta y sustituye la copia importada. Editar en Mailvex no actualiza el archivo que el cliente ya recibió. Indica exactamente qué versión reemplaza a la anterior.

Preguntas y problemas frecuentes

La entrega queda clara cuando el cliente sabe qué importar, qué consultar y quién realizará el próximo cambio. Un paquete pequeño con estas decisiones registradas resulta más útil que varios formatos sin una finalidad definida.