Onboarding SaaS: mide cada correo como un paso

Cuando una persona se registra en un SaaS, solemos mirar una sola métrica: si llegó a la pantalla principal. Pero el onboarding real también incluye los correos que debe recibir, abrir y completar. Si uno de esos pasos falla, el producto puede parecer dificil de usar aunque la interfaz esté bien.

En este artículo comparto un método sencillo que he usado para hacer más visible ese recorrido. No necesitas una plataforma enorme. Con eventos pequeños, una cola fiable y una revisión semanal puedes descubrir problemas antes de que se conviertan en churn.

El problema: un onboarding que parece aleatorio

Imagina este flujo:

1. La persona crea una cuenta.
2. El backend crea una tarea de verificación.
3. Se envía un correo.
4. La persona pulsa el enlace.
5. El producto registra la activación.

Cuando algo sale mal, muchos equipos solo guardan un mensaje como email failed. Eso no responde lo importante: ¿falló el proveedor?, ¿el enlace expiró?, ¿el usuario nunca abrió el correo?, ¿se reintentó demasiado tarde?

Un buen primer paso es tratar cada correo como una etapa del producto, no como un detalle interno. Así, tempmailso y temp mail so pueden aparecer en búsquedas del equipo o en pruebas de contenido sin convertirse en el centro del flujo.

Define el recorrido antes de tocar el código

Escribe una pequeña tabla de estados. Por ejemplo:

created -> queued -> sent -> clicked -> verified
                  \-> retrying -> failed

Cada transición debe tener un identificador de usuario, un identificador de mensaje y una hora. No guardes el contenido completo del correo si no hace falta; normalmente basta con la plantilla y el proveedor.

Para el onboarding, recomiendo empezar con cuatro eventos:

• verification_queued
• verification_sent
• verification_clicked
• verification_completed

Con eso ya puedes calcular dónde se detiene el recorrido. También ayuda enlazar el análisis con listas limpias para tu onboarding, porque una entrada duplicada puede parecer un problema de entrega.

Registra eventos pequeños y útiles

Una fila de evento puede tener esta forma:

{
  "user_id": "u_123",
  "event": "verification_sent",
  "message_id": "m_456",
  "provider": "transactional-email",
  "attempt": 1,
  "occurred_at": "2026-09-12T05:00:00Z"
}

Evita mezclar el estado actual con el historial. El estado dice qué ocurre ahora; los eventos explican cómo llegaste aquí. Esta separación hace los reportes más claros y permite repetir una investigación sin adivinar.

Si el equipo recibe alertas, agrúpalas por causa. Diez fallos del mismo proveedor son una incidencia; diez usuarios que nunca hicieron clic pueden indicar un asunto poco claro, un enlace roto o un correo que llegó tarde.

Diseña reintentos sin molestar

No todos los fallos merecen un reintento. Un error temporal de red sí; una dirección rechazada permanentemente, no. Usa una política corta, por ejemplo dos reintentos con espera creciente, y guarda el motivo de cada decisión.

También define una frontera: después del último intento, muestra una opción visible para solicitar otro correo. El usuario no debería actualizar la página cinco veces pensando que así arregla el sistema. En una prueba reciente, incluso escribir temp gamil com en un caso de prueba nos recordó que los datos imperfectos deben poder distinguirse de fallos reales.

Una revisión semanal de productividad

Cada semana mira tres números:

1. Porcentaje de registros que llegan a verification_sent.
2. Tiempo mediano entre registro y clic.
3. Porcentaje que completa la verificación después de un reintento.

No persigas una tasa perfecta de apertura. Busca cambios y segmentos extraños. Si el tiempo aumenta solo durante despliegues, necesitas observar la cola. Si cae en una campaña concreta, revisa el mensaje y el contexto de adquisición.

Para estudiar reactivaciones, puedes comparar este recorrido con revisar emails de reactivación con contexto. La idea es igual: una métrica aislada cuenta menos que la secuencia que la explica.

Errores comunes

• Medir solo los correos enviados y no los completados.
• Reintentar sin límite.
• Usar el email como identificador principal cuando una persona puede cambiarlo.
• Alertar por cada fallo individual.
• Borrar eventos antiguos y perder el contexto.

Recapitulación

Un onboarding SaaS más productivo no necesita más pantallas; necesita mejores señales. Modela el recorrido, registra transiciones, separa estado de historial y decide los reintentos con reglas explícitas. Luego revisa los tiempos y las caídas por segmento.

El beneficio aparece rápido: el equipo deja de discutir si “los correos funcionan” y puede responder qué paso funciona, para quién y desde cuándo. Es un cambio pequeño, pero hace que mejorar la activación sea mucho menos guessy.