Creativo
Un documento, no una plantilla
Lo que escribes es un árbol de bloques con un esquema publicado. Lo que sale es ese documento renderizado para un destino — correo, página, formulario, SMS, push o impresión. Los dos están separados a propósito, porque el editor es reemplazable y el renderizado no, y fingir lo contrario es como una herramienta de marketing acaba con seis versiones del mismo mensaje que ya no coinciden.
Seis destinos, una fuente
Cada destino tiene restricciones que no son cuestión de gusto, y el renderizador las conoce para que tú no tengas que hacerlo.
Correo significa tablas y CSS en línea, sin flex ni grid porque Outlook sigue usando Word para maquetar el correo, una alternativa en texto plano generada por ti, colores que sobreviven a un cliente en modo oscuro que invierte todo, y un guardián de tamaño en unos 102 KB, donde Gmail empieza a recortar.
Página significa HTML moderno y responsivo de toda la vida, publicado bajo un slug, en tu propio dominio si quieres uno. Formulario es una página más vinculaciones de campos, validación, un honeypot y un límite de frecuencia — y es la única vía de entrada a tus contactos que puede producir legítimamente una base de consent.
SMS cuenta los segmentos mientras escribes. Push es un título, un cuerpo, un icono, acciones y un deep link. Carta es CSS de impresión renderizado a un PDF, dirigido y enviado por correo postal.
El documento en sí se almacena como un setup con un esquema publicado, en el servicio de documentos del ecosistema en lugar de oculto en una tabla privada. Lo que significa que el día que llegue un editor mejor, edita los mismos documentos y no cambia nada aguas arriba.
- 1correoTablas, CSS en línea, alternativa en texto, seguro en modo oscuro, guardián de ~102 KB.
- 2páginaHTML responsivo bajo un slug, en tu dominio.
- 3formularioPágina más vinculaciones, validación, honeypot, límite de frecuencia.
- 4smsTexto con un contador de segmentos GSM-7 / UCS-2 en vivo.
- 5pushTítulo, cuerpo, icono, acciones, enlace profundo.
- 6cartaCSS de impresión → PDF.
- iLa costuraEl editor es sustituible; los destinos no. Por eso el documento tiene un esquema publicado.
Salida renderizada cacheada por destino
Variables de fusión
Una variable desconocida falla al publicar, no silenciosamente al enviar
El comportamiento predeterminado de todo lenguaje de plantillas ante una clave ausente es no renderizar nada. En un correo eso significa un «Hola ,» enviado a cuarenta mil personas, y nadie se entera hasta que empiezan a llegar las respuestas. Así que un documento se valida contra el vocabulario de variables antes de poder publicarse.
Qué puedes interpolar
El correo electrónico, el nombre, el teléfono y la configuración regional del contacto; attrs.*, que está abierto porque los atributos son tuyos; el nombre y la dirección postal de tu organización; los enlaces de baja y de preferencias; y el asunto y la preheader del propio mensaje.
Deliberadamente una lista y no «cualquier cosa del registro». Una fila de contacto también lleva identificadores internos, y ninguno de ellos pertenece a un mensaje.
Un valor de respaldo no es una variable ausente
{{first_name | default:there}} es una variable conocida que este contacto en concreto no tiene: una lista importada en la que la mitad de las filas no tenían nombre. Eso renderiza el respaldo y está perfectamente bien.
Lo que se rechaza es {{frist_name}}: una variable que no existe para nadie. A la hora de enviar, ambos se ven idénticos. A la hora de publicar no podrían ser más distintos, y por eso la comprobación se hace allí.
El mismo vocabulario funciona en todos los destinos, así que una frase escrita para un correo se renderiza en el SMS y en la página de aterrizaje sin reescribirla. Y first_name se deriva al renderizar a partir del nombre completo en lugar de almacenarse, porque una división almacenada es una división errónea esperando a la persona cuyo nombre no encaja con la suposición.

Escríbelo una vez. Llega vestido para el canal.
Antes de que salga
Las comprobaciones que ocurren mientras todavía puedes arreglar las cosas
El recorte de Gmail
Por encima de unos 102 KB, Gmail trunca el mensaje y esconde el resto tras un enlace que casi nadie pulsa, incluida, en el fondo del todo, tu opción de baja. El renderizador mide y avisa al publicar.
Peso de las imágenes
Una fotografía principal de cuatro megabytes revienta el presupuesto de tamaño y se renderiza mal en un teléfono. Las imágenes se redimensionan y se convierten al subirlas, lo cual es un asunto de entregabilidad y no un detalle estético.
Vista previa de la bandeja de entrada
El mensaje se renderiza y se fotografía a anchos de escritorio y de móvil, de modo que la vista de lista muestra cómo se ve realmente la cosa y no su nombre. Sin servicios de vista previa de pago.
Un envío de prueba real
Envíatelo a ti mismo, por el mismo renderizador y la misma identidad de envío que recibiría un destinatario real. Una vista previa que sigue otro camino de código no prueba nada sobre el mensaje que se envía.
El HTML pegado se depura
El contenido pegado desde otro sitio pasa por un depurador antes de almacenarse, porque un correo de marketing no es el lugar para descubrir qué había en el portapapeles de alguien.
Markdown, si lo prefieres
Escribe en Markdown y haz que se renderice. Mucho más fiable que pedirle HTML de correo a un modelo, y es lo que hace que un agente que escribe un mensaje sea una idea viable y no una demo.
Empezando desde tu propio sitio web
Pega una URL en tu primer uso. ClickSomo lee la página en busca de su logotipo, sus iconos, su manifiesto y sus colores medidos —no colores que alguien haya imaginado— y construye un primer correo que ya se parece al tuyo. También detecta la plataforma, lo que suele bastar para sugerir un embudo que merece la pena: a una tienda le toca el carrito abandonado, a un editor la bienvenida al boletín.
Cada descarga de una URL que tú suministras pasa por un descargador protegido: solo HTTP y HTTPS, las direcciones literales se comprueban directamente, cada respuesta DNS debe ser pública y cada salto de redirección se revalida. Descargar URLs arbitrarias en nombre de un cliente es una de las formas más fáciles de abrir un agujero en tu propia red, y no es algo que deba escribirse dos veces.
La parte honesta: una primera plantilla generada a partir de tu sitio web es un buen comienzo, no un diseño terminado. Acierta más o menos con el logotipo, los colores y la tipografía para que tu primer envío no parezca una demo, y luego la editas tú, que es un trabajo mucho mejor que quedarte mirando un lienzo vacío.