«v2.14.3: fix en el parser de webhooks, refactor del módulo de facturación, bump de dependencias.» Así son muchas notas de versión de SaaS. Las escribe quien hizo el cambio, para quien hizo el cambio, y el cliente que las lee no saca nada en claro: ¿ya funciona lo que le fallaba? ¿Hay algo nuevo que le sirva?
Las notas de versión son de lo poco que un SaaS cuenta a todos sus clientes de forma regular. Bien escritas, enseñan que el producto avanza, reducen preguntas y cierran el círculo con quien pidió algo o reportó un fallo. Mal escritas, nadie las lee.
La respuesta corta
Unas buenas notas de versión explican qué cambia para el cliente, no qué cambió en el código. Cada entrada dice qué puede hacer ahora el cliente o qué problema ya no tendrá, en una o dos frases, con una captura o un enlace si ayuda. Se agrupan en novedades, mejoras y correcciones, se fechan y se publican en un changelog accesible. Lo importante se avisa además dentro del producto o por correo, y a los clientes que pidieron algo o reportaron un fallo se les avisa personalmente.
Qué cambia para el cliente
La regla de oro: cada entrada responde a «¿y a mí qué?».
| Mal | Bien |
|---|---|
| Refactor del módulo de exportación | Las exportaciones grandes ahora tardan segundos en vez de minutos |
| Fix en el parser de webhooks | Los webhooks con caracteres especiales ya no fallan |
| Nuevo endpoint /invoices/bulk | Ahora puedes crear varias facturas a la vez desde la API |
| Mejoras de rendimiento | El panel principal carga el doble de rápido con muchos proyectos |
Si un cambio no cambia nada para el cliente —una dependencia actualizada, una limpieza interna—, no va en las notas de versión.
Qué incluir
- Novedades: funciones nuevas. Con una captura o un vídeo corto si son visuales.
- Mejoras: cosas que ya existían y ahora funcionan mejor.
- Correcciones: fallos que los clientes podían notar.
- Cambios que exigen algo del cliente: algo que deja de funcionar, una configuración que hay que revisar. Estos, arriba y destacados.
Cada entrada, con:
- Un título que diga el beneficio.
- Una o dos frases con lo necesario para entenderlo.
- Dónde encontrarlo o un enlace a la ayuda.
- Para quién, si no es para todos: «disponible en el plan Pro».
Ejemplo de una entrada
Duplica un proyecto con todas sus tareas
Ahora puedes copiar un proyecto entero —tareas, responsables y plantillas— desde el menú del proyecto → Duplicar. Útil si repites el mismo trabajo para cada cliente. Disponible en todos los planes.
Y una corrección:
Las facturas con descuento del 100 % ya se guardan bien
Antes, aplicar un descuento del 100 % daba un error al guardar. Ya está corregido; si usabas el 99,99 % como alternativa, ya no hace falta.
Dónde publicarlas
- Una página de changelog pública, con fecha y en orden inverso: lo último arriba. Sirve también a quien está evaluando el producto, como prueba de que avanza.
- Dentro del producto, para lo importante: un aviso discreto o un punto en el menú.
- Por correo, un resumen mensual o trimestral, no un correo por cada cambio.
Cuánta comunicación necesita cada cambio:
| Cambio | Changelog | En el producto | Correo |
|---|---|---|---|
| Corrección menor | Sí | No | No |
| Mejora notable | Sí | A veces | En el resumen |
| Novedad importante | Sí | Sí | Sí |
| Cambio que exige acción | Sí | Sí | Sí, con antelación |
Cerrar el círculo
Las notas de versión son la oportunidad de cerrar dos círculos que casi siempre se quedan abiertos:
- Las peticiones de funcionalidades. Si alguien pidió duplicar proyectos hace tres meses, merece un mensaje personal cuando sale. Más en cómo gestionar las peticiones de funcionalidades.
- Los fallos reportados. Quien reportó un fallo y recibe un «ya está arreglado, gracias por avisar» es un cliente que volverá a reportar. Cómo recogerlos bien está en cómo conseguir reportes de bugs útiles.
Para hacerlo hace falta que las peticiones y los fallos estén registrados con los clientes que los pidieron. Con eso, avisar es cuestión de minutos.
Notas de versión y soporte
Una nota de versión clara reduce preguntas: «¿por qué ha cambiado este botón?» se responde antes de que nadie la haga. Pero soporte tiene que conocer los cambios antes de que salgan, no enterarse por los clientes. Y si atiende un agente de IA, la documentación que consulta tiene que estar actualizada el mismo día: un agente que explica cómo se hacía algo antes del cambio genera más confusión que nada.
En Intake, los avisos dentro del producto pueden dirigirse según el plan, los ajustes o el uso de cada cuenta, para que una novedad del plan Pro no aparezca a quien no la tiene. Más en mensajes.
Errores frecuentes
- Escribir para el equipo técnico en vez de para el cliente.
- Mezclar lo interno con lo visible.
- No avisar de los cambios que rompen algo hasta que rompen.
- Un correo por cada cambio, que acaba ignorado o en spam.
- No actualizar la documentación a la vez.
Preguntas frecuentes
¿Qué son las notas de versión?
El registro de lo que cambia en cada versión de un producto, escrito para sus usuarios: novedades, mejoras y correcciones.
¿Qué diferencia hay entre changelog y notas de versión?
En la práctica se usan como sinónimos. A veces el changelog es el registro completo y técnico, y las notas de versión, la versión para clientes.
¿Cada cuánto hay que publicarlas?
Cada vez que hay algo que cambia para el cliente, y un resumen por correo cada mes o cada trimestre.
¿Hay que incluir las correcciones de fallos?
Las que los clientes podían notar, sí. Son de las entradas que más se agradecen.
¿Cómo aviso de un cambio que obliga al cliente a hacer algo?
Con antelación, destacado en el changelog, dentro del producto y por correo, explicando qué tiene que hacer y hasta cuándo.
