Automatización de notificaciones push para viajes: 5 plantillas de flujo de trabajo

Es martes por la tarde y la revisión de retención finalizó a las 2:15 p. m. Tu tasa de conversión de reservas disminuyó 1.4 puntos el último trimestre, de 3.6% a 2.2%. El equipo de fidelización cree que la cadencia de correos electrónicos de recuperación se está enviando demasiado tarde. El equipo móvil cree que el push de reserva abandonada se superpone con las alertas de caída de precios. Nadie puede probar que una u otra sea la causa. Dos horas después del hilo de Slack posterior a la reunión, lo único en lo que todos están de acuerdo es que el panel no es lo suficientemente granular como para resolver la discusión.

La automatización de notificaciones push para viajes se encuentra en el centro de esta discusión, y nadie en el equipo de retención está seguro de cómo defenderla. El push automático de confirmación de reserva se activa cuando se completa una reserva. El disparador de reserva abandonada vuelve a notificar el mismo itinerario 24 horas después, y a veces ese itinerario ya no tiene el precio que el viajero abandonó, porque la tarifa cambió durante la noche. El disparador de advertencia de abandono que alguien configuró hace dos años todavía se activa cuando el DAU (usuarios activos diarios) cae en la aplicación, pero no sabe que el suscriptor está actualmente en viaje y no está realmente abandonando, solo de vacaciones. Tres mecanismos "automatizados", ninguno consciente del otro, ninguno con una visión coherente de dónde se encuentra el viajero en el ciclo de vida del viaje.

Este artículo analiza cómo debería ser realmente la automatización de notificaciones push de viajes —arquitectura de flujo de trabajo, no transmisiones de confirmación de reserva con un disparador de reserva abandonada añadido— y presenta cinco planos de flujo de trabajo con forma de viaje, con tiempos, criterios de salida para el momento del cambio de tarifa, manejo en viaje activado por geolocalización y las matemáticas de ingresos que convierten cada uno en un elemento defendible para operaciones de publicidad y el equipo de fidelización.

Por qué tus "notificaciones push automatizadas" de viajes están perdiendo ingresos en el momento del cambio de tarifa

La palabra automatización ha estado haciendo el mismo trabajo inmerecido en viajes que en eCommerce, SaaS y publicaciones. Cuando la mayoría de los equipos de CRM de viajes hablan de notificaciones push automatizadas para viajes, lo que quieren decir es la programación de transmisiones activadas por eventos: una notificación se dispara cuando ocurre un evento conocido, sin estado, sin segmentación, sin esperas entre contactos, sin condiciones de salida y, de manera crítica, sin conciencia de que la oferta subyacente puede que ya no sea válida cuando se activa el segundo contacto.

Un flujo de trabajo es algo diferente. Un flujo de trabajo es un viaje de varios pasos con estado. Sabe cuándo el viajero abandonó la reserva, qué tarifa vio, qué tarifa se cotiza actualmente en ese itinerario, cuál es el estado de su viaje y qué condiciones cancelan el viaje. El flujo de trabajo de reserva abandonada no se limita a enviar un recordatorio push 24 horas después. Comprueba si la tarifa sigue siendo válida antes de cada contacto, sale del flujo de trabajo en el momento en que se completa la reserva y sale por separado si la tarifa cambia, porque enviar “completa tu reserva de 399 €” a un viajero cuando la tarifa ahora es de 529 € destruye la confianza de una manera que ninguna reserva recuperada justifica jamás.

Esa última cláusula es la diferencia. Los desencadenantes de eventos no tienen memoria del estado externo. Los flujos de trabajo sí. Si tu automatización de reserva abandonada sigue enviando notificaciones a los viajeros con la tarifa antigua después de que la tarifa haya cambiado, no tienes una automatización. Tienes un desencadenante al que nadie le dijo que comprobara.

Para un equipo de CRM de viajes de mercado medio, esta distinción es la diferencia entre un LTV de reservas recurrentes que se acumula y uno que se erosiona por errores que destruyen la confianza en el momento del cambio de tarifa. Tres desencadenantes ejecutándose en paralelo producen tres canales de fricción. Cinco flujos de trabajo ejecutándose en coordinación producen un viaje por viajero por etapa del viaje, ramificado y limitado por el estado de la reserva, la validez de la tarifa y el estado del viaje. Los resultados de la primera página de búsqueda para esta palabra clave enmarcan el problema como “5 casos de uso de viajes” y responden con una lista de herramientas. Esa no es la pregunta que tu revisión de retención del martes está haciendo.

La anatomía de un flujo de trabajo de notificación push de viajes

Antes de los planos, el vocabulario. Un flujo de trabajo de notificación push de viajes se construye a partir de seis tipos de nodos. Una vez que sepas lo que hace cada uno, cada plano se lee como un diagrama, no como una descripción.

INICIO. El punto de entrada. Un nodo INICIO define cómo se activa el flujo de trabajo, ya sea por un evento del suscriptor (booking_initiated, booking_abandoned, fare_changed, geolocation_changed, trip_completed) o por un filtro de audiencia (lifecycle_stage, loyalty_tier, last_active). Un flujo de trabajo tiene exactamente un INICIO.

ESPERAR. Un retraso. Un nodo WAIT retiene al suscriptor durante un período especificado (minutos para la reactividad durante el viaje, horas para el ritmo de reserva abandonada, días para la cadencia previa al viaje) o hasta una hora de calendario específica utilizando la semántica wait_until vinculada a un atributo del suscriptor: departure_date - 7 días, departure_date - 1 día, trip_completion_date + 1 año. Las esperas son la forma en que un flujo de trabajo honra un evento futuro conocido, no solo uno pasado.

DECISIÓN. Una bifurcación de dos vías. Un nodo DECISION comprueba una condición por suscriptor: ¿ha completado la reserva?, ¿sigue siendo válida la tarifa (leído de un atributo del suscriptor que el sistema de reservas actualiza)?, ¿el nivel de fidelidad está por encima de plata?, ¿el viajero está actualmente en viaje? Los nodos DECISION evalúan filtros de eventos y filtros de audiencia; no consumen cuerpos de respuesta de HttpRequest directamente. El patrón que introduce el estado externo en un flujo de trabajo es que la acción HttpRequest activa el sistema externo, el sistema externo escribe de nuevo en un atributo del suscriptor a través de la API REST de PushEngage, y la DECISIÓN lee el atributo.

SPLIT_PATH. Una bifurcación basada en porcentajes. Los nodos SPLIT_PATH dirigen a los suscriptores a través de diferentes rutas según porcentajes configurados: 50/50 para una prueba A/B sobre los importes de descuento de reservas abandonadas, 33/33/34 para una prueba de hora de envío de tres vías sobre recordatorios previos al viaje. Una vez que tenga un ganador, promocionará esa ruta al 100%.

ACCIÓN. El trabajo en sí. Los nodos ACTION envían una notificación push, añaden al suscriptor a un segmento, actualizan atributos personalizados, disparan una HttpRequest a un sistema de reservas o pasarela SMS, inician otro flujo de trabajo o detienen uno. PushEngage Workflows admite once tipos de acciones. Los más útiles para viajes son SendPushNotification, UpdateAttribute, HttpRequest y Workflow.Start (para encadenar pre-viaje, durante el viaje y post-viaje).

FIN / SALIDA. Lo terminal. END marca la conclusión natural. EXIT marca una terminación temprana: en el camino NO de una Decisión cuando el viajero ya no califica, cuando se activa la regla de enfriamiento, o cuando se cumple el objetivo (reserva completada, viaje cancelado, tarifa invalidada).

Cada plano a continuación se compone de estas seis piezas.

Cinco planos de flujo de trabajo para viajes

Estas no son plantillas. Son planos de trabajo. Cada uno enumera su disparador, tipo de ejecución, secuencia de nodos, criterios de salida y la métrica de retención de viajes que está diseñado para mover. Puede cargar cada uno en el constructor de PushEngage Workflows y enviar la primera versión en menos de una hora. La guía de notificaciones push de viajes heredada cubre los casos de uso más amplios que implementan estos planos.

Plano 1 — Bienvenida + nutrición de la primera reserva

• Disparador (INICIO): Evento PushEngage.Subscriber.Added O browse_destination_page_view
• Tipo de ejecución: Único (un viaje de bienvenida por viajero por ventana de 90 días)
• Flujo: Push de bienvenida con destinos-más-populares → ESPERAR 1 día → push de preferencia de destino preguntando qué tipos de viaje importan (playa, esquí, escapada urbana, negocios) → ESPERAR 2 días → DECISIÓN: ¿ha iniciado el suscriptor una reserva? → ruta SÍ: encadenar al Blueprint 2 si abandonan, de lo contrario, dejar que el flujo de trabajo previo al viaje se encargue después de booking_completed → ruta NO: enviar un push de recomendación curada de tres destinos, añadir al segmento active_browsers, FIN
• Criterios de salida: Objetivo booking_completed
• Métrica de viaje: Tasa de conversión de navegación a primera reserva a los 7 días.

Plano 2 — Reserva abandonada con salida por cambio de tarifa (automatización de notificaciones push de abandono de reserva)

• Desencadenante (INICIO): Evento personalizado booking_abandoned con carga útil itinerary_id
• Tipo de ejecución: Múltiples en paralelo (cada reserva abandonada es su propia instancia de flujo de trabajo)
• Flujo: ESPERAR 1 hora → ACCIÓN: HttpRequest GET al punto final de verificación de tarifas de su sistema de reservas para el itinerary_id. El sistema de reservas escribe en un atributo del suscriptor a través de la API REST de PushEngage: fare_status = valid o fare_status = invalidated — en segundos → DECISIÓN: ¿filtro de audiencia fare_status = valid? → ruta NO: enviar un push de “su tarifa ha cambiado, aquí tiene opciones similares al nuevo precio” y SALIR (reenrutamiento elegante, sin violación de la confianza) → ruta SÍ: push de recordatorio con la tarifa original → ESPERAR 24 horas → repetir la verificación de tarifas HttpRequest, luego DECISIÓN sobre fare_status = valid Y filtro de audiencia booking_completed = false → ruta SÍ: recordatorio n.º 2 con un código de promoción del 10% → ESPERAR 48 horas → recordatorio final con una oferta más fuerte → FIN
• Criterios de salida: Objetivo booking_completed que coincida con el itinerary_id del desencadenante O filtro de audiencia fare_status = invalidated
• Métrica de viaje: Valor de reserva recuperado por reserva abandonada. Este es el flujo de trabajo con la línea de ingresos más defendible en la página. La publicación 6 consejos para reducir el abandono de reservas cubre la versión de táctica manual de este blueprint; la versión del flujo de trabajo añade la salida de validez de la tarifa que convierte una recuperación táctica en una que preserva la confianza en la marca.

Plano 3 — Nutrición previa al viaje (matemáticas de la fecha de salida)

Este es el flujo de trabajo de notificación push previo al viaje que demuestra la semántica de wait_until vinculada a un atributo del suscriptor.

• Desencadenante (INICIO): Evento personalizado booking_completed (que escribe departure_date en un atributo del suscriptor)
• Tipo de ejecución: Única por reserva
• Flujo: ESPERAR hasta fecha_salida - 14 días → push de “tu viaje es en dos semanas” con recomendaciones de equipaje y pronóstico del tiempo → ESPERAR hasta fecha_salida - 7 días → push de ingresos auxiliares (mejora de asiento, mejora de habitación, adición de alquiler de coche, traslado al aeropuerto) → ESPERAR hasta fecha_salida - 1 día → push de recordatorio de check-in con enlace a la tarjeta de embarque móvil → ESPERAR hasta fecha_salida → push de bon-voyage, FIN
• Criterios de salida: Objetivo reserva_cancelada
• Métrica de viaje: Ingresos auxiliares por reserva. El toque 7 días antes es el momento de mayor influencia para los auxiliares.

Plano 4 — Geolocalización en viaje (automatización de notificaciones push por geolocalización)

• Disparador (INICIO): Evento personalizado ubicacion_geografica_cambiada (disparado por tu aplicación móvil cuando el dispositivo informa una nueva lat/lng) Y filtro de audiencia viaje_en_curso = verdadero
• Tipo de ejecución: Múltiple en paralelo
• Flujo: DECISIÓN: ¿ha llegado el viajero a la ciudad de destino (el filtro de audiencia compara las coordenadas de geolocalización con un geovallado de destino almacenado como atributo del suscriptor)? → ruta SÍ: ACCIÓN enviar push de recomendaciones locales (hoteles, restaurantes, actividades locales vinculadas al destino), ACCIÓN HttpRequest a la API del tiempo → si se justifica una alerta meteorológica, ACCIÓN enviar notificación meteorológica → FIN → ruta NO: SALIR (el viajero está en tránsito, no en el destino)
• Horas de silencio: consciente de la zona horaria del suscriptor. Workflows.md §9.4 resuelve las horas de silencio primero por zona horaria del suscriptor, luego por zona horaria del sitio, luego por UTC. Para flujos de viaje, esto significa que la zona horaria respeta la hora local del destino, no el mercado de origen de la marca. Los pushes no críticos usan saltar; las alertas de seguridad y meteorológicas usan reprogramar para garantizar la entrega
• Criterios de salida: Objetivo viaje_completado
• Métrica de viaje: Tasa de participación durante el viaje e ingresos auxiliares durante el viaje. Nota: ubicacion_geografica_cambiada no es un tipo de disparador integrado — es un PushEngage.CustomEvent que tu aplicación móvil dispara cuando la ubicación del dispositivo se actualiza, y la comprobación en el destino es un filtro de audiencia sobre atributos del suscriptor que la aplicación mantiene. Las notificaciones push de geolocalización cubren la base de segmentación que este plano extiende.

Plano 5 — Revisión posterior al viaje + reserva de seguimiento de similares

• Disparador (INICIO): Evento personalizado viaje_completado
• Tipo de ejecución: Múltiple Secuencial
• Flujo: ESPERAR 3 días → push de solicitud de reseña haciendo referencia al destino por nombre → ESPERAR hasta fecha_finalización_viaje + 365 días (un año después) → push de “¿listo para tu próximo viaje?” con una oferta similar al destino basada en el tipo de viaje anterior → ESPERAR 7 días → DECISIÓN: ¿inició el viajero una reserva? → ruta SÍ: encadenar en el Plano 1 o 2 → ruta NO: SALIR
• Criterios de salida: Nuevo evento reserva_iniciada O desuscrito
• Métrica de viaje: Tasa de reservas repetidas a 12 meses. Este es el blueprint de mayor duración —unos 13 meses— y el que tiene el mayor impacto en el LTV. El patrón de lookalike año tras año es el análogo de viajes de la recuperación postcompra en eCommerce, adaptado a la cadencia estacional que realmente siguen los compradores de viajes.

Segmentación por etapa del ciclo de vida, pruebas A/B, horas de silencio por zona horaria de destino y criterios de salida dentro del flujo de trabajo

El patrón dominante en los artículos de push de viajes es enumerar estos cuatro conceptos como "mejores prácticas" — viñetas genéricas al final de una publicación de estrategia, divorciadas de las campañas que las utilizan. Ese es el marco equivocado. No son mejores prácticas que se sientan junto al flujo de trabajo. Son el flujo de trabajo.

Concepto	Encuadre de mejores prácticas (incorrecto)	Encuadre de nodos de flujo de trabajo (correcto)
Segmentación por etapa del ciclo de vida	“Segmentar viajeros por etapa del viaje”	Un nodo DECISION sobre el atributo del suscriptor lifecycle_stage (navegando / inicio de reserva / pre-viaje / en viaje / post-viaje / inactivo) que dirige a los viajeros pre-viaje a nudges auxiliares, a los viajeros en viaje a flujos de trabajo de geolocalización, a los viajeros post-viaje a reseñas y a lookalike para reservar de nuevo.
Pruebas A/B	“Realiza siempre pruebas A/B de tu copia de reserva abandonada”	Un nodo SPLIT_PATH con una asignación del 50/50, suscriptores balanceados por ruta, y un campo winner_edge_id que promociona al ganador al 100% una vez que la prueba alcanza significancia — la mayoría de las pruebas A/B de viajes se ejecutan en el monto del descuento en el recordatorio n.º 2.
Horas de silencio por zona horaria de destino	“No envíes notificaciones a las 3 AM”	Una opción a nivel de flujo de trabajo con timezone: subscriber y una configuración fallback que skipea el envío (notificaciones no críticas) o lo reschedulea para un minuto después de que terminen las horas de silencio (seguridad, clima, cambio de puerta) — crítico para flujos de trabajo en viaje donde la zona horaria local del suscriptor es el destino, no el mercado de origen de la marca.
Criterios de salida	“Detén la secuencia de reserva abandonada una vez que reserven”	Una regla a nivel de flujo de trabajo que verifica al viajero contra el objetivo booking_completed Y el atributo fare_status = invalidated antes de cada nodo, y cancela el flujo de trabajo si alguno coincide — la segunda condición es lo que ningún resultado de SERP describe.

La diferencia importa porque las viñetas de mejores prácticas son fáciles de aceptar con la cabeza y difíciles de aplicar. Los nodos del flujo de trabajo se aplican por el motor. El DECISION se ejecuta cada vez. El SPLIT_PATH balancea a cada viajero. El fallback de horas de silencio se activa sin que nadie recuerde verificar la zona horaria del destino. La regla de salida cancela el flujo de trabajo de reserva abandonada, independientemente de si el propietario de la campaña está prestando atención.

Para el flujo de reserva abandonada del Blueprint 2, esto significa que en el momento en que un viajero reserva — a la hora 1, a la hora 30 o a la hora 73 del flujo de trabajo — la regla de salida se activa, el flujo de trabajo se cancela para ese viajero y no se envía más notificaciones de "completa tu reserva" a alguien que ya pagó ayer. Por separado, en el momento en que la tarifa cambia y el sistema de reservas actualiza fare_status = invalidated, el flujo de trabajo se cierra con elegancia y envía la notificación de recuperación "tarifa cambiada, aquí tienes opciones similares". Sin violación de la confianza. Sin llamadas enfadadas al servicio de atención al cliente.

Orquestación multicanal: push web, push de aplicación, SMS, WhatsApp, correo electrónico

Las marcas de viajes gestionan más canales que los equipos de eCommerce, SaaS o de editores. Notificaciones push web para el flujo de reserva en el escritorio. Notificaciones push de la app para viajeros que descargaron la app de la marca. SMS como canal resistente a la itinerancia de datos para alertas críticas durante el viaje (cambio de puerta de embarque, retraso del vuelo, clima). WhatsApp para atención al cliente de alto contacto y viajeros internacionales en regiones donde WhatsApp es el mensajero predeterminado. Email como contenedor del itinerario previo al viaje en formato largo. Componer los cinco dentro de un flujo de trabajo, eligiendo el canal que coincide con el estado del suscriptor, es lo que marca la diferencia entre un equipo de CRM que ofrece un viaje coherente y uno que tiene que disculparse por una notificación push a las 3 AM de "tu vuelo está a tiempo" que despertó a un viajero en una zona horaria de destino.

Un viaje compuesto de cambio de puerta de embarque durante el viaje se lee así:

• INICIO: Evento personalizado gate_change para un itinerario donde trip_in_progress = true
• DECISIÓN: ¿está el viajero en la app móvil de la marca actualmente?
  • SÍ: ACCIÓN enviar notificación push de la app (menor fricción, entrega consciente de la itinerancia de datos)
  • NO: continuar
• DECISIÓN: ¿está el viajero en itinerancia internacional (filtro de audiencia por country no igual a home_country)?
  • SÍ: ACCIÓN enviar SMS a través de HttpRequest a Twilio o Plivo (SMS utiliza la red de voz celular, no de datos, resistente cuando los datos de itinerancia son limitados)
  • NO: ACCIÓN enviar notificación push web (el viajero puede estar en Wi-Fi del hotel)
• ACCIÓN: HttpRequest a ESP para actualizar el próximo resumen del itinerario por correo electrónico
• FIN en gate_acknowledged o flight_boarded

Una identidad de viajero, un flujo de trabajo, cuatro canales elegidos por estado. El canal viable más barato va primero. SMS, el más caro por envío, solo se activa cuando el viajero está en itinerancia internacional y el mensaje es crítico en tiempo. Booking.com enmarcó la mensajería móvil como "interacción con el cliente en tiempo real" en lugar de marketing masivo; este flujo de trabajo compuesto es la misma filosofía expresada como arquitectura de flujo de trabajo.

Ejecutar esto con herramientas separadas significa cinco inicios de sesión de proveedores, dos motores de segmentación que no están de acuerdo sobre quién está actualmente en viaje y ninguna atribución de ingresos única por viajero por canal. Hacerlo dentro de un motor de flujo de trabajo significa una identidad de viajero, un conjunto de lógica de decisión y un informe de embudo que muestra dónde se rompe realmente el viaje. La acción HttpRequest (Workflows.md §5.7) es lo que hace posible la orquestación entre canales: une el motor de flujo de trabajo con la pasarela SMS, el ESP y el sistema de reservas sin requerir una herramienta de orquestación separada.

Las matemáticas de retención: aumento de la conversión de reservas y LTV (valor de vida del cliente) de reservas repetidas en tamaños de billetes de viaje

La monetización de viajes es de alto valor. Los valores de reserva oscilan entre vuelos de corta distancia de 300 $ y paquetes vacacionales de más de 5000 $, lo que cambia el cálculo de costes en comparación con el comercio electrónico (cestas de 50-200 $) y SaaS (99-999 $ ARR). PushEngage Workflows rastrea las mismas tres cifras en cada nodo: en cola, completado, salido, y el mismo patrón de análisis a nivel de nodo se aplica. Los ingresos por reserva recuperada superan con creces los ingresos por cesta recuperada, lo que facilita la defensa de la contribución del flujo de trabajo a la cuenta de pérdidas y ganancias.

Así es como se ven los análisis a nivel de nodo para un flujo de trabajo activo de reserva abandonada en una OTA de mercado medio con 5000 reservas abandonadas mensuales a un precio medio de 1200 $ (cifras ilustrativas):

Nodo	En cola	Completado	Salido	Notas
INICIO (reserva_abandonada)	0	5,000	0	Entran todos los itinerarios abandonados
ESPERAR 1 hora	92	4,900	8	8 reservados en la primera hora sin intervención
ACCIÓN: HttpRequest comprobación de tarifa	0	4,900	0	El sistema de reservas actualiza el atributo fare_status
DECISIÓN: fare_status válido	0	4,410	490	490 itinerarios con tarifa invalidada antes de la primera intervención: salida elegante a través de un push de "tarifa cambiada"
ACCIÓN: recordatorio n.º 1 (tarifa original)	0	4,410	0	Primer recordatorio enviado
ESPERAR 24 horas	134	3,950	326	326 reservados después del recordatorio n.º 1
Segunda comprobación de tarifa + DECISIÓN	0	3,720	230	Otros 230 itinerarios con tarifa invalidada: salida elegante
ACCIÓN: recordatorio n.º 2 + promoción del 10 %	0	3,720	0	Segundo recordatorio
ESPERAR 48 horas	78	3,200	442	Otros 442 reservados después del recordatorio n.º 2
ACCIÓN: recordatorio final + oferta más fuerte	0	3,200	0	Último push
FIN	n/d	3,200	n/d	3200 no reservaron

En esta cohorte, 776 itinerarios abandonados se convirtieron en reservas dentro del flujo de trabajo: una tasa de recuperación del 15,5 %. Con un valor medio de reserva de 1200 $, eso son 931 200 $ de ingresos recuperados al mes, o 11,2 millones de dólares anualizados. Las salidas por cambio de tarifa evitaron que otras 720 relaciones con viajeros recibieran un push engañoso de "completa tu reserva de 399 $ " cuando la tarifa ya había subido: 720 tickets de atención al cliente y violaciones de la confianza en la marca que el flujo de trabajo evitó, aparte del aumento de la conversión de reservas.

El cálculo de costes se reformula para viajes. Los push web y los push de aplicaciones no cuestan nada por envío después de la suscripción. Los SMS a través de Twilio cuestan aproximadamente 0,0079 $ por mensaje nacional de EE. UU. y 0,05-0,30 $ por mensaje internacional; con 5000 cohortes de reservas abandonadas al mes y una cuota del 10 % de SMS en viaje, eso son 40-150 $ por cohorte en gasto de SMS. Los precios de WhatsApp Business Platform se basan en sesiones. El correo electrónico escala con el contrato del ESP. El trabajo del flujo de trabajo es utilizar primero el canal viable más barato y escalar a SMS o WhatsApp solo cuando el estado lo exija. La línea de artículo que dice "el flujo de trabajo de reserva abandonada recuperó 931 000 $ en reservas mensuales con un coste total de canal de 1500 $ " es el tipo de declaración de P&L que gana la conversación presupuestaria del próximo año.

Constrúyelo en PushEngage Workflows para tu marca de viajes

Cada uno de los cinco planos de viaje se mapea directamente a los componentes de PushEngage Workflows. El mapeo:

Plano	Tipos de nodos utilizados	Tipos de acciones utilizados	Opción de flujo
Bienvenida + nutrición de primera reserva	INICIO, ESPERA, DECISIÓN, ACCIÓN, FIN	SendPushNotification, AddSegment	Tipo de ejecución: Único
Reserva abandonada con salida por cambio de tarifa	INICIO, ESPERA, ACCIÓN, DECISIÓN, FIN	SendPushNotification, HttpRequest, UpdateAttribute	Tipo de ejecución: Múltiple Paralelo; salir en el objetivo booking_completed O filtro de audiencia fare_status=invalidated
Nutrición previa al viaje (cálculo de fecha de salida)	INICIO, ESPERA (wait_until), ACCIÓN, FIN	EnviarNotificaciónPush	Tipo de ejecución: Única por reserva; wait_until ligado al atributo departure_date
Geolocalización durante el viaje	INICIO, DECISIÓN, ACCIÓN, FIN	SendPushNotification, HttpRequest, UpdateAttribute	Tipo de ejecución: Múltiple en paralelo; evento personalizado + filtro de audiencia
Revisión posterior al viaje + nueva reserva similar	INICIO, ESPERA, ACCIÓN, ESPERA (wait_until), ACCIÓN, DECISIÓN, FIN	EnviarNotificaciónPush	Tipo de ejecución: Múltiple Secuencial

El motor de Workflows incluye más de 60 plantillas predefinidas que cubren los bloques de construcción de cada blueprint. La mayoría de las plantillas están orientadas a eCommerce, pero la adaptación a viajes es sencilla: la lógica de la plantilla de carrito abandonado se convierte en un flujo de trabajo de reserva abandonada al cambiar el evento desencadenante a booking_abandoned, añadir el patrón de comprobación de tarifas de HttpRequest-and-attribute-update del Blueprint 2 y utilizar un criterio de salida de invalidación de tarifas junto con booking_completed. La plantilla de bienvenida se ajusta directamente al Blueprint 1. La plantilla de goteo de geolocalización, ya en el catálogo, es la base del flujo de trabajo durante el viaje del Blueprint 4.

Para el contexto más amplio de campañas de viajes, casos de uso específicos de nicho (hoteles, vuelos, alquileres vacacionales) y estrategias de estacionalidad, el manual de notificaciones push para sitios de viajes existente cataloga los tipos de campañas que implementan estos blueprints.

Para la ruta de prueba inmediata, el plan gratuito te ofrece 200 suscriptores, todos los canales (notificaciones push web, push de app, WhatsApp, chat en vivo) y el motor completo de Workflows desde el primer día. Eso es suficiente para implementar los Blueprints 1 y 2 en tu próxima cohorte de itinerarios abandonados y capturar análisis a nivel de nodo antes del próximo QBR. Para el posicionamiento de PushEngage en el sector de viajes (precios, integraciones, ejemplos de clientes), PushEngage para viajes es la página de destino canónica.

Lo que esto cambia

Si te llevas una cosa de este artículo, llévate esto: la automatización de notificaciones push para viajes es arquitectura de flujos de trabajo, no transmisiones de confirmación de reservas con un disparador de reserva abandonada añadido. El viaje de reserva abandonada que finaliza elegantemente ante un cambio de tarifa, el flujo de trabajo previo al viaje que se activa en departure_date - 7 días, el flujo de trabajo de geolocalización durante el viaje que respeta la zona horaria del destino, todos tienen la misma forma. Un INICIO, algunas ESPERAS, algunas DECISIONES, algunas ACCIONES, una SALIDA. Tres disparadores independientes no pueden hacer esto. Un motor de flujos de trabajo sí puede. El LTV de repetición de reservas se acumula a partir de ahí.

Empieza con el plan gratuito para implementar el primer blueprint en tu próxima cohorte de itinerarios abandonados.