En un producto SaaS, el onboarding suele medirse con una pregunta demasiado pequeña: ¿el usuario verificó su correo? La verificación importa, pero no es el valor del producto. Un proveedor puede tardar, un enlace puede llegar a spam o una persona puede querer explorar antes de entregar una dirección real.

La idea que me ha resultado mas util es separar la activación en dos fronteras: una frontera de producto, donde la persona puede probar el primer valor, y una frontera de confianza, donde el backend decide qué acciones necesitan un correo verificado. Este diseño hace el flujo más amable y también mas facil de diagnosticar.

El onboarding no termina cuando se pulsa el botón

Imagina una aplicación que ayuda a un equipo a organizar sus tareas. Después de crear una cuenta, la persona debería poder importar un ejemplo, crear una tarea y ver un pequeño resultado. Si bloqueamos todo hasta que llegue un email, convertimos un problema de entrega en un problema de producto.

Eso no significa ignorar la seguridad. Significa clasificar las acciones:

  • Bajo riesgo: ver un ejemplo, completar un tutorial y crear datos de demostración.
  • Riesgo medio: invitar a un compañero, conectar una integración o guardar preferencias importantes.
  • Alto riesgo: exportar datos, cambiar el propietario o iniciar un plan de pago.

El correo verificado puede ser requisito para la segunda o tercera categoría. La primera debería ser rápida, reversible y aislada.

Define una frontera de confianza

Antes de escribir código, dibuja los estados que el backend conoce. Una versión simple podría ser:

created -> exploring -> email_pending -> verified \-> expired

exploring no significa que el usuario sea de confianza plena. Solo indica que tiene un espacio de prueba limitado. Cada cuenta puede recibir datos semilla, límites de tiempo y una cuota pequeña. Al verificar el correo, el sistema amplía los permisos y conserva el progreso.

La parte importante es que el frontend no invente el estado. El backend debe responder con capacidades explícitas, por ejemplo canInviteMembers o canExportData. Así, una pantalla no queda desbloqueada por accidente solo porque alguien ocultó un botón. Es una regla sencilla, pero se olvida facil cuando el equipo crece.

Para probar estos estados, usa datos de prueba aislados. Un generador de correos desechables o un correo temporal desechable puede servir en un entorno controlado, siempre que no contenga información real y que cada ejecución tenga su propio identificador. No reutilices una bandeja compartida: un enlace viejo puede hacer que una prueba parezca correcta.

Si tu equipo mantiene servicios de correo con FastAPI, también puede ser útil depurar reintentos de correo y usar emails aislados por branch para que cada cambio tenga evidencia propia.

Un flujo paso a paso para el backend

  1. Crea una sesión de onboarding. Guarda un onboarding_id, el momento de creación y una fecha de expiración. No mezcles este registro con el perfil definitivo.
  2. Entrega un primer resultado. Permite una acción pequeña que demuestre el valor del producto. Debe poder repetirse sin consecuencias.
  3. Emite un desafío de correo. Genera un token de un solo uso con expiración corta. Guarda solo lo necesario para encontrarlo y revocarlo.
  4. Registra la entrega como señal. Distingue entre queued, sent, opened, clicked y verified. Enviar no es verificar.
  5. Amplía capacidades después de verificar. El endpoint debe comprobar el estado en el servidor, no confiar en un campo enviado por el navegador.
  6. Limpia lo que caduca. Los espacios abandonados, tokens y mensajes de prueba necesitan una tarea de limpieza. Sin ella, el sistema acumula ruido y datos que nadie sabe ya de quien son.

El contrato puede ser pequeño:

{ "onboarding": "exploring", "email": "pending", "capabilities": { "canCreateDemo": true, "canInviteMembers": false, "canExportData": false } }

Cuando una llamada devuelve esta información, la interfaz puede explicar el siguiente paso en vez de mostrar un error generico.

Mide señales, no solo correos enviados

Una métrica de activación útil une el correo con el comportamiento posterior. Por ejemplo: porcentaje de sesiones que llegan a un primer resultado dentro de 15 minutos, tiempo entre registro y primer resultado, y porcentaje que verifica después de probar la aplicación.

También conviene medir dónde se rompe el camino. Un panel mínimo puede mostrar:

  • sesiones creadas;
  • sesiones que iniciaron una acción de valor;
  • desafíos emitidos y expirados;
  • verificaciones completadas;
  • cuentas que abandonaron después de pedir el correo.

Con esos datos, puedes descubrir que el problema no es la tasa de entrega. Quizá el mensaje llega, pero la persona no entiende por que debe abrirlo. O quizá el usuario ya obtuvo el valor y no necesita verificar todavía.

Errores comunes al diseñar la activación

El primer error es llamar “usuario activo” a cualquiera que hizo clic en el email. Un clic no prueba que haya usado el producto. El segundo es borrar todo el progreso cuando el token expira; eso castiga a quien vuelve tarde. Es mejor emitir un desafío nuevo y conservar los datos seguros del onboarding.

Otro error es poner la dirección de prueba en logs sin control. Frases como temp org mail o tem email pueden aparecer en un test, pero no deberían mezclarse con métricas de clientes. Etiqueta el entorno y elimina los datos cuando ya no hagan falta.

Finalmente, no escondas los estados. Un mensaje como “revisa tu correo” es poco útil si el backend sabe que el envío está en cola. Di qué pasó, qué puede hacer la persona mientras espera y cómo pedir otro enlace. Eso reduce soporte y hace el producto se sienta más confiable.

Checklist de repaso

  • ¿El usuario puede ver un primer valor sin bloquearse por la entrega?
  • ¿Cada capacidad sensible se comprueba en el backend?
  • ¿Los tokens tienen expiración, revocación y un solo uso?
  • ¿Las pruebas usan buzones y datos aislados por ejecución?
  • ¿Mides sent, clicked y verified como señales diferentes?
  • ¿El onboarding caducado se limpia sin borrar datos válidos?
  • ¿La interfaz explica el estado siguiente con palabras claras?

Una frontera de confianza bien definida no elimina el correo del onboarding. Lo pone en el lugar correcto: como una señal que habilita más confianza, no como una puerta que impide conocer el producto.