La plantilla de email de novedades que sí se lee

El email de novedades del producto que se lee es el que se envía a alguien que pidió exactamente lo que anuncia. Todo lo demás compite con el resto de la bandeja de entrada en interés, una competición que un anuncio de release pierde la mayoría de semanas. Ese único hecho debería decidir la forma del email antes que cualquier redacción: quién lo recibe, y qué hizo esa persona para acabar en la lista.

¿Qué es un email de novedades del producto?

Es un mensaje que le dice a usuarios existentes qué cambió en un producto que ya usan. Hay cuatro tipos distintos, y tratarlos como una sola lista es por qué las tasas de apertura decaen. Cada uno tiene un disparador distinto, un público distinto y una frecuencia aceptable distinta.

La mayoría de equipos solo construyen el tercero, lo mandan a todos, y concluyen que los emails de novedades no funcionan. Los dos primeros cargan casi todo el valor, porque el lector tiene un motivo previo para interesarse, y el mensaje llega mientras ese motivo está vivo.

Las cuatro filas de aquí están escritas para clientas. Ventas, soporte y customer success también necesitan saber qué se lanzó, casi siempre en una forma distinta a cualquiera de estas cuatro; notas de release internas cubre qué debería decir ese documento y por qué tiene que salir antes que la nota de cara al cliente.

El email es uno de varios canales que un anuncio de lanzamiento puede usar, no el único. Cómo anunciar una función nueva cubre los demás, y cómo elegir entre ellos según lo grande que sea la función.

¿Qué va en la plantilla?

Seis bloques, en este orden. El primero es el que suele faltar y el que hace el trabajo.

Asunto:  <qué cambió, con las palabras del lector>

1. Por qué te llega esto
   "Pediste exportación a CSV en marzo." o
   "Tu integración llama a /v1/invoices, que cambia el 15 de enero."

2. Qué cambió
   Una frase. Qué es posible ahora, o qué se rompe ahora.

3. Qué tienes que hacer
   A menudo "nada". Dilo explícitamente, no lo dejes implícito.

4. Dónde verlo
   Un enlace a la entrada del changelog, no a la portada.

5. Cuándo
   La fecha en que se lanzó, o desde cuándo aplica.

6. Cómo dejar de recibirlos
   Un clic, y respetado al instante.

El bloque 1 es la diferencia entre un mensaje y una difusión general. Un lector al que se le dice, en la primera línea, que esto es la resolución de algo que él mismo pidió, lee el resto. Sin él, los bloques 2 a 5 son un newsletter por bien escritos que estén.

Mantened el conjunto bajo unas 150 palabras. El email es un puntero a la entrada del changelog, y la entrada es donde va el detalle. Un email que reproduce la entrada entera no le da al lector motivo para hacer clic, ni a vosotros señal de si le importó a alguien.

¿Qué líneas de asunto funcionan?

Nombrad el cambio, no la versión. “La exportación a CSV ya está” gana a “novedades de septiembre” porque lo primero es un hecho que el lector puede evaluar y lo segundo es un contenedor. Los números de versión en el asunto son útiles para consumidores de una API y ruido para todos los demás, otra razón para separar los públicos.

Evitad afirmar un beneficio al que el lector no ha dado su consentimiento. “Tus informes ahora son más rápidos” afirma algo sobre su experiencia; “Los informes de más de 10.000 filas ahora cargan en menos de un segundo” reporta un cambio y le deja decidir si le importa.

¿Cuándo enviar uno, y a quién?

Enviad una notificación dirigida en el momento en que la cosa se lanza, a las personas que la pidieron, individualmente. Enviad un aviso de breaking change tan pronto como la fecha sea segura y otra vez cerca de ella, a las cuentas realmente afectadas en lugar de a toda la lista. Enviad un digest solo si tenéis suficientes cambios como para que un lector se pierda algo si no, y dejad que la gente se apunte por separado.

La lista que casi nunca deberíais usar es “todos los usuarios”. Convierte un mensaje concreto en uno genérico, y entrena la baja. Segmentad por comportamiento que ya almacenáis: quién lo pidió, quién usa este endpoint, quién está en este plan.

¿Necesitáis consentimiento para enviarlo?

Para clientes existentes, una novedad sobre un servicio que usan suele ser una cuestión legal distinta del marketing a un prospecto, y la respuesta depende de dónde estén y de qué les dijisteis al registrarse. En la UE la pregunta relevante es qué base legal del artículo 6 del RGPD aplica, y en Estados Unidos los mensajes comerciales llevan requisitos concretos recogidos en la guía de cumplimiento CAN-SPAM de la FTC. Ambas exigen lo mismo en la práctica: decid quiénes sois, dejad claro el propósito, y dejad que la gente pueda parar.

Sea cual sea la base, mantened separados los flujos transaccional y de marketing a nivel de envío. Un aviso de breaking change que un cliente ha dado de baja porque compartía lista con un digest promocional es un incidente de soporte esperando su fecha.

¿Cómo queda rellena?

La notificación dirigida, el email de novedades de más valor y el que la mayoría de equipos nunca construye:

Asunto: La exportación a CSV ya está aquí

Hola Dana,

pediste exportación a CSV allá por marzo.

Se lanzó esta mañana. Los informes ahora tienen un botón de
exportar que genera un CSV de la vista actual, filtros
incluidos.

No tienes que hacer nada por tu parte. Ya está activo en tu
cuenta.

  Detalles: example.com/changelog#csv-export
  Lanzado: 2 de septiembre de 2026

Recibes esto porque lo pediste. Darte de baja de novedades de
peticiones: <enlace>

Noventa palabras, y el lector sabe en la primera línea por qué le llegó. Comparad esto con el mismo cambio en un digest mensual, donde aparece como uno de nueve puntos y Dana no tiene motivo para notar que su propia petición salió.

¿Qué deberíais medir?

No la tasa de apertura sola. Para una notificación dirigida la pregunta es si la persona que pidió volvió y usó la cosa, así que el número que importa vigilar es el clic hacia la entrada y si esa cuenta usa la función en la semana siguiente. Para un aviso de breaking change es cobertura: qué porcentaje de cuentas afectadas abrió antes de la fecha, y con quién hicisteis seguimiento individual.

Un digest es el único de los cuatro donde una tasa de apertura significa algo, e incluso ahí es más útil como tendencia contra su propio historial que contra un benchmark del sector. Distintos tipos de email de novedades tienen trabajos distintos, así que una cifra mezclada entre todos no describe nada sobre lo que se pueda actuar.

¿En qué se diferencia de las notas de versión?

Las notas de versión son un documento que permanece disponible. El email es un mecanismo de entrega que pasa una vez. El mismo cambio produce ambos, y el email debería ser más corto que la entrada a la que enlaza. Buenas prácticas de notas de versión cubre el documento, y changelog vs notas de versión cubre cuál estáis escribiendo.

La relación que conviene acertar: la entrada del changelog es el texto canónico y el email lo cita. Cuando esos dos divergen, el lector que hace clic encuentra una descripción distinta del cambio y deja de confiar en ambos. Publicar la entrada primero y generar el email a partir de ella elimina la divergencia por construcción. changeloop funciona igual por su lado: una entrada se revisa y publica una vez en la página, el feed y el widget, y a quien la pidió a través del widget se le avisa en el issue de GitHub en que se convirtió su feedback, y en el propio widget. changeloop no envía el email; tu herramienta de email cita la entrada publicada.

FAQ

¿Con qué frecuencia debería salir un email de novedades del producto? Tan a menudo como haya algo concreto que el destinatario quiera saber, que para una notificación dirigida es cada vez que se lanza su petición y para un digest es mensual como mucho.

¿Debería el email contener la entrada de changelog entera? No. Una frase y un enlace. La entrada es la versión canónica, y una copia completa en el email significa dos textos que mantener alineados.

¿Qué tasa de apertura debería esperar? Comparad cada tipo contra sí mismo en lugar de contra un benchmark. Una notificación dirigida y un digest mensual son productos distintos, y promediarlos esconde la única cifra que merece la pena observar.

¿Necesito una lista separada para breaking changes? Sí, y debería ser la que la gente no pueda darse de baja casualmente sin entender la consecuencia, porque es la que les cuesta una caída.

Las afirmaciones técnicas de este artículo no se han revisado de forma independiente. Si algo está mal, avísanos y lo corregiremos.

Relacionado en changeloop: Ejemplos de changelog, Documentación para desarrolladores