¿Dónde empieza la secuencia de prueba a pago?
El onboarding y los emails de prueba a pago hacen dos trabajos distintos. La secuencia de onboarding tiene un solo objetivo: llevar al usuario a su momento aha, el punto en que el valor del producto resulta evidente. Eso es activación. No es una compra.
La secuencia de prueba a pago empieza ahí. Da por hecho que el valor ya se ha entregado y hace lo único que el onboarding no hace: pedir la tarjeta. Si el onboarding corresponde a la etapa del ciclo de vida de activación, esta secuencia corresponde a la decisión de pasar de la prueba al pago: un empujón corto y en el momento justo que termina antes que la prueba.
¿Cómo es la secuencia y cuándo sale cada email?
Seis emails, repartidos a lo largo de la prueba. Algunos se disparan por comportamiento y otros por calendario. Los dos primeros reaccionan a lo que hace el usuario; los cuatro últimos cuentan los días hasta la caducidad. Un motor de journeys gestiona la mezcla: un nodo wait_for_event retiene el email de activación hasta que el usuario se activa de verdad, y un nodo de rama envía a los usuarios activados y a los pasivos por caminos distintos.
| Prueba de 14 días | Prueba de 30 días | |
|---|---|---|
| Comprobación de activación | Día 2 | Día 3 |
| Resumen de valor a mitad de prueba | Día 7 | Día 15 |
| Respuesta a la objeción (T-3) | Día 11 | Día 27 |
| Urgencia (T-1) | Día 13 | Día 29 |
| Caducidad / día de gracia | Días 14–15 | Días 30–31 |
| Recuperación tras la caducidad | Días 18–21 | Días 34–37 |
¿Qué debería decir cada email?
Los emails de resumen deben vincular el valor a lo que el usuario hizo realmente en el producto, no a tu lista de funciones. “Creaste 5 segmentos y lanzaste 2 journeys: esto es en lo que se convierte con un plan de pago” gana a “nuestra plataforma es muy potente”. Los detalles que reflejan su propia actividad son el argumento más sólido que tienes.
- Un resumen de valor vinculado a una acción real en el producto, con una cifra cuando la tengas
- Exactamente una objeción, nombrada y respondida: el precio, el esfuerzo de migración o una integración que falta
- Prueba social opcional: una línea, una cifra, de un equipo comparable
- Un único CTA claro (pasar al plan de pago) y nada que compita con él
- Lenguaje claro sobre lo que pasa al caducar: qué conserva y qué pierde
Elige la objeción que con más probabilidad frenará la compra y respóndela directamente: no enumeres cinco. Este es el criterio que aporta un Lifecycle Marketer: saber qué objeción es real para este segmento. Si estás construyendo el sistema más amplio en el que viven estos emails, consulta marketing de ciclo de vida para startups.
El día de caducidad y el periodo de gracia
El email del día de caducidad no es una nota al pie. Envíalo en el momento en que termina la prueba: di que el acceso ha cambiado y ofrece un camino de vuelta. Después añade un breve periodo de gracia (uno o dos días en los que la cuenta sigue funcionando) y dilo. Si pides la tarjeta al principio, ten en cuenta las reglas de plazos: Userlist señala que redes de tarjetas como Visa exigen al menos siete días de aviso antes de que una prueba se convierta en un cargo de pago, así que tus recordatorios tienen que salir con la antelación suficiente para cumplirlas.
No trates la caducidad como el final. Encharge, citando un análisis de MadKudu, indica que cerca de la mitad de las conversiones SaaS pueden producirse después de que termine la prueba, y por eso una recuperación tras la caducidad se gana su lugar. Envía una reactivación más ligera unos días después. Y cuando un usuario convierte, la siguiente fuga es la facturación: un cargo fallido hace que un cliente de pago se pierda sin hacer ruido, así que combina esta secuencia con la gestión de impagos y recuperación de pagos fallidos.
¿Deberías ofrecer un descuento?
Con moderación. Un 20 % de descuento fijo en cada email de fin de prueba enseña a la gente a dejar caducar la prueba y esperar el cupón: enseñas a tus usuarios con más intención de compra a esperar. Mejor una urgencia honesta y un resumen de valor durante la prueba activa. Reserva el descuento para una recuperación dirigida a los usuarios que dejaron caducar la prueba sin convertir, donde es una segunda oferta genuina y no un acto reflejo. Herramientas como Customer.io, Encharge y Loops pueden limitar esa oferta a un segmento concreto de usuarios con la prueba caducada.
¿Cómo se mide la conversión de prueba a pago?
La tasa de conversión de prueba a pago es el número de clientes de pago dividido entre las pruebas iniciadas en la misma cohorte. Agrupa las cohortes por semana de registro, no por mes natural, o los registros tardíos distorsionan la tasa. Segméntala entre usuarios activados y no activados; la cohorte activada es la que tus emails pueden mover. Los benchmarks varían mucho según el diseño de la prueba: Baremetrics indica que las pruebas opt-in (sin tarjeta) suelen convertir en torno al 15–25 %, mientras que las pruebas con tarjeta por adelantado suelen convertir más, aproximadamente un 40–60 %. Tómalos como puntos de referencia, no como objetivos: tu producto y tu audiencia marcan la cifra real.
El kit de inicio: eventos, journeys y mensajes
Todo lo que sigue es una plantilla para adaptar, no un resultado: nombres de eventos, reglas de journeys y borradores de mensajes pensados para una prueba de 14 días. Cambia la acción aha, la duración de la prueba y los nombres de los planes por los tuyos. El mismo kit está disponible como archivo Markdown para añadirlo a tu repositorio o a tu wiki.
Registra cinco eventos
Cinco eventos sostienen toda la secuencia. Envía los eventos de producto y de facturación desde tu servidor, donde un bloqueador de anuncios no puede descartarlos ni un visitante falsificarlos, y guarda los datos personales en el perfil y no en las propiedades de los eventos.
| Evento | Envíalo cuando | Propiedades | Se envía desde |
|---|---|---|---|
| signup_started | Se envía el formulario de registro, antes de verificar el email | source, plan_intent | Navegador |
| signup_completed | La cuenta existe y el email está verificado. Identifica aquí al usuario, con el ID que usa tu sistema de facturación | trial_ends_at, plan | Servidor |
| activated | El usuario completa tu acción aha por primera vez (defínela una sola vez, por ejemplo “primer informe compartido”) | activation_action, days_since_signup | Servidor |
| trial_expiring | Un proceso diario detecta que trial_ends_at está a tres días, y luego a un día | days_left, trial_ends_at | Servidor, programado |
| subscription_started | Tu proveedor de facturación confirma el primer cargo correcto | plan, interval, amount | Servidor, desde el webhook de facturación |
Dos reglas de nomenclatura mantienen el plan legible un año después: object_action en snake_case, y el pasado para lo que ya ha ocurrido. Escríbelo una vez, con un responsable: eso es todo lo que es un plan de tracking.
Construye tres journeys
Dos journeys de onboarding separan las pruebas activadas de las estancadas; el tercero rescata la prueba al caducar. Los tres comparten las mismas salvaguardas: todo el mundo sale en cuanto llega subscription_started, los contactos dados de baja o con rebote duro nunca entran, y las cuentas internas o de test se filtran en la entrada.
| 1 · Onboarding: primer valor | 2 · Onboarding: prueba estancada | 3 · Rescate al caducar la prueba | |
|---|---|---|---|
| Disparador | signup_completed | Ningún evento activated 48 horas después de signup_completed (lo traspasa el journey 1) | trial_expiring con days_left = 3 |
| Filtro de entrada | En un plan de prueba; no es una cuenta interna ni de test | Lo mismo, y sin respuesta al email de bienvenida | Todavía sin subscription_started |
| Pasos | Email de bienvenida → esperar hasta 48 horas a activated → email con el siguiente paso | Email de ayuda → esperar hasta 3 días a activated → mensaje de seguimiento en texto plano de una persona | Rama según activated: resumen de valor con una objeción respondida, o ayuda con una oferta de ampliación → recordatorio T-1 → email de caducidad y día de gracia → email de reactivación 4 días después |
| Supresión | Los contactos dados de baja o con rebote duro nunca entran; como máximo un email de marketing al día entre todos los journeys | Lo mismo; pausa mientras una persona responde a su mensaje | Lo mismo; omite el email de reactivación si respondió o reservó una llamada |
| Salida y objetivo | Objetivo: activated. Salida con subscription_started | Objetivo: activated. Salida con subscription_started | Objetivo y salida: subscription_started, en cualquier paso |
Adapta seis mensajes
| Mensaje | Asunto | Primera línea | Una única llamada a la acción |
|---|---|---|---|
| Onboarding (bienvenida) | Te damos la bienvenida a {product}: lo primero que debes hacer | La mayoría de los equipos obtienen valor de {product} el mismo día en que dan este paso: {aha_action}. Este es el camino más corto para llegar. | {aha_action} |
| Activación (siguiente paso) | Ya {aha_action_past}. Esto es lo que viene ahora | Es el paso al que la mayoría de las pruebas nunca llegan. El siguiente es {next_action}, y lleva unos cinco minutos. | {next_action} |
| Ayuda (prueba estancada) | ¿Te has atascado en {setup_step}? | Te registraste hace {days} días y todavía no {aha_action_past}. Normalmente es por {common_blocker}: aquí tienes la solución, o responde y te ayudará una persona. | Responde a este email |
| Prueba a punto de terminar (T-3, T-1) | Quedan {days_left} días: lo que has construido hasta ahora | Hasta ahora: {usage_summary}. Con {plan}, todo seguirá funcionando después del {trial_end_date}. | Elige un plan |
| Caducidad (día de gracia) | Tu prueba ha terminado. Tu trabajo sigue aquí | Tu prueba terminó el {trial_end_date}. Tus {objects} se conservan durante {grace_days} días, así que puedes elegir un plan sin perder nada. | Conservar mi cuenta |
| Reactivación (recuperación) | Retoma donde lo dejaste | Desde tu último inicio de sesión, hemos lanzado {relevant_change}. Tus {objects} siguen aquí si quieres echar otro vistazo. | Reiniciar mi prueba |
Los marcadores entre llaves salen de las propiedades del perfil y de los datos de los eventos. Escribe primero cada mensaje en texto plano, mantén una única llamada a la acción, deja los descuentos fuera de la secuencia principal y saca cada afirmación sobre la actividad del usuario de una propiedad real, nunca de una suposición.
Antes de activarlo
- Prueba cada journey con un perfil de test: dispara cada evento a mano y comprueba quién entra, quién espera y quién sale.
- Paga con una tarjeta de prueba a mitad del journey 3 y confirma que los emails restantes se detienen.
- Envía en la zona horaria de cada usuario, nunca de madrugada, y limita el email de marketing a uno al día entre todos los journeys.
- Si pides la tarjeta al principio, empieza los recordatorios con la antelación suficiente para cumplir las reglas de aviso de las redes de tarjetas descritas arriba.
- Mide la conversión de prueba a pago por cohortes de semana de registro, y mantén un pequeño grupo de control si quieres saber qué aporta la secuencia por sí misma.
Cualquier herramienta de journeys con disparadores por eventos, esperas que terminan con un evento y una regla de salida puede ejecutar este kit. En fromHello, los cinco eventos entran por el snippet de tracking o por la API, y cada journey de arriba se construye con los nodos propios del editor: send email, wait, wait for event, branch, goal y exit. Las startups de menos de dos años que hayan levantado menos de 5 M€ pueden solicitar 12 meses de fromHello Core a través de nuestro programa para startups.