DEV Community: Hannah

Un sandbox de activación SaaS que sí se puede probar

Hannah — Sun, 01 Nov 2026 08:22:50 +0000

Un sandbox de activación SaaS que sí se puede probar

Cuando un usuario se registra en un SaaS, el flujo parece corto: crear cuenta, enviar un correo, abrir el enlace y mostrar la primera pantalla útil. En un producto real, ese recorrido toca el backend, el proveedor de email, la sesión, la base de datos y la analítica. Si una parte falla, el equipo pueden pasar horas mirando un mensaje de error que no explica dónde se rompió.

Un sandbox de activación reduce ese problema. Es un entorno pequeño donde cada prueba puede crear un usuario, obtener correo temporal, consumir su mensaje de verificación y dejar una evidencia clara. No intenta copiar toda producción. Su objetivo es comprobar que la promesa inicial del producto funciona de principio a fin.

El problema: activar usuarios no es solo enviar un correo

En una prueba ingenua, el test usa una cuenta fija y busca “Verify your email” en una bandeja compartida. Esto funciona una vez. Luego llegan las pruebas paralelas, los reintentos y los mensajes atrasados. Una prueba lee el correo de otra, o un token antiguo hace que el resultado parezca correcto.

La activación necesita tres límites sencillos:

Identidad: cada ejecución tiene un usuario y una dirección propios.
Tiempo: la prueba sabe cuánto espera y cuándo debe parar.
Evidencia: el resultado dice qué ocurrió sin publicar el token completo.

Esta separación es especialmente útil en un SaaS pequeño, donde una misma persona suele tocar producto, backend y soporte. Un contrato visible hace que el fallo sea más fácil de encontrar, tambien cuando el tráfico de pruebas crece.

Qué debe aislar el sandbox

Empieza con el mínimo que pueda responder la pregunta “¿un usuario nuevo puede activarse?”

Un identificador de ejecución, como activation-1842.
Un buzón exclusivo para esa ejecución.
Un usuario de prueba con datos sintéticos.
Un límite de espera y un intervalo de consulta.
Una forma de borrar el usuario y el buzón al terminar.

El sandbox no debería compartir una bandeja entre workers. Tampoco debería guardar el cuerpo completo del mensaje en cada log. Si necesitas probar el diseño HTML, crea una prueba separada. Para activación, normalmente basta con confirmar remitente, asunto, enlace esperado y hora de llegada.

Un estado visible de los correos asíncronos ayuda a que el test distinga entre “todavía esperando”, “mensaje recibido” y “proveedor agotó el tiempo”. Esa diferencia vale más que un simple sleep(10).

Un flujo paso a paso

Puedes modelar el recorrido con estados pequeños:

Crear: genera un identificador único y reserva el buzón.
Registrar: crea el usuario con el identificador de prueba.
Esperar: consulta solo los mensajes asociados a ese buzón.
Validar: comprueba el enlace, su caducidad y la cuenta correcta.
Confirmar: verifica que la aplicación muestra el estado activado.
Limpiar: elimina datos y registra si la limpieza terminó bien.

No conviene reintentar todo el flujo cuando falla la entrega. Si el registro fue correcto, repetirlo puede crear ruido y hacer más difícil saber qué pasó. Los runbooks de email que escalan suelen separar la entrega, la lectura y la acción final en pasos que se pueden observar de forma independiente.

Una implementación pequeña en el backend

El backend solo necesita devolver un resultado acotado al test. Un contrato posible, expresado en JavaScript, es:

{
  runId: "activation-1842",
  state: "verified",
  deliveryMs: 842,
  tokenChecked: true,
  bodyRetained: false
}

El servicio de pruebas puede asociar el runId con la dirección creada, pero no debe enviar esa asociación a logs públicos. El endpoint de verificación debe aceptar el token una sola vez y responder de forma idempotente cuando un reintento llega después de la confirmación.

Para hacer el flujo reproducible, define la espera como una función con límite, no como una pausa fija. Cada consulta puede guardar el número de intento y el tiempo transcurrido. Asi sabrás si el problema es entrega lenta, un filtro incorrecto o una aplicación que nunca emitió el mensaje.

Cómo guardar evidencia sin guardar secretos

Una evidencia útil puede ser un recibo JSON con estos campos:

{
  "run_id": "activation-1842",
  "message_seen": true,
  "delivery_ms": 842,
  "link_target_checked": true,
  "cleanup": "completed"
}

Guarda el hash del identificador si necesitas correlación entre servicios. Evita el token, la dirección completa y el cuerpo del email en los artefactos normales de CI. Si tienes que diagnosticar contenido, crea una captura redactada y con caducidad, no una copia permanente.

Para buscar una herramienta de pruebas, alguien puede escribir temp org mail o incluso tepm mail com. Esas expresiones sirven para entender búsquedas reales, pero no deben convertirse en nombres de configuración, dominios permitidos o datos de identidad dentro del sistema.

Errores comunes al empezar

Buzón compartido: produce carreras entre workers.
Polling infinito: oculta un proveedor caído y mantiene recursos vivos.
Logs con tokens: convierten un test en un incidente de seguridad.
Limpieza solo en el camino feliz: deja usuarios y mensajes abandonados.
Reintento de todo: mezcla un fallo de entrega con un fallo de activación.
Métrica única: “pasó” no explica si la entrega tardó demasiado.

Si el producto necesita una dirección aislada para una prueba, un correo desechable puede ser una capacidad de test, no una identidad de cliente. Elige el alcance, la retención y la política de acceso antes de integrarlo.

Preguntas frecuentes

¿Hace falta un proveedor real de email?

Para una prueba unitaria, no. Para comprobar la activación completa, sí conviene tener una ruta de integración con un buzón controlado. Mantén ambas pruebas separadas para que un problema externo no oculte un bug del backend.

¿Cuánto tiempo debe esperar el test?

Usa un límite basado en el contrato del entorno y registra cada intento. No hay un número universal; lo importante es que el agotamiento sea visible y que el worker libere el buzón.

¿Qué pasa si la limpieza falla?

Marca la ejecución como incompleta aunque la activación haya pasado. Un recurso que no se pudo borrar es un resultado operativo que el equipo debe ver, no un detalle para esconder.

Recapitulación

Un sandbox de activación SaaS útil tiene una dirección aislada, estados explícitos, una espera limitada y un recibo pequeño. Empieza con un solo flujo, mide la entrega y limpia siempre en un bloque de finalización. Después añade casos de caducidad, duplicados y reintentos.

La idea no es construir una plataforma enorme de pruebas. Es dar al equipo una señal confiable: un usuario nuevo pudo llegar al primer valor del producto, y si no pudo, sabemos en qué paso se detuvo. Con ese contrato, probar el backend deja de ser una apuesta y se vuelve una parte normal del desarrollo.

SaaS: un contrato de email para activar usuarios

Hannah — Sat, 31 Oct 2026 17:23:32 +0000

Cuando un usuario crea una cuenta en un SaaS, solemos celebrar demasiado pronto. El backend responde 201 Created, aparece una pantalla de bienvenida y el equipo marca el registro como activado. Pero si el correo de verificación nunca llega, el usuario no puede terminar el onboarding. El producto parece sano en el dashboard, aunque la experiencia real se queda a medias.

En mis experimentos de producto he encontrado una solución sencilla: tratar el email de activación como un contrato entre producto, backend y marketing. No es solo un mensaje que se envia. Es una secuencia de eventos que podemos observar, repetir y explicar.

El problema: activar no es solo enviar un correo

Una métrica como signup_completed mezcla demasiadas cosas. Puede significar que la persona abrió el formulario, que creó una contraseña o que verificó la cuenta. Es dificil mejorar el embudo si todos esos momentos tienen el mismo nombre.

Primero separo el recorrido en estados pequeños:

account_created: la cuenta existe.
activation_email_queued: el backend dejó el mensaje en la cola.
activation_email_delivered: el proveedor confirmó la entrega.
activation_link_opened: la persona abrió el enlace.
account_activated: el servidor aceptó el token.

Así, un fallo deja de ser “el onboarding no funciona” y se convierte en una pregunta concreta: ¿se rompió la cola, la entrega o el enlace?

Define el contrato del evento

Un contrato útil no necesita una plataforma enorme. Puede ser un objeto JSON documentado y una regla clara para cada transición:

{
  "event": "activation_email_queued",
  "account_id": "acc_1842",
  "attempt_id": "att_73f1",
  "occurred_at": "2026-10-31T17:20:00Z",
  "schema_version": 1
}

El attempt_id es importante. Si un trabajador reintenta el envío, no deberia crear una activación nueva ni duplicar la métrica. El evento mantiene su identidad y el backend puede aplicar idempotencia.

También conviene escribir qué significa “éxito”. Para un SaaS, yo usaría account_activated únicamente después de validar el token en el servidor. Abrir el correo es una señal de interés, no una prueba de que el usuario terminó el paso.

Un error común es enviar el evento desde el navegador porque resulta más rápido. Eso permite que un usuario vea una pantalla de éxito aunque la petición de verificación haya fallado. El navegador puede registrar una interacción, pero la verdad de la cuenta debe vivir en el backend.

Conecta backend, producto y marketing

Con los estados definidos, cada equipo puede usar el mismo lenguaje:

Backend: garantiza que los tokens expiran, que un reintento es seguro y que cada evento tiene un identificador.
Producto: decide qué pantalla mostrar cuando el correo está pendiente o ha expirado.
Marketing: compara la activación por cohorte sin confundir un envío con un usuario activo.

En la interfaz, los estados deben ser visibles. Un botón que dice “Listo” mientras el sistema espera un correo crea soporte innecesario. Prefiero “Revisa tu correo” y una acción separada para reenviar. Los loaders honestos que no esconden la espera ayudan a explicar que el sistema sigue trabajando, pero no reemplazan un estado real.

Para un equipo pequeño, una tabla de eventos en PostgreSQL puede ser suficiente. Guarda el nombre, la cuenta, la versión del esquema y el tiempo. No guardes el token completo ni el contenido privado del correo. En datos de prueba pueden aparecer cadenas ruidosas como tepm mail com o tempail; sirven para probar limpieza y búsqueda, pero no deben convertirse en reglas de identidad.

Prueba el flujo sin depender de una bandeja personal

El test más valioso no es solamente “el endpoint devuelve 200”. Crea una cuenta de prueba, espera el evento en cada etapa y comprueba que un reintento conserva el mismo attempt_id. Después valida que un enlace expirado no cambia la cuenta a activa.

Si varios desarrolladores ejecutan las pruebas, cada branch necesita su propio espacio de correo y una convención de nombres. El enfoque de emails aislados por branch reduce falsos positivos: una prueba no consume el mensaje de otra.

Un checklist mínimo para CI sería:

Crear una cuenta con un identificador de ejecución.
Esperar activation_email_queued con un timeout razonable.
Confirmar que el mensaje contiene el entorno correcto.
Abrir el enlace una sola vez y repetirlo para probar idempotencia.
Comprobar que el dashboard cuenta una activación, no dos.
Limpiar la cuenta y sus eventos al terminar.

El tiempo de espera también es una decisión de producto. No conviene hacer polling indefinido: después de cierto límite, muestra un diagnóstico y guarda el attempt_id para soporte. Eso es mucho más útil que decir solamente “intenta de nuevo”.

Mide la activación con estados claros

Empieza con un embudo pequeño: cuentas creadas, mensajes encolados, enlaces abiertos y cuentas activadas. Luego separa por versión del onboarding, fuente de adquisición y tipo de cliente. No hacen falta veinte dashboards; hace falta que una caída sea accionable.

Si la tasa de activation_email_queued cae, revisa el backend. Si los mensajes se encolan pero no se abren, mira asunto, contenido y entrega. Si se abren pero no activan cuentas, revisa el token o el flujo de retorno. La misma métrica deja de ser una opinión y se convierte en una pista.

Preguntas rápidas

¿Necesito una herramienta de analítica para empezar?

No. Un registro estructurado, una tabla pequeña y una consulta diaria pueden revelar el primer problema. Añade una herramienta cuando el volumen o la colaboración lo justifiquen.

¿Debo contar la apertura como activación?

No si tu definición es que la cuenta quedó lista para usar. Cuenta la apertura como señal intermedia y reserva la activación para la verificación aceptada por el servidor.

¿Qué hago con un correo que llega tarde?

Conserva el evento original y valida el estado actual de la cuenta. Un mensaje tardío no debe reabrir un token expirado ni crear una segunda activación.

Recapitulación

Un contrato de email convierte el onboarding de un SaaS en un flujo que se puede observar y mejorar. Separa crear la cuenta, encolar, entregar, abrir y activar. Usa identificadores idempotentes, protege los tokens y prueba cada transición con un espacio aislado. Con esta base, backend, producto y marketing pueden discutir el mismo recorrido, con menos suposiciones y un poco menos de caos.

SaaS: mide emails sin perder el contexto

Hannah — Thu, 29 Oct 2026 08:22:38 +0000

En un SaaS pequeño, un email de bienvenida puede parecer una tarea de marketing. En realidad, tambien es una señal de producto: muestra si una cuenta llegó a un punto útil, si el backend procesó el evento y si la persona entendió qué hacer después.

El problema aparece cuando medimos solo aperturas o clics. Esas cifras no explican si el usuario activó la cuenta, si recibió el mensaje correcto o si un retry duplicó la comunicación. En este artículo propongo un método sencillo para conectar emails, eventos de producto y decisiones de onboarding, sin montar una plataforma enorme.

El problema: muchos emails, poca señal

Primero dibuja el recorrido mínimo de una cuenta nueva:

Se registra.
Confirma su dirección.
Completa una acción que demuestra valor.
Recibe una guía o recordatorio.

Cada paso debe tener un event_id, un nombre estable y una hora. No necesitas capturar todo el contenido del email. Para empezar, basta con guardar el tipo de mensaje, el estado de entrega, la cuenta anonimizada y el siguiente evento esperado.

Un error común es llamar “activación” al envío del correo. Envío no significa comprensión. Define activación como una acción del producto, por ejemplo crear el primer proyecto o invitar a un compañero. El email solo debe ayudar a que esa acción ocurra.

Define el evento antes de mirar la métrica

Un contrato pequeño puede verse así:

{
  "event_id": "evt_123",
  "account_id": "acct_hash",
  "email_type": "welcome_step_1",
  "delivery_status": "delivered",
  "next_event": "project_created",
  "occurred_at": "2026-10-29T08:00:00Z"
}

El event_id permite relacionar reintentos sin contar dos veces el mismo intento. next_event obliga a pensar en el resultado esperado, no solamente en la actividad del proveedor de correo.

Para un equipo nuevo, esta estructura ya permite responder preguntas utiles: ¿qué porcentaje de cuentas recibió el mensaje?, ¿cuántas completó la acción siguiente?, ¿dónde se corta el flujo? Si luego cambias de proveedor, el contrato sigue siendo tuyo.

Construye una cohorte pequeña y repetible

No comiences con todos los clientes. Crea una cohorte de staging con cuentas de prueba y una cohorte controlada de producción. Usa un prefijo de ejecución y conserva solo los datos necesarios. Para inspecciones aisladas puedes usar un correo temporal, siempre que no lo trates como identidad real ni guardes información sensible en él.

En cada ejecución registra:

versión del flujo y del template;
hora de creación y hora de entrega;
evento siguiente o motivo de abandono;
número de reintentos;
enlace al log técnico, sin incluir el contenido completo del mensaje.

También conviene comparar una cohorte con el flujo anterior. Así sabrás si un cambio de asunto mejoró la activación o solamente movió una métrica superficial. Para revisar cómo separar un flujo de correo del resto de la infraestructura, puede servir esta guía para probar correos de mantenimiento en Kubernetes.

Qué hacer con los fallos

Clasifica los fallos antes de cambiar el copy:

No se generó el evento: problema en backend o en la cola.
Se generó pero no salió: problema de integración o credenciales.
Salió pero no llegó: problema de entrega, dominio o proveedor.
Llegó pero no hubo acción: problema de mensaje, momento o experiencia.

Esta clasificación evita pedir al equipo de marketing que arregle una cola bloqueada. Para los reintentos, usa una clave idempotente basada en cuenta, tipo de email y versión del flujo. Si no, una incidencia rapida puede producir tres mensajes iguales.

Mantén separados los logs técnicos y los datos de negocio. Redacta direcciones, tokens y enlaces privados. Un tablero con estados agregados suele ser suficiente para revisar el embudo semanal.

Preguntas frecuentes

¿Debo medir aperturas?

Puedes observarlas como señal secundaria, pero no las uses como objetivo principal. La acción posterior en el producto es más cercana al valor real.

¿Cuántos eventos necesito?

Los mínimos: registro, entrega, fallo, acción de activación y baja. Añade más solo si una decisión concreta lo necesita; demasiados eventos vuelven el análisis confuso.

¿Qué hago si el volumen es muy bajo?

Revisa ejemplos individuales, pero marca la muestra como exploratoria. No conviertas una diferencia pequeña en una regla de negocio.

Resumen práctico

Un sistema de email útil para un SaaS no empieza con más campañas. Empieza con un contrato de eventos, una cohorte repetible y una definición clara de activación. Mide la cadena completa: evento, entrega, siguiente acción y resultado.

Como siguiente paso, revisa tu onboarding y anota qué señal falta. En mi experiencia, corregir una etiqueta ambigua o un retry sin idempotencia suele dar más claridad que añadir otra automatización. Y si documentas el flujo, revisa también cómo medir señales de un onboarding SaaS para mantener el contexto junto a las métricas.

SaaS: mide activación sin perder el hilo del email

Hannah — Sun, 25 Oct 2026 05:23:02 +0000

En un SaaS, el registro no es la activación. Una persona puede crear una cuenta, recibir un email y aun así no llegar al primer momento de valor. Si el equipo solo mira el evento signup_completed, parece que el onboarding funciona aunque haya usuarios bloqueados en el correo de verificación.

La forma mas clara de entender este recorrido es seguir una historia completa: qué acción inició el email, cuándo se procesó, si la persona lo abrió y qué paso del producto ocurrió después. No hace falta un sistema de analítica enorme. Hace falta acordar unos eventos pequeños y conectarlos con un identificador común.

El problema: activación sin una historia completa

Las métricas de marketing suelen separar el registro, la entrega del email y el uso del producto. Esa separación es útil para cada equipo, pero puede esconder el punto donde se pierde la activación.

Por ejemplo, un funnel puede mostrar:

1.000 personas crean una cuenta.
940 emails son aceptados por el proveedor.
760 usuarios confirman su dirección.
410 llegan a la primera función útil.

El dato importante no es solo que falten 590 personas. Es saber en qué transición se quedaron y qué evidencia existe para investigar. Un email aceptado no significa que la activación haya ocurrido.

Tambien conviene distinguir entre el tiempo del proveedor y el tiempo del producto. Si el mensaje llega tarde, la experiencia puede fallar aunque el backend responda rápido. Si llega enseguida pero el enlace apunta al entorno equivocado, el problema está en otra parte.

Qué eventos conviene medir

Para empezar, usaría cinco eventos con nombres fáciles de leer:

signup_completed: se creó la cuenta.
activation_email_requested: el sistema pidió el email.
activation_email_delivered: el proveedor confirmó la entrega, cuando existe esa señal.
activation_email_confirmed: la persona completó el enlace.
first_value_reached: realizó la acción que define el primer valor del producto.

Cada evento debería llevar user_id o un identificador equivalente, run_id, entorno, timestamp y una versión de la plantilla. El run_id ayuda a unir logs de backend con una ejecución de prueba; la versión evita discutir si el fallo pertenece al email actual o a uno antiguo.

No guardes el contenido completo del mensaje en cada evento. Para depurar suele bastar con el asunto, la plantilla, el proveedor y el estado. Así el equipo tiene evidencia sin copiar información privada a dashboards o tickets.

Un contrato sencillo para el backend

Un contrato pequeño puede verse así:

{
  "event": "activation_email_confirmed",
  "user_id": "usr_2048",
  "run_id": "onb_20261025_01",
  "template_version": "welcome-v3",
  "occurred_at": "2026-10-25T05:00:00Z"
}

El backend no necesita marcar el email como completado cuando solo lo puso en una cola. Debe avanzar el estado cuando recibe la señal correspondiente y conservar una razón legible si algo falla. Este detalle hace que soporte pueda responder mas rapido y que producto pueda separar un problema de entrega de uno de usabilidad.

Si tu API usa FastAPI, puedes validar emails por entorno sin mezclar datos antes de ejecutar pruebas de activación. Para el worker, también resulta útil guardar recibos para emails asíncronos, especialmente cuando un reintento vuelve difícil saber qué ocurrió primero.

Cómo probar el recorrido sin contaminar métricas

Primero prueba el contrato sin proveedor externo. Crea una cuenta de prueba, emite el evento y verifica que cada transición sea idempotente. Si el mismo mensaje llega dos veces, no deberia producir dos confirmaciones ni mover el contador de activación de forma incorrecta.

Después usa una bandeja aislada para revisar el enlace, el asunto y la plantilla. Un tempmailso puede servir como generador de emails falsos para un escenario controlado, siempre que no lo uses con datos de clientes ni como sustituto de pruebas de seguridad. La meta es verificar el flujo, no enviar información sensible a un servicio externo.

Durante una prueba, registra un recibo mínimo:

run_id=onb_20261025_01
email_requested=ok
email_delivered=ok
link_confirmed=ok
first_value=blocked
reason=missing_workspace_setup

No confundas términos de búsqueda con nombres técnicos. Alguien puede escribir temp gamil com o tamp mail com al buscar una herramienta, pero esos textos no deberían acabar en una etiqueta de evento, una URL ni una variable. Mantén los términos de SEO en la documentación si realmente ayudan, y conserva el contrato del sistema limpio.

Errores comunes y recapitulación

El primer error es medir solo la entrega. La entrega es una señal intermedia, no el resultado del onboarding. El segundo es cambiar el nombre de los eventos entre frontend y backend; una métrica que parece caer puede ser solo un problema de nomenclatura.

El tercero es probar con cuentas reales. Eso mezcla datos de desarrollo con resultados de marketing y hace mas dificil comparar un experimento. El cuarto es reintentar sin un run_id: cuando aparecen duplicados, nadie sabe si son usuarios distintos o la misma ejecución repetida.

Empieza con pocos eventos, un identificador compartido y una razón de bloqueo. Luego observa cuánto tarda cada transición y compara el recorrido por versión de plantilla o cohorte. Un tablero sencillo que explica dónde se rompe el camino vale mas que veinte métricas sin contexto.

Preguntas rápidas

¿Debo medir la apertura del email? Puede ser útil, pero no la trates como activación. Las aperturas dependen de clientes y políticas de privacidad. La confirmación y la acción de primer valor suelen ser señales mas cercanas al resultado real.

¿Qué hago si no tengo confirmación de entrega? Registra que la señal no está disponible y separa “aceptado por el proveedor” de “confirmado por el usuario”. Es mejor una limitación explícita que una métrica que parezca mas precisa de lo que es.

¿Cuándo necesito un generador de emails falsos? Cuando quieres probar enlaces y plantillas sin tocar cuentas reales. Define el entorno, elimina los datos de prueba y documenta qué parte del recorrido estás comprobando.

SaaS: prueba la activación con señales de email

Hannah — Sun, 25 Oct 2026 02:22:50 +0000

En un SaaS, el onboarding suele medirse con una pregunta demasiado simple: ¿se envió el email? Para el usuario, eso no es activación. La activación ocurre cuando entiende el producto, completa una acción importante y puede avanzar sin pedir ayuda.

En un experimento de producto que hice recientemente, el email de bienvenida aparecía como “correcto” en los logs, pero varias personas no terminaban el primer flujo. El envío funcionaba; la señal que estabamos mirando era la equivocada. Desde entonces trato el correo como parte de un recorrido de eventos, no como el resultado final.

Este enfoque sirve para equipos pequeños que quieren mejorar su SaaS sin montar una plataforma enorme de analítica. Con un contrato claro, un poco de backend y pruebas repetibles, puedes saber donde se rompe la experiencia.

La activación no termina cuando se envía el email

Un email puede tener varios estados útiles:

Preparado: el producto generó el mensaje correcto para el usuario correcto.
Enviado: el proveedor aceptó la solicitud.
Recibido: el sistema de prueba encontró el mensaje.
Abierto o visitado: el usuario siguió el enlace principal.
Activado: completó la acción que demuestra valor, como crear un proyecto o invitar a un compañero.

No todos los productos necesitan medir la apertura. A veces es una señal poco fiable y distrae del objetivo. En cambio, el evento activation_completed suele estar mas cerca del valor real. La clave es no llamar “activado” a alguien solo porque recibió un correo.

Define señales que se puedan medir

Antes de programar, escribe una tabla pequeña. No hace falta una herramienta sofisticada:

Evento	Datos mínimos	Qué demuestra
`welcome_sent`	`user_id`, `message_id`	El onboarding comenzó
`welcome_received`	`user_id`, `received_at`	El mensaje llegó al buzón
`cta_clicked`	`user_id`, `link_id`	El usuario volvió al producto
`activation_completed`	`user_id`, `workspace_id`	Se completó la acción principal

Incluye un run_id en las pruebas. También guarda una versión del template y el nombre del evento. Parece un detalle menor, pero ayuda bastante cuando marketing cambia el texto y el backend cambia la secuencia.

Si necesitas probar emails de onboarding sin ruido, empieza por separar la entrega del comportamiento posterior. Son comprobaciones relacionadas, pero no son la misma cosa.

Construye un pequeño contrato de eventos

Un contrato sencillo puede ser un objeto JSON:

{
  "event": "activation_completed",
  "user_id": "user_123",
  "workspace_id": "ws_456",
  "run_id": "onboarding-2026-10-25-01",
  "template_version": "welcome-v3"
}

El servicio que envía emails no debería decidir por sí solo que el usuario está activado. Su responsabilidad es publicar welcome_sent y, cuando puedas comprobarlo, welcome_received. El producto debe publicar activation_completed después de validar la acción principal.

Esta separación hace el sistema mas fácil de depurar. Si el correo llegó pero la activación no ocurrió, revisas el flujo de producto. Si ni siquiera llegó, miras el proveedor, la cola o el template. Cada error tiene un lugar donde empezar.

Prueba el recorrido sin contaminar tus datos

Para una prueba de integración, crea una identidad nueva por ejecución. No uses un buzón compartido: un mensaje viejo puede hacer que el test pase aunque el flujo actual esté roto. Una bandeja aislada por ejecución también evita que dos jobs lean el mismo correo cuando CI corre en paralelo.

El patrón de use and throw email es útil aquí: crea un buzón temporal, espera el mensaje que corresponde al run_id, comprueba el enlace y deja la identidad fuera del siguiente intento. No necesitas conservar cada correo para siempre. Si quieres repetir el recorrido manualmente, genera otra ejecución con otro identificador.

En documentación aparecen búsquedas raras como “fake e mail com” o “tepm mail com”. No las uses como nombres de eventos ni como criterios de negocio; el contrato debe usar nombres consistentes y entendibles para el equipo.

Errores comunes y checklist

Estos fallos aparecen con frecuencia:

Medir solo welcome_sent y asumir que el usuario vio el mensaje.
Reutilizar una dirección y aceptar un correo de una ejecución anterior.
Poner toda la lógica de activación dentro del worker de email.
No guardar message_id, run_id o la versión del template.
Enviar demasiados eventos y luego no saber cual importa.
Hacer el test dependiente de un tiempo exacto; la entrega puede tardar un poco.

Antes de publicar un cambio, revisa este checklist:

[ ] El evento de activación representa una acción de valor.
[ ] Cada prueba tiene una identidad y un run_id propios.
[ ] Los reintentos no crean una activación duplicada.
[ ] Los logs permiten seguir el mensaje sin exponer su contenido completo.
[ ] El equipo de producto entiende que significa cada evento.
[ ] El dashboard distingue entrega, visita y activación.

Recapitulación

Un buen email de onboarding no se mide solo por haber salido del servidor. Para aprender de verdad, conecta la entrega con la acción que el usuario intenta completar. Define pocos eventos, asigna una identidad aislada a cada prueba y conserva la evidencia mínima para investigar un fallo.

El resultado es un experimento de SaaS mas honesto: puedes ver si el problema está en el mensaje, en el enlace o en la experiencia posterior. Y cuando el equipo crezca, ese pequeño contrato de eventos será una base mucho mas útil que una colección de métricas difíciles de interpretar.

Como siguiente paso, documenta una sola acción de activación y prueba el recorrido completo esta semana. No hace falta instrumentarlo todo de golpe; empieza con una señal que todos puedan explicar.

SaaS: diseña un onboarding que sobreviva al email

Hannah — Tue, 20 Oct 2026 08:23:18 +0000

Un onboarding de SaaS suele dibujarse como una línea muy simple: registro, email de bienvenida, primer uso y activación. En producción, esa línea se rompe cuando el email tarda, el webhook llega dos veces o una persona abre el mensaje desde otro dispositivo.

En mis experimentos de producto intento que el email sea una señal del onboarding, no el dueño de todo el flujo. La diferencia parece pequeña, pero ayuda a separar “el usuario completó el paso” de “nuestro proveedor avisó que envió un mensaje”. Así las métricas son mas honestas y el equipo puede investigar un problema sin adivinar.

El email no es todo el onboarding

Un usuario puede verificar su cuenta desde un enlace, volver a la aplicación y completar su perfil antes de que nuestro sistema procese el evento delivered. Si el producto sólo considera válida la activación cuando recibe ese evento, la métrica queda atrasada o directamente incorrecta.

Conviene tratar cada paso como un estado propio:

registered: la cuenta fue creada.
verification_started: se solicitó la verificación.
verified: la persona confirmó su dirección.
profile_completed: terminó el primer dato útil.
activated: realizó la acción que demuestra valor del producto.

El email conecta estados, pero no los sustituye. Esta idea también sirve para revisar los mensajes comerciales; por ejemplo, puede complementar una guía para auditar los emails de upgrade en un SaaS sin mezclar entrega con conversión.

Define un contrato para cada evento

Antes de cambiar el dashboard, escribe el contrato mínimo que debe cumplir un evento. Para un webhook de correo podría ser:

{
  "event_id": "evt_8f12",
  "user_id": "usr_42",
  "message_type": "welcome",
  "status": "delivered",
  "occurred_at": "2026-10-20T08:20:00Z"
}

event_id evita contar dos veces el mismo aviso. user_id permite unir el evento con el onboarding sin usar el email como identificador principal. occurred_at ayuda a ordenar una señal atrasada, y message_type evita que un email de recuperación se cuele en la métrica de bienvenida.

También define qué pasa si faltan campos, si el proveedor reintenta o si llega un estado imposible. Un evento desconocido debe quedar en una cola de revisión, no convertirse en una activación silenciosa. Parece trabajo extra, pero despues ahorra bastante conversación ambigua entre producto y backend.

Un flujo pequeño que se puede observar

Una implementación inicial puede guardar el estado del usuario y una tabla de eventos procesados. El pseudocódigo siguiente muestra la regla importante: procesar de forma idempotente.

def handle_email_event(event):
    if events.exists(event["event_id"]):
        return "already_processed"

    events.insert(event["event_id"], event)

    if event["message_type"] == "welcome":
        onboarding.mark_email_seen(event["user_id"], event["status"])

    return "processed"

En una base de datos real, event_id debe tener una restricción única. El patrón “consultar y luego insertar” sin esa protección puede duplicar eventos cuando dos workers reciben el mismo webhook casi al mismo tiempo. La base de datos es la última barrera, aunque el código parezca suficientemente seguro.

Para entender el impacto, registra tres tiempos: cuándo se solicitó el mensaje, cuándo el proveedor informó el estado y cuándo el usuario completó el siguiente paso. Con esos datos puedes distinguir una demora del proveedor de una fricción real del producto. Es una observabilidad modesta, pero muy util.

Pruebas sin depender de una bandeja perfecta

Las pruebas de integración deben comprobar dos cosas separadas: que el sistema solicita el email y que el onboarding responde cuando llega una señal válida. No hace falta que cada test espere una bandeja real durante minutos.

Puedes usar un buzón controlado, un adaptador falso y un caso end-to-end pequeño. Si el equipo necesita un generador de cuentas de correo temporal para aislar registros de prueba, asocia la cuenta temporal al run_id del test y limpia sus datos cuando termine. El buzón es un recurso de test, no la identidad del usuario.

Una prueba útil también envía el mismo webhook dos veces y comprueba que la métrica sólo aumenta una vez. Otra entrega primero delivered y despues verified, y una tercera hace el orden inverso para confirmar que el estado final no depende de la suerte.

En la interfaz, los estados deben ser visibles y comprensibles. Una fila fija para validar el email puede evitar que el usuario pierda el contexto mientras espera, pero el frontend aún necesita manejar pending, expired y verified por separado.

Errores comunes y cómo corregirlos

El primer error es medir el clic del email como activación. Un clic demuestra interés, no necesariamente valor. El segundo es usar el webhook como única fuente de verdad; los proveedores pueden reintentar, cambiar de orden o entregar un estado con retraso.

El tercero es guardar el contenido entero del mensaje para poder depurar. Normalmente basta con conservar el identificador del proveedor, el tipo de mensaje y los tiempos principales. Menos datos hacen el debugging mas seguro.

Y hay un detalle que aparece en búsquedas internas: nombres como tempail mail pueden parecer equivalentes a un correo temporal, pero no deberían convertirse en estados de negocio. Conserva los términos de entrada para entender la consulta, y usa nombres claros dentro del código.

Preguntas rápidas

¿Debo bloquear el onboarding hasta recibir `delivered`?

No, salvo que el producto dependa realmente de esa entrega. Si la verificación ya ocurrió, permite continuar y registra la señal del proveedor como información adicional.

¿Qué hago con un webhook desconocido?

Guárdalo con estado unhandled, emite una alerta de baja urgencia y evita cambiar la métrica de activación. Así el equipo puede ampliar el contrato sin borrar evidencia.

¿Cuándo conviene separar Marketing y Backend?

Desde el principio en los nombres de eventos y responsables. Marketing puede definir el objetivo del mensaje; Backend debe garantizar que los eventos sean repetibles, trazables y seguros.

Checklist de lanzamiento

[ ] Cada estado del onboarding tiene una definición observable.
[ ] Los eventos tienen un identificador único e idempotente.
[ ] La entrega de email no se confunde con activación.
[ ] Los reintentos y eventos fuera de orden tienen pruebas.
[ ] pending, expired y verified se muestran de forma distinta.
[ ] Los logs guardan tiempos y referencias, no contenido sensible innecesario.
[ ] El dashboard explica qué fuente alimenta cada métrica.

Un onboarding resistente no necesita ignorar el email. Necesita colocarlo en el lugar correcto: como una señal útil dentro de un contrato de eventos mas amplio. Cuando producto, backend y pruebas comparten esos estados, los fallos son mas faciles de localizar y las decisiones de crecimiento se apoyan en señales reales.

SaaS: mide la activación con eventos de email

Hannah — Mon, 19 Oct 2026 14:22:49 +0000

En un SaaS, “el usuario recibió el email” parece una señal útil para medir activación. Pero un mensaje entregado no demuestra que la persona entendió el producto, terminó el primer paso o volverá mañana. Si mezclamos esos hechos, el panel de métricas se vuelve bonito y poco util.

Una forma más clara de trabajar es convertir cada etapa del onboarding en un evento pequeño, con un nombre y una condición verificable. Así el equipo de producto puede distinguir entre entrega, lectura, primera acción y valor real. No hace falta montar un sistema enorme para empezar: un contrato de eventos, una tabla sencilla y algunas pruebas ya dan bastante visibilidad.

La activación empieza con una señal, no con un clic

Primero define qué significa “activado” para tu producto. En una herramienta de colaboración podría ser crear un espacio y añadir a otra persona. En un servicio de facturación, puede ser crear la primera factura y guardarla. El email solo ayuda a guiar el camino.

Un flujo básico puede verse así:

signup_created
  -> welcome_email_accepted
  -> first_project_created
  -> teammate_invited
  -> activated

Cada evento debe responder una pregunta concreta. welcome_email_accepted confirma que el enlace llegó al producto; no confirma que el usuario haya encontrado valor. first_project_created es una señal de uso. activated debería ser una regla de negocio compuesta, no un botón que alguien marca a mano.

Si todavía estás aprendiendo backend, guarda también occurred_at, user_id, source y un event_id idempotente. Ese último campo evita contar dos veces el mismo reintento. Para revisar la interfaz, puede servir esta guía de validación de email sin saltos de layout, especialmente cuando el estado del mensaje cambia mientras la persona escribe.

Define un contrato pequeño de eventos

El contrato no tiene que ser una especificación de cien páginas. Un ejemplo en JSON sería:

{
  "event_id": "evt_123",
  "name": "welcome_email_accepted",
  "user_id": "usr_456",
  "occurred_at": "2026-10-19T14:00:00Z",
  "campaign": "onboarding-v2",
  "metadata": {"template": "welcome"}
}

Valida el nombre, la fecha y el identificador en el borde de tu API. Después persiste el evento antes de lanzar tareas secundarias, como actualizar una cohorte o enviar un recordatorio. Si el worker falla, puedes reintentar sin inventar una nueva acción del usuario.

Conviene separar dos estados que suelen confundirse: email_sent y email_link_opened. El primero describe una operación del sistema; el segundo, una interacción. Si el proveedor acepta un mensaje pero el enlace nunca se usa, eso no es necesariamente un problema de Marketing. Tal vez el asunto no explica el beneficio, o el primer paso es demasiado largo.

Para un buzón de prueba, una dirección de temp mail.so puede ayudarte a comprobar el recorrido completo sin contaminar cuentas personales. Úsala solo en entornos de desarrollo o QA y registra qué evento esperabas observar. Un test que solo busca “algún email” puede pasar aunque reciba una plantilla vieja.

Construye un embudo que puedas explicar

Empieza con cuatro conteos por cohorte semanal:

registros creados;
mensajes aceptados por el proveedor;
primer proyecto creado;
usuarios activados dentro de siete días.

El porcentaje más útil no siempre es el mayor. Si el 98 % recibe el mensaje pero solo el 12 % crea un proyecto, la oportunidad está después de la entrega. Si cae el primer número, revisa la cola y la reputación antes de cambiar el copy. Esta separación ahorra discusiones y evita que el equipo persiga una métrica de vanidad.

No compares cohortes sin guardar la versión de campaña. Un cambio de asunto, un nuevo formulario y una migración de base de datos pueden coincidir en la misma semana. Añadir campaign y product_version hace que el resultado sea mucho mas facil de interpretar.

Prueba los casos que rompen la métrica

Los tests deben cubrir tanto el camino feliz como los estados incómodos:

el mismo evento llega dos veces;
el enlace se abre después de expirar;
el email pertenece a una cuenta ya activada;
el proveedor acepta el mensaje, pero el worker recibe un timeout;
la campaña enviada no coincide con la versión esperada.

En pruebas automáticas, separa la espera por un mensaje concreto de la espera por cualquier mensaje. Revisa destinatario, asunto, identificador de campaña y enlace. Para ideas de fixtures y limpieza, puedes consultar estas pruebas limpias para emails de upgrade.

Un detalle pequeño: fija el reloj en los tests de expiración. Dejar que cada prueba use la hora real produce fallos intermitentes y hace que el equipo desconfíe de la métrica. La frase tem email o tamp mail com puede aparecer como dato inválido en una prueba de búsqueda, pero no debe convertirse en una URL ni en una señal de activación.

Errores comunes y una checklist

Los errores más habituales son marcar activación al enviar, contar reintentos como nuevas acciones y borrar los eventos demasiado pronto. También es facil llamar “retención” a un usuario que solo volvió a abrir un enlace.

Antes de publicar un panel, comprueba:

cada evento tiene una condición que el equipo puede explicar;
los reintentos son idempotentes;
la versión de campaña queda guardada;
los tiempos de espera están definidos;
los tests diferencian entrega, interacción y valor;
las métricas de una cohorte se pueden reproducir.

Preguntas rápidas

¿Necesito una plataforma de analítica desde el primer día? No. Una tabla de eventos y una consulta diaria son suficientes para validar la definición de activación.

¿Un email abierto significa que el usuario está activado? No. Es una señal intermedia; combina el evento con una acción dentro del producto.

¿Cuántos eventos debo crear? Los necesarios para explicar decisiones. Si nadie usa un evento para depurar, mejorar el onboarding o medir una hipótesis, probablemente sobra.

Recapitulación

Un buen sistema de activación de SaaS no empieza con más dashboards. Empieza con definiciones pequeñas: qué se envió, qué se abrió, qué acción ocurrió y qué significa valor. Con eventos idempotentes, cohortes versionadas y pruebas de email realistas, el equipo puede mejorar el onboarding sin adivinar qué pasó. Es un cambio modesto, pero deja el producto mucho mas entendible para todos.

Emails de onboarding SaaS: un contrato de eventos

Hannah — Sun, 18 Oct 2026 20:22:55 +0000

Un email de onboarding parece una pieza pequeña del producto: alguien crea una cuenta, recibe un mensaje y empieza a usar la aplicación. En un SaaS que crece, sin embargo, ese mensaje depende de varias cosas: la transacción de registro, una cola, un proveedor de correo, una plantilla y un enlace correcto.

Cuando algo falla, el equipo suele preguntar “¿se envió el email?” Esa pregunta es demasiado corta. Un evento puede haberse creado, procesado y entregado, pero la persona no haberlo visto porque la plantilla tenía un enlace roto o porque el mensaje terminó en una bandeja equivocada.

La solución que me ha resultado más práctica es tratar cada email como un contrato de eventos. No hace falta construir una plataforma enorme. Hace falta definir qué ocurrió, qué evidencia guardamos y qué puede comprobar un test.

El problema: onboarding sin evidencia

En una primera versión, el backend normalmente devuelve 201 Created y deja el envío para un worker. Eso es correcto para la experiencia del usuario, pero dificulta depurar. El frontend sabe que la cuenta existe, mientras el equipo de producto no sabe si el email fue encolado, reintentado o descartado.

Para un flujo de onboarding, separo cinco estados sencillos:

created: la cuenta fue creada.
queued: el evento de email entró en la cola.
sent: el proveedor aceptó el mensaje.
delivered: recibimos confirmación de entrega cuando está disponible.
failed: terminó el número de reintentos o hubo un error permanente.

Esto evita que un solo booleano como welcome_email_sent esconda demasiadas situaciones. Tambien hace más fácil explicar el estado a soporte: no es lo mismo “todavía en cola” que “el proveedor rechazó el dominio”.

Qué debe contener el contrato de eventos

Cada evento necesita un identificador estable y algunos datos mínimos. Por ejemplo:

{
  "event_id": "evt_01J9W2Q4K8",
  "type": "onboarding.email.requested",
  "account_id": "acc_2048",
  "template": "welcome-v2",
  "attempt": 1,
  "created_at": "2026-10-18T20:00:00Z"
}

El event_id sirve para aplicar idempotencia. Si un worker recibe el mismo mensaje dos veces, no deberia crear dos envíos. template ayuda a comparar versiones y attempt permite distinguir un reintento de un evento nuevo.

También guardo una razón de fallo legible, pero sin incluir el contenido completo del email ni datos privados. En desarrollo, esa pequeña decisión ahorra bastante tiempo: el equipo puede revisar la secuencia sin copiar direcciones reales a una hoja o a un chat.

Si tu producto necesita más detalle, puedes añadir correlation_id, provider_message_id y environment. No añadiría campos solo porque “quizas algún día” sirvan. Un contrato pequeño se mantiene mejor y se aprende más rapido.

Implementación sencilla en el backend

La tabla de eventos puede vivir junto a las demás tablas del SaaS. Un índice único sobre event_id y una transición controlada de estados suele ser suficiente para comenzar. La idea importante es que la aplicación no marque un email como enviado antes de que el worker lo entregue al proveedor.

Un pseudocódigo de consumo puede verse así:

event = inbox.next()

if events.exists(event.event_id):
    acknowledge(event)
else:
    events.insert(event, status="queued")
    result = mailer.send(event)
    events.update(event.event_id, result.status, result.message_id)
    acknowledge(event)

En producción, el detalle depende de la cola y del proveedor. Para un proyecto pequeño, lo esencial es registrar la respuesta y no esconder los fallos detrás de un reintento infinito. Una cola que insiste para siempre puede hacer que un problema de configuración parezca tráfico normal.

Para medir productividad del equipo, observo tres tiempos: desde created hasta queued, desde queued hasta sent y desde sent hasta delivered. No uso estos números como una promesa de entrega; los uso para encontrar donde se atasca el flujo.

Cómo probar el flujo completo

Primero pruebo el contrato sin depender de un proveedor externo. El test publica un evento, ejecuta el worker y verifica que el estado final, el número de intentos y el identificador de correlación sean correctos.

Después hago una prueba de integración con una bandeja aislada. Una dirección temporal puede servir para inspeccionar el asunto, el enlace de activación y la versión de la plantilla sin tocar la bandeja personal de un desarrollador. En búsquedas de este tema aparecen variantes como tempmail.so, tempmail so y hasta el typo tepm mail com; son términos útiles para entender la intención, pero no deberían convertirse en nombres de variables o estados del sistema.

Para el flujo visual, conviene comprobar que la interfaz explica cada espera: “procesando”, “enviado” y “no pudimos entregar”. Puedes probar emails de referidos sin llenar bandejas reales y revisar también cómo diseñar estados accesibles para un inbox de prueba.

Un checklist útil para cada ejecución es:

¿El evento aparece una sola vez?
¿El worker puede reintentarlo sin duplicar el email?
¿El enlace apunta al entorno correcto?
¿La plantilla corresponde a la versión esperada?
¿El fallo explica la siguiente acción?
¿La prueba usa una bandeja separada de las cuentas reales?

Al principio, algunas pruebas pueden parecer repetitivas. Aun así, suelen detectar regresiones antes de que soporte reciba el primer mensaje. Es mejor invertir cinco minutos en una evidencia clara que media hora intentando adivinar qué pasó.

Errores comunes

El primer error es probar solo la función que llama al proveedor. Eso deja fuera la cola, los reintentos y el estado que ve el usuario. El segundo es usar una dirección personal durante el desarrollo. Contamina resultados, puede exponer datos y hace que el equipo confunda una prueba manual con una señal del producto.

El tercero es medir solo “enviado”. Para un SaaS, la experiencia depende de todo el recorrido. Si no hay confirmación de entrega, registra esa limitación y presenta un estado honesto; no inventes certeza.

Recapitulación

Un contrato de eventos convierte un email de onboarding en algo observable y comprobable. Empieza con estados pequeños, un identificador idempotente y una razón de fallo clara. Luego prueba el backend, el worker, la bandeja aislada y la experiencia visual por separado.

La meta no es tener más logs. Es que una persona nueva del equipo pueda responder, rapido y sin adivinar, qué ocurrió con cada email. Cuando esa respuesta está disponible, mejorar el onboarding deja de ser una discusión de intuiciones y se convierte en trabajo de producto medible.

Preguntas rápidas

¿Necesito una cola para un SaaS pequeño? No siempre. Pero conviene diseñar el contrato de eventos aunque el primer worker sea simple; así la migración será menos dolorosa cuando aumente el tráfico.

¿Debo probar con direcciones reales? Para pruebas automáticas, no. Usa datos y bandejas aisladas. Reserva las cuentas reales para una verificación manual controlada y documentada.

SaaS: un contrato de estados para el onboarding

Hannah — Fri, 09 Oct 2026 20:22:54 +0000

Cuando un SaaS tiene pocos usuarios, el onboarding parece una secuencia simple: crear cuenta, enviar un correo y activar el perfil. Pero en cuanto aparecen reintentos, invitaciones, planes distintos y pruebas automáticas, la pregunta cambia: ¿en qué estado exacto quedó cada persona?

En mis experimentos de producto, me ha ayudado tratar el onboarding como un contrato de estados. No es una gran máquina distribuida. Es una lista pequeña y explicable que conecta la interfaz, el backend y las pruebas de email. Con ese modelo, un equipo puede entender qué paso ocurrio, repetir una prueba y medir la activación sin adivinar.

El onboarding también necesita un contrato

Un contrato define qué significa cada estado y qué transiciones están permitidas. Por ejemplo, created no debería significar lo mismo que email_sent, y email_verified no debería llegar antes de que exista un token válido.

Un flujo inicial puede ser:

created -> email_pending -> email_sent -> verified -> activated
                         \-> email_failed

La flecha no es solo documentación. Es una regla para el código. Si el frontend muestra “cuenta activa” mientras la base de datos todavía dice email_pending, el usuario recibe una señal confusa y soporte pierde tiempo buscando la causa.

También conviene guardar state_changed_at, attempt_count y last_reason. Así el equipo backend puede ver si el retraso viene del proveedor, de un worker detenido o de una acción repetida en la interfaz.

Qué estados conviene modelar

No hace falta crear un estado para cada detalle. Empieza con los momentos que cambian una decisión de producto:

created: la cuenta existe, pero el flujo no ha solicitado verificación.
email_pending: hay un trabajo pendiente de enviar.
email_sent: el proveedor aceptó el mensaje.
verified: la persona confirmó el token.
activated: completó el primer paso útil del producto.
expired: el token o la invitación ya no son válidos.
failed: el sistema agotó una política de reintentos.

La separación entre verified y activated es especialmente útil. Una persona puede confirmar su correo y nunca crear su primer proyecto. Si agrupamos todo como “registrado”, perdemos la señal que sirve para mejorar el onboarding. En mi caso, esa distinción hizo mas fácil conversar con producto: el problema no era el correo, sino el siguiente paso.

Una identidad de prueba por ejecución

Las pruebas automáticas suelen fallar porque varias ejecuciones comparten el mismo buzón o la misma dirección. Una ejecución recibe el correo de otra, consume un token antes de tiempo y deja un error que aparece solo a veces.

La solución práctica es dar a cada ejecución una identidad propia. El registro de prueba puede guardar algo como esto:

{
  "run_id": "signup-2026-10-09-042",
  "test_email": "signup-042@example.test",
  "expected_state": "verified",
  "expires_at": "2026-10-09T21:00:00Z"
}

La identidad no tiene que ser permanente. Una herramienta de correo de prueba como tempmailso puede servir para validar el recorrido, siempre que el equipo conozca el límite de retención y no mezcle datos reales con fixtures. Incluso un valor de búsqueda mal escrito, como temp mailid, debe quedar asociado a una ejecución y no a una cuenta compartida.

Cuando cada prueba tiene su propio run_id, investigar un fallo es más directo. Se puede preguntar qué mensaje llegó, qué transición esperaba la prueba y cuánto tiempo pasó entre ambos eventos. Ese contexto vale más que un simple “assert failed”.

Idempotencia y limpieza

El endpoint de “reenviar correo” debe ser seguro si el usuario pulsa dos veces. Una clave como signup:{user_id}:{flow_id} permite reconocer el mismo trabajo. El worker también debería comprobar el estado actual antes de enviar: si ya está en email_sent, no debe crear otro mensaje por accidente.

Para las pruebas, la clave puede incluir el run_id. Así una nueva ejecución no hereda el estado de la anterior. Si la prueba se repite con signup-043, su buzón y sus eventos son nuevos.

La limpieza es la otra mitad del contrato. Define cuándo se eliminan los mensajes, tokens y registros de prueba. Una retención corta reduce ruido, pero borrar enseguida puede hacer imposible depurar un fallo. Un equilibrio sencillo es conservar el resumen de la ejecución y eliminar el contenido del mensaje cuando ya no sea necesario.

En una base pequeña, incluso un job diario puede marcar como expirados los registros viejos. Lo importante es que no dependa de una persona acordándose manualmente. Cuando los estados queda sin dueño, los datos de prueba terminan pareciendo usuarios reales.

Errores comunes

El primer error es modelar solo el estado final. “Activo” no explica si la persona verificó el correo, aceptó una invitación o fue activada por un administrador.

El segundo es guardar el estado únicamente en el frontend. El navegador puede cerrarse, repetir una solicitud o mostrar información antigua. La fuente de verdad debe vivir en el backend, y la interfaz debe renderizar una versión clara de ella.

El tercero es usar direcciones fijas para todos los tests. Un dato de prueba llamado fake e mail com puede parecer inofensivo, pero si se reutiliza entre suites genera falsos positivos y hace difícil saber que pasó.

Por último, no midas solo el porcentaje de emails enviados. Añade tiempo hasta verificación, tasa de expiración, reintentos, activación posterior y ejecuciones contaminadas por datos anteriores. Esas señales ayudan a priorizar mejoras reales. También evita que el equipo persiga problemas de correo cuando el bloqueo está en otra pantalla.

Checklist práctico

[ ] Cada estado tiene una definición breve y una transición válida.
[ ] verified y activated representan momentos diferentes.
[ ] Cada email de prueba tiene un run_id propio.
[ ] El reenvío usa una clave idempotente.
[ ] Los errores guardan una razón segura y un contador de intentos.
[ ] Existe una política de expiración y limpieza.
[ ] Las métricas separan entrega, verificación y activación.
[ ] La interfaz comunica el estado actual sin prometer mas de lo que el backend sabe.

Si el flujo usa React, también merece la pena diseñar reenvíos de verificación sin ansiedad: el estado del email debe ser visible, pero no interrumpir el trabajo de la persona. Y para analizar el resultado, puedes medir activación por email con más contexto, separando la confirmación del primer momento de valor.

Recapitulación

Un contrato de estados convierte el onboarding en algo que se puede explicar, probar y mejorar. Empieza con pocos estados, guarda el motivo de cada transición y da a cada ejecución de prueba una identidad aislada.

No necesitas una arquitectura enorme. Necesitas que el backend sepa qué paso ocurrió, que el frontend lo comunique con honestidad y que la limpieza tenga un responsable automático. Con esas bases, un SaaS puede crecer sin convertir cada “no recibí el email” en una investigación desde cero.

SaaS: contrato de entrega para emails

Hannah — Wed, 07 Oct 2026 14:23:54 +0000

En un SaaS, un email de activación no es solo un mensaje que sale de un servidor. Es una parte del producto. Si llega tarde, se duplica o nadie puede explicar que paso, la persona usuaria puede abandonar el onboarding aunque el registro haya funcionado.

Un contrato de entrega ayuda a quitar esa incertidumbre. No promete que todos los mensajes llegarán siempre, porque eso depende de proveedores y destinatarios. Promete algo mas útil para el equipo: cada intento tendrá un estado, un contexto y una siguiente acción clara.

Qué debe prometer el contrato de entrega

Antes de escribir workers o añadir otra cola, define qué significa “entregado” en tu producto. Yo separaría estas etapas:

requested: el producto pidió el email.
queued: el backend guardó el trabajo.
sending: un worker lo tomó.
accepted: el proveedor aceptó la petición.
observed: una prueba o evento confirmó el resultado esperado.

accepted no es lo mismo que “la persona lo leyó”. Esta diferencia parece pequeña, pero evita que soporte prometa demasiado. También permite investigar si el problema está en la aplicación, en el proveedor o en el buzón de destino.

Un registro mínimo puede verse así:

delivery_id     identificador único
user_id         usuario del SaaS
kind            welcome, verify o reset
template        versión de la plantilla
status          estado actual
attempts        número de intentos
last_error      error breve y seguro
created_at      momento de creación
updated_at      última transición

La plantilla debe tener una versión. Si el usuario recibe un texto antiguo, podremos saber qué contenido generó el worker sin buscar en cada despliegue. Este detalle vuelve el debugging mucho menos dificil.

Diseña el flujo paso a paso

El flujo puede empezar en la transacción que crea la cuenta, pero no debería enviar el email dentro de la misma petición HTTP. Guarda un evento o trabajo y responde al frontend. Después, un worker procesa la cola.

signup -> delivery.requested -> delivery.queued
                              -> worker toma el trabajo
                              -> accepted o failed

Para evitar duplicados, usa una clave de idempotencia basada en el caso de uso. Por ejemplo:

welcome:user_482:template_v3

Antes de crear otra tarea, busca una entrega activa con esa clave. El worker también debe comprobar el estado justo antes de llamar al proveedor. Si un proceso ya la marcó como accepted, no conviene reintentar de nuevo solo porque un timeout escondió la respuesta.

Los reintentos tienen que distinguir errores temporales de errores permanentes. Un timeout de red puede volver a intentarse con una espera creciente. Una dirección rechazada necesita una ruta de corrección, no cinco llamadas iguales. Anota la razón, el número de intento y el próximo momento de ejecución.

Para diseñar los estados y sus salidas, resulta útil pensar en contratos de salida para automatizaciones. La idea es parecida: cada paso debe producir una señal que el siguiente componente pueda interpretar.

Prueba el onboarding con un buzón aislado

Las pruebas end-to-end suelen fallar cuando varias ejecuciones comparten la misma bandeja. Un test puede leer el mensaje de otro branch y parecer correcto. La solución práctica es crear un buzón o dirección de prueba por ejecución y guardar su identidad junto al delivery_id.

En algunos equipos se usa un correo temporal gratuito o un correo desechable gratuito para validar el flujo en staging. Eso puede servir, pero el test debe tratar esa dirección como un fixture aislado: no la mezcles con métricas de producción, no guardes secretos en el código y define cuánto tiempo se conserva.

También conviene guardar un pequeño recibo de la prueba:

{
  "run_id": "ci-1842",
  "delivery_id": "del_8f21",
  "expected_subject": "Confirma tu cuenta",
  "observed": true,
  "attempts": 1
}

Si alguien escribe tepm mail com en una nota de QA, esa cadena no debe romper el parser ni entrar como una dirección real. Los fixtures deben validar formato y separar las anotaciones humanas de los datos que usa el worker.

Para flujos con varios pasos, también vale la pena versionar acciones de correo. Versionar no significa hacer una plataforma enorme; significa poder reproducir que configuración produjo cada resultado.

Mide evidencia, no solo envíos

Una métrica de “emails enviados” es insuficiente. Añadiría estas señales:

tiempo desde requested hasta accepted;
porcentaje de entregas que necesitaron reintento;
duplicados evitados por la clave de idempotencia;
entregas sin confirmación después del límite;
fallos agrupados por tipo, no por contenido privado.

La privacidad importa también en los logs. Guarda identificadores y dominios cuando sea necesario, pero evita tokens, enlaces completos de recuperación y cuerpos enteros. Un panel con demasiados datos personales es dificil de compartir durante un incidente.

Errores comunes

El primer error es llamar al proveedor antes de persistir el trabajo. Si el proceso cae después del envío, no hay forma confiable de saber qué ocurrió. El segundo es usar un solo estado failed para todo; así se pierde la diferencia entre un rechazo permanente y una caída temporal.

Otro error frecuente es borrar la evidencia apenas el test termina. Conserva un resumen corto durante el tiempo que tu equipo necesite para depurar, y elimina lo que ya no aporta valor. Finalmente, no conviertas cada reintento en una notificación para la persona usuaria: los estados internos pueden ser detallados mientras la interfaz mantiene un mensaje simple.

Checklist de implementación

[ ] Cada entrega tiene un identificador y una clave de idempotencia.
[ ] Los estados distinguen petición, cola, proveedor y observación.
[ ] La plantilla se guarda con una versión.
[ ] Los reintentos tienen límite y clasificación de errores.
[ ] Cada prueba usa un fixture de inbox aislado.
[ ] Los logs no contienen tokens ni cuerpos completos.
[ ] El frontend explica qué puede hacer la persona si el email no llega.

Preguntas rápidas

¿Necesito una cola especializada desde el inicio?

No. Una tabla en PostgreSQL y un worker sencillo pueden ser suficientes para un SaaS pequeño. Empieza con estados claros y cambia de herramienta cuando una necesidad observada lo justifique.

¿`accepted` significa que el email llegó?

No necesariamente. Significa que el proveedor aceptó la solicitud. La entrega final depende de más sistemas, por eso conviene separar aceptación, observación y lectura.

¿Qué hago si el test encuentra un mensaje viejo?

Relaciona cada ejecución con un buzón, asunto o identificador único. Busca por el delivery_id o por un encabezado de prueba, no solamente por el asunto.

Recapitulación

Un contrato de entrega convierte el email de onboarding en una pieza observable del producto. Con estados pequeños, idempotencia, fixtures aislados y métricas útiles, el equipo puede saber qué pasó y qué hacer después. Es una mejora de backend, pero también de productividad: menos adivinanzas, menos reintentos ciegos y conversaciones de soporte mas claras.

SaaS: cómo probar onboarding sin emails falsos

Hannah — Tue, 06 Oct 2026 11:23:51 +0000

Cuando una persona se registra en un SaaS, el correo de bienvenida parece un detalle pequeño. En realidad, suele ser el puente entre “creé una cuenta” y “entendí el valor del producto”. Si esa prueba depende de una bandeja compartida o de un email fijo, el resultado se vuelve dificil de interpretar: el test puede pasar aunque haya recibido un mensaje viejo.

La solución no es añadir más asserts sin orden. Es darle a cada ejecución un buzón propio, una expectativa clara y un recibo que explique qué ocurrió.

El problema: onboarding verde, producto roto

Un flujo de onboarding normalmente tiene varios pasos:

Crear una cuenta con un correo nuevo.
Esperar el mensaje de verificación.
Seguir el enlace.
Completar el primer paso útil del producto.
Comprobar que la cuenta aparece activa.

Cuando varias pruebas usan el mismo buzón, aparecen falsos positivos y falsos negativos. Un mensaje anterior puede contener un enlace todavía válido. Otra ejecución puede leer el correo equivocado. Y si el equipo mira la analítica, los usuarios de prueba se mezclan con señales de marketing o con clientes reales.

El resultado más peligroso es un onboarding “verde” que no representa la experiencia que tendrá una persona nueva.

Qué debe representar un buzón de prueba

Un buzón de prueba no necesita ser una copia perfecta de Gmail. Necesita representar tres cosas de forma consistente:

Identidad: la dirección debe estar asociada a una sola ejecución.
Cursor: la prueba debe buscar mensajes posteriores a su inicio, no cualquier mensaje disponible.
Retención: al terminar, los datos deben expirar o quedar marcados para limpieza.

Para una prueba local, un correo temporal puede ser suficiente. En CI, conviene además guardar el identificador de la ejecución y el asunto esperado. Un buzón aislado por ejecución hace que el diagnóstico sea más rapido, porque la pregunta deja de ser “¿qué mensaje recibió esta cuenta?” y pasa a ser “¿qué ocurrió en esta ejecución?”.

La cadena tepm mail com puede aparecer en búsquedas internas o en notas de soporte por un error de escritura; no conviene usarla como criterio de validación ni como dominio real.

Un contrato sencillo por ejecución

Antes de escribir el test, define un contrato pequeño:

run_id       = ci-1842
email        = ci-1842@dominio-de-pruebas.example
subject      = Confirma tu cuenta
max_wait     = 60 segundos
message_from = no-reply@tu-saas.example

La prueba crea la dirección, registra run_id y espera sólo mensajes que cumplan el contrato. No basta con comprobar que existe un email: también hay que confirmar que el enlace apunta al entorno correcto y que la cuenta cambia al estado esperado.

Un recibo mínimo puede verse así:

{
  "run_id": "ci-1842",
  "email": "ci-1842@dominio-de-pruebas.example",
  "message_id": "msg-9081",
  "verification": "passed",
  "activation": "passed",
  "cleanup": "pending"
}

El campo cleanup es importante. Si los datos se conserva sin límite, una suite pequeña termina creando ruido y costes que nadie mira.

Ejemplo de implementación

En un backend sencillo, separaría el flujo en tres funciones: createFixture, waitForWelcome y assertActivation. La primera crea la identidad; la segunda usa un cursor de inicio y un límite de tiempo; la tercera valida el efecto en la aplicación.

const fixture = await createFixture({ runId });

const message = await waitForWelcome({
  address: fixture.address,
  after: fixture.createdAt,
  timeoutMs: 60_000,
});

await openVerificationLink(message);
await assertActivation({ runId, expected: "active" });
await markForCleanup(fixture.id);

En caso de fallo, conserva el recibo y una versión redactada del asunto. No guardes el enlace completo de verificación si contiene un token válido. Para alertas operativas, ayuda pensar en el mismo patrón que al diseñar alertas de rollback con contexto: el dato debe indicar qué falló, dónde y con qué contexto.

Errores comunes que salen caros

Usar una cuenta fija. Es cómodo al principio, pero crea carreras entre tests y hace dificil reproducir un fallo.

Esperar sólo por el asunto. Dos mensajes pueden compartir asunto. Añade remitente, fecha de creación y un identificador de ejecución.

Verificar la entrega, pero no la activación. El mensaje puede llegar y aun así tener un enlace roto, una URL de staging o un estado de usuario que no cambia.

Borrar demasiado pronto. Si limpias antes de crear el recibo, el diagnóstico queda incompleto. Marca para limpiar y aplica la retención después de conservar los metadatos necesarios.

Mezclar pruebas con campañas. Un correo de test nunca deberia entrar en la analítica normal de marketing. Usa un atributo de entorno y exclúyelo de los informes.

Cómo conectar la prueba con el producto

La prueba técnica gana valor cuando responde una pregunta de producto: ¿una persona nueva puede llegar al primer momento útil sin fricción? Para medirlo, registra tiempos separados para entrega, clic y activación. No hace falta construir un sistema enorme; una tabla de eventos por run_id ya ayuda a ver dónde se pierde el flujo.

También puedes crear un pequeño catálogo de correos útiles para alertas operativas y reutilizar la misma disciplina de contexto en los fallos de onboarding.

Si necesitas una herramienta externa para preparar identidades de prueba, un generador de correo desechable puede servir para exploraciones manuales. Para CI, confirma antes sus límites de retención, privacidad y automatización; no pongas datos de clientes ni tokens reales en una bandeja compartida.

Recapitulación

Un buen test de onboarding SaaS no comprueba solamente que “llegó un correo”. Crea una identidad aislada, usa un cursor temporal, valida la activación y deja un recibo útil para depurar.

Empieza con una sola ejecución por buzón, un asunto y remitente esperados, un límite de espera y una limpieza explícita. Después conecta esos resultados con la analítica de activación. Es un cambio pequeño, pero vuelve las pruebas más confiables y el producto más fácil de mejorar en el día a día.

SaaS: prueba emails con un contrato de ejecución

Hannah — Tue, 06 Oct 2026 08:23:17 +0000

En un SaaS, los emails parecen una pieza pequeña hasta que el primer test falla por leer el mensaje equivocado. Una ejecución crea una cuenta, otra confirma el mismo buzón temporal y una tercera recibe el correo de la primera. El resultado es un test intermitente que cuesta mas tiempo investigar que arreglar.

En mis experimentos de producto he encontrado una regla simple: cada ejecución de prueba debe tener dueño, identidad y una forma clara de terminar. No hace falta crear una plataforma enorme. Hace falta acordar un contrato entre el test, el Backend y el proveedor de correo.

Este enfoque complementa ideas para aislar el correo de cada ejecución y también ayuda cuando un flujo incluye un signup accesible para pruebas reales.

El problema de compartir una bandeja

Una bandeja compartida rompe la relación entre causa y evidencia. Si el test solo pregunta “¿hay un email nuevo?”, no sabe si ese email pertenece a su propia ejecución. Un reintento puede consumir el mensaje correcto antes que el test original, o una ejecución lenta puede encontrar datos que dejó otra.

Esto ocurre mucho en CI porque varios jobs corren al mismo tiempo. También ocurre en local: alguien repite el test y el correo anterior sigue ahí. Las cadenas de prueba suelen tener nombres raros, como fake e mail com, y luego nadie recuerda cual job las creó.

La solución no es esperar más. Añadir sleep(10) solo hace que el problema sea mas caro. La solución es dar contexto al email y validar ese contexto antes de aceptarlo.

El contrato de ejecución

Un contrato pequeño puede tener cuatro campos:

run_id: identificador único del job o de la ejecución.
mailbox_id: buzón temporal reservado para ese run_id.
created_at: momento en que el test comenzó a esperar mensajes.
expires_at: límite después del cual los datos ya no sirven.

Por ejemplo, el backend puede crear este registro antes de abrir el formulario:

{
  "run_id": "ci-1842-signup-07",
  "mailbox_id": "qa-ci-1842-07",
  "purpose": "signup-verification",
  "expires_at": "2026-10-06T09:00:00Z"
}

El nombre exacto puede cambiar. Lo importante es que el test conserve el run_id y lo use en cada consulta. Un correo temporal como tempmailso puede servir para pruebas controladas, siempre que el equipo trate el contenido como dato de test y no como una cuenta real.

Un diseño pequeño para el backend

El endpoint de creación debería devolver una identidad de ejecución, no solo una dirección de correo. Así el cliente de pruebas no necesita adivinar qué mensaje pertenece a qué job.

POST /test-fixtures/mailboxes
Idempotency-Key: ci-1842-signup-07

{
  "purpose": "signup-verification",
  "ttl_seconds": 900
}

La respuesta puede incluir run_id, mailbox_id y una fecha de expiración. En la consulta, el backend debe filtrar por el buzón y por un cursor o timestamp. De esta forma un mensaje viejo no pasa solo porque contiene la palabra “verify”.

También conviene que la limpieza tenga un responsable. Un worker puede borrar fixtures expirados, pero el job debe intentar liberar su buzón en un bloque finally. Si el job muere antes, el TTL sigue siendo la red de seguridad.

Qué debe comprobar el test

Un test de verificación de email debería comprobar, en este orden:

Que el mailbox_id corresponde a su propio run_id.
Que el mensaje llegó después de iniciar la ejecución.
Que el destinatario esperado coincide, sin comparar solo el asunto.
Que el token no está expirado y puede usarse una sola vez.
Que el mensaje queda marcado como consumido.

El cuarto punto suele olvidarse. Un correo correcto pero antiguo puede producir un falso positivo. La prueba pasa, aunque el flujo actual nunca haya enviado nada.

Para depurar, guarda un recibo pequeño: run_id, estado, timestamps, proveedor y razón del fallo. No guardes el cuerpo completo si no hace falta. El recibo permite saber si el problema fue creación, entrega, lectura o limpieza, y hace el resultado bastante mas útil para quien mantiene el SaaS.

Errores comunes

El primer error es usar una dirección fija para todos los tests. Es cómodo al principio, pero se vuelve una cola compartida. El segundo es usar el asunto como identificador único; dos mensajes pueden tener el mismo asunto.

El tercero es mezclar formato y entrega. Validar que la dirección tiene forma correcta no demuestra que el email llegó. Son comprobaciones diferentes y deben tener tiempos y mensajes distintos.

El cuarto es borrar evidencia demasiado pronto. Durante desarrollo, conserva el recibo hasta que el job termine y registra solo los datos necesarios. En producción, aplica una retención corta y documentada.

Por último, no escondas toda la lógica detrás de reintentos. Un reintento con el mismo contrato puede ser seguro; un reintento que crea otra identidad sin marcar la anterior deja basura y vuelve confuso el diagnóstico.

Recapitulación

Un contrato de ejecución convierte las pruebas de email de una búsqueda ambigua en una conversación clara entre el test y el Backend:

cada job tiene un run_id único;
cada buzón temporal tiene una fecha de caducidad;
cada lectura valida identidad, tiempo y destinatario;
cada fixture tiene limpieza y un recibo mínimo;
los reintentos conservan el contexto original.

Empieza con un solo flujo de signup. Añade el registro, filtra los mensajes por ejecución y mide los fallos durante una semana. Cuando el patrón sea estable, puedes llevarlo a otros emails del SaaS sin cambiar toda la arquitectura. Es un cambio pequeño, pero hace que los tests sean mucho mas fáciles de confiar.

DEV Community: Hannah

Un sandbox de activación SaaS que sí se puede probar

Un sandbox de activación SaaS que sí se puede probar

El problema: activar usuarios no es solo enviar un correo

Qué debe aislar el sandbox

Un flujo paso a paso

Una implementación pequeña en el backend

Cómo guardar evidencia sin guardar secretos

Errores comunes al empezar

Preguntas frecuentes

¿Hace falta un proveedor real de email?

¿Cuánto tiempo debe esperar el test?

¿Qué pasa si la limpieza falla?

Recapitulación

SaaS: un contrato de email para activar usuarios

El problema: activar no es solo enviar un correo

Define el contrato del evento

Conecta backend, producto y marketing

Prueba el flujo sin depender de una bandeja personal

Mide la activación con estados claros

Preguntas rápidas

¿Necesito una herramienta de analítica para empezar?

¿Debo contar la apertura como activación?

¿Qué hago con un correo que llega tarde?

Recapitulación

SaaS: mide emails sin perder el contexto

El problema: muchos emails, poca señal

Define el evento antes de mirar la métrica

Construye una cohorte pequeña y repetible

Qué hacer con los fallos

Preguntas frecuentes

¿Debo medir aperturas?

¿Cuántos eventos necesito?

¿Qué hago si el volumen es muy bajo?

Resumen práctico

SaaS: mide activación sin perder el hilo del email

El problema: activación sin una historia completa

Qué eventos conviene medir

Un contrato sencillo para el backend

Cómo probar el recorrido sin contaminar métricas

Errores comunes y recapitulación

Preguntas rápidas

SaaS: prueba la activación con señales de email

La activación no termina cuando se envía el email

Define señales que se puedan medir

Construye un pequeño contrato de eventos

Prueba el recorrido sin contaminar tus datos

Errores comunes y checklist

Recapitulación

SaaS: diseña un onboarding que sobreviva al email

El email no es todo el onboarding

Define un contrato para cada evento

Un flujo pequeño que se puede observar

Pruebas sin depender de una bandeja perfecta

Errores comunes y cómo corregirlos

Preguntas rápidas

¿Debo bloquear el onboarding hasta recibir delivered?

¿Qué hago con un webhook desconocido?

¿Cuándo conviene separar Marketing y Backend?

Checklist de lanzamiento

SaaS: mide la activación con eventos de email

La activación empieza con una señal, no con un clic

Define un contrato pequeño de eventos

Construye un embudo que puedas explicar

Prueba los casos que rompen la métrica

Errores comunes y una checklist

Preguntas rápidas

Recapitulación

Emails de onboarding SaaS: un contrato de eventos

El problema: onboarding sin evidencia

Qué debe contener el contrato de eventos

Implementación sencilla en el backend

Cómo probar el flujo completo

Errores comunes

Recapitulación

Preguntas rápidas

SaaS: un contrato de estados para el onboarding

El onboarding también necesita un contrato

Qué estados conviene modelar

Una identidad de prueba por ejecución

¿Debo bloquear el onboarding hasta recibir `delivered`?

¿`accepted` significa que el email llegó?