El recorrido que solo empieza cuando termina otro

La mayoría de las plataformas de marketing hotelero tratan cada recorrido del huésped como si partiera de cero. Se activa un disparador, se incorpora un huésped, salen los mensajes, termina el recorrido y la plataforma olvida que alguna vez existió. Si quieres que un segundo flujo dependa de que el primero termine de verdad, y no solo de que empiece más o menos al mismo tiempo, la mayoría de los constructores te obligan a improvisar: etiquetar al huésped cuando el recorrido A envía su último mensaje, crear el recorrido B para que esté atento a esa etiqueta y confiar en que nada se adelante. Funciona hasta que deja de funcionar, normalmente la semana en que un huésped recibe dos veces la misma oferta de recuperación porque dos flujos pensaron que les correspondía gestionar el traspaso.

Los recorridos de GuestMaker evitan ese rodeo. Se puede indicar a un recorrido que espere a que termine otro recorrido concreto para un huésped, y no incorporará a ese huésped hasta que ese recorrido exacto se haya completado. No cuando "haya terminado cualquier recorrido", ni cuando "este segmento ya lo incluya". El que has nombrado.

Qué significa realmente un recorrido activado por otro recorrido

Dentro del menú de disparadores está journey.completed, uno de los dieciocho disparadores repartidos en seis categorías. Configurarlo implica elegir uno o varios recorridos de origen por id, no una categoría, ni una etiqueta, ni una suposición basada en el momento. Un huésped solo cumple el disparador cuando uno de esos recorridos nombrados se ha completado para él de principio a fin, con sus ramas incluidas, y ha alcanzado un nodo final. Si el recorrido de origen nunca se completa para un huésped (porque sale antes, porque nunca encaja en una rama, por el motivo que sea), el recorrido dependiente tampoco se activa. Esa es precisamente la idea: el segundo flujo de trabajo está aguas abajo de un evento real, no de una señal indirecta.

Esto importa más de lo que parece sobre el papel. Una secuencia de bienvenida que termina en tres sitios distintos según cómo responde un huésped no está "terminada" en cuanto empieza. Está terminada cuando el huésped llega a uno de esos nodos finales. Un segundo recorrido que debe continuar desde ahí, por ejemplo, una comprobación de satisfacción unos días después del checkout, pero solo para huéspedes que hayan completado la secuencia de bienvenida en vez de abandonar el flujo, necesita distinguir entre "empezado" y "terminado". journey.completed está diseñado para reconocer esa diferencia.

Dentro de un recorrido real y multietapa para un grupo hotelero

En producción, esto no toma la forma de una línea recta. Un recorrido encadenado que hemos visto funciona así: se activa journey.completed para un recorrido de origen nombrado y, después, queda en un nodo de espera hasta una fecha u hora para no mover al huésped de inmediato. Desde ahí pasa por tres nodos anidados de división condicional, que forman un pequeño árbol de decisión. Cada una de las tres ramas resultantes termina en su propia plantilla de correo electrónico, adaptada al resultado de esa rama, en lugar de recurrir a un mensaje genérico con texto condicional dentro. Antes de que cualquiera de esos tres correos se envíe realmente, un nodo de envío a una hora concreta controla a qué hora del día llega el mensaje a la bandeja de entrada del huésped, de modo que una rama resuelta en mitad de la noche no se dispare en mitad de la noche. Después, cada rama se cierra en su propio nodo final.

No hay nada en esa estructura que sea un ejemplo de juguete. Es un árbol de decisión real, tal como se usa en producción: un punto de entrada, una espera, lógica de ramificación en tres vías, tres envíos distintos, control horario y tres líneas de llegada separadas. El valor del disparador journey.completed situado delante de todo ello está en que todo el árbol solo empieza cuando el huésped ha salido de verdad por el otro lado de lo que venía antes.

Dieciocho disparadores detrás del constructor de recorridos de huéspedes de GuestMaker

El encadenamiento es uno de los dieciocho disparadores, y conviene ver dónde encaja respecto al resto, porque lo interesante de un constructor de recorridos de huéspedes para hoteles no es un disparador aislado, sino cuántos eventos reales distintos pueden iniciar una secuencia sin que el equipo de marketing tenga que escribir una solución provisional para cada caso.

Los eventos de reserva cubren reservas creadas, actualizadas, canceladas y no-shows. Los eventos de huésped cubren check-in y checkout. Los disparadores de mensajería responden a un mensaje entrante, con filtros para palabras clave concretas o para el primer mensaje que envía un huésped. Segmentos y etiquetas cubren la entrada de un huésped en un segmento, la adición de una etiqueta, la suscripción de un contacto, y tanto la creación como la actualización de contactos; esta última puede vigilar campos concretos en lugar de reaccionar ante cualquier cambio. Los disparadores programados cubren cumpleaños, aniversarios de fecha, huéspedes inactivos y un disparador programado genérico que se ejecuta a diario, semanalmente, mensualmente o con una expresión cron para cualquier necesidad más específica. Y también están la incorporación manual y un disparador personalizado activado por una llamada a una API externa, para lo que necesiten iniciar los sistemas propios de un grupo hotelero.

journey.completed vive en esa misma lista de disparadores, no añadido al margen. Es deliberado: un recorrido que depende de que termine otro recorrido debe configurarse exactamente igual que uno que depende de la cancelación de una reserva, a través del mismo selector de disparadores, no mediante un modo "avanzado" separado que el equipo de marketing tenga que buscar.

Por qué los flujos de marketing encadenados necesitan secuenciación real, no solo etiquetas

La solución de etiquetar y vigilar no es incorrecta. Simplemente es frágil de una manera muy concreta: depende de que el primer recorrido recuerde escribir la etiqueta en el momento adecuado, de que el segundo recorrido recuerde filtrarla correctamente y de que nada más en la cuenta toque nunca esa etiqueta por un motivo no relacionado. Cada uno de esos puntos puede romper la cadena en silencio, y ninguno lanza un error cuando ocurre. Un huésped sencillamente nunca recibe el recorrido B, o lo recibe en el momento equivocado, y nadie se da cuenta hasta que alguien lo comprueba de casualidad.

Un disparador que vigila directamente el recorrido de origen no abre esa vía de fallo. No hay una etiqueta intermedia que pueda desincronizarse, ni una lógica de filtrado separada que haya que mantener alineada con un objetivo móvil. La dependencia es el evento real de finalización, lo que significa que un grupo hotelero que construye flujos de marketing encadenados, una secuencia de bienvenida que alimenta una comprobación de satisfacción, una secuencia de confirmación de reserva que alimenta una secuencia preestancia, está creando un grafo de dependencias explícito y no un conjunto de flujos que hoy coinciden en una convención de nombres.

Piensa en un grupo con varios establecimientos que ejecuta una secuencia de inscripción al programa de fidelización. El grupo quiere que un segundo recorrido, que profundiza en los beneficios continuos del programa, llegue al huésped solo cuando haya terminado realmente la inscripción, no en el momento en que entró en ella. Con una configuración basada en etiquetas, "se incorporó" y "terminó la inscripción" pueden parecer idénticos si la etiqueta se aplica pronto para facilitar la creación posterior del segmento. Con un disparador journey.completed limitado al id exacto de ese recorrido de inscripción, no hay ambigüedad que resolver en el diseño. La misma lógica se aplica a una secuencia preestancia que alimenta una solicitud de reseña posestancia: la petición de reseña debe llegar a los huéspedes que completaron la secuencia preestancia, no a quienes la abandonaron a medio camino, y la diferencia entre esas dos poblaciones de huéspedes es exactamente para lo que sirve el seguimiento de finalización.

Qué no hace todavía

Conviene decirlo con claridad: esto no es encadenamiento ilimitado. Lo que existe y está publicado es un enlace único y bien definido: un recorrido que depende de que se completen uno o varios recorridos previos concretos y nombrados. No hemos verificado que una cadena avance más allá de ese salto, con la finalización del recorrido A activando B y la propia finalización de B activando a su vez C, y no estamos afirmando que lo haga. Si tu caso de uso necesita una cadena de varios saltos, prueba cada enlace por separado en lugar de asumir que la fiabilidad del primer salto se mantiene en el siguiente.

Dónde encaja

Nada de esto sustituye a los otros diecisiete disparadores. Convive con ellos. El valor aparece específicamente cuando la lógica de un flujo depende de verdad del resultado de otro flujo, no solo del momento en que ocurre, cuando "después de que terminen la serie de bienvenida" significa algo distinto de "unos días después de que llegaran". Esa distinción se difumina fácilmente con etiquetas y se mantiene clara con un disparador diseñado para vigilar directamente la finalización. Si tu configuración actual de recorridos depende de que un huésped lleve la etiqueta correcta en el momento adecuado como sustituto de "haber terminado", merece la pena comprobar si lo que realmente necesitas es un id de recorrido de origen y un disparador journey.completed.