Automatisation des notifications push pour les voyages : 5 modèles de flux de travail

C'est mardi après-midi et la revue de rétention s'est terminée à 14h15. Votre taux de conversion des réservations a baissé de 1,4 point le trimestre dernier — passant de 3,6 % à 2,2 %. L'équipe fidélisation pense que la cadence des e-mails de relance est trop tardive. L'équipe mobile pense que le push de réservation abandonnée chevauche les alertes de baisse de prix. Personne ne peut prouver que l'un ou l'autre est la cause. Deux heures après le fil de discussion Slack post-réunion, la seule chose sur laquelle tout le monde s'accorde est que le tableau de bord n'est pas assez granulaire pour régler le débat.

L'automatisation des notifications push pour les voyages est au centre de cet argument, et personne dans l'équipe de rétention n'est sûr de comment la défendre. Le push automatique de confirmation de réservation se déclenche lorsqu'une réservation est complétée. Le déclencheur de réservation abandonnée renvoie le même itinéraire 24 heures plus tard — et parfois cet itinéraire n'est plus au prix que le voyageur a abandonné, car le tarif a changé pendant la nuit. Le déclencheur d'alerte de désabonnement que quelqu'un a mis en place il y a deux ans se déclenche toujours lorsque le DAU baisse sur l'application, mais il ne sait pas que l'abonné est actuellement en voyage et ne se désabonne pas réellement, il est juste en vacances. Trois mécanismes « automatisés », aucun d'eux n'est conscient des autres, aucun d'eux n'a une vision cohérente de la place du voyageur dans le cycle de vie du voyage.

Cet article explique à quoi devrait ressembler l'automatisation des push de voyage — une architecture de flux de travail, pas des diffusions de confirmation de réservation avec un déclencheur de réservation abandonnée greffé — et propose cinq modèles de flux de travail en forme de voyage avec des critères de calendrier, de sortie pour le moment du changement de tarif, une gestion en cours de voyage déclenchée par la géolocalisation, et les mathématiques des revenus qui transforment chacun d'eux en un poste budgétaire défendable pour l'équipe ad ops et l'équipe fidélisation.

Pourquoi vos « notifications push automatisées » de voyage font fuir les revenus au moment du changement de tarif

Le mot automatisation a fait le même travail immérité dans le voyage que dans le commerce électronique, le SaaS et l'édition. Lorsque la plupart des équipes CRM de voyage parlent de notifications push automatisées pour le voyage, ce qu'elles entendent par là, c'est la planification de diffusion déclenchée par un événement : une notification se déclenche lorsqu'un événement connu se produit, sans état, sans segmentation, sans délais entre les interactions, sans conditions de sortie et, surtout, sans conscience que l'offre sous-jacente peut ne plus être valide au moment où la deuxième interaction se déclenche.

Un workflow est quelque chose de différent. Un workflow est un parcours en plusieurs étapes avec état. Il sait quand le voyageur a abandonné la réservation, quel tarif il a vu, quel tarif est actuellement cité pour cet itinéraire, quel est son statut de voyage et quelles conditions annulent le parcours. Le workflow d'abandon de réservation ne se contente pas de déclencher un rappel push 24 heures plus tard. Il vérifie si le tarif est toujours valide avant chaque interaction, sort du workflow au moment où la réservation est terminée, et sort séparément si le tarif change – car envoyer « terminez votre réservation de 399 $ » à un voyageur alors que le tarif est maintenant de 529 $ détruit la confiance d'une manière qu'aucune réservation récupérée ne justifie jamais.

Cette dernière clause fait la différence. Les déclencheurs d'événements n'ont aucune mémoire de l'état externe. Les workflows en ont. Si votre automatisation d'abandon de réservation continue de recontacter les voyageurs avec l'ancien tarif après que celui-ci ait changé, vous n'avez pas d'automatisation. Vous avez un déclencheur à qui personne n'a dit de vérifier.

Pour une équipe CRM de voyage du marché intermédiaire, cette distinction fait la différence entre une LTV de réservations répétées qui se compose et une qui est érodée par des erreurs destructrices de confiance au moment du changement de tarif. Trois déclencheurs fonctionnant en parallèle produisent trois canaux de friction. Cinq workflows fonctionnant en coordination produisent un parcours par voyageur par étape de voyage, ramifié et limité par l'état de la réservation, la validité du tarif et le statut du voyage. Les résultats de recherche de la page 1 pour ce mot-clé présentent le problème comme « 5 cas d'utilisation du voyage » et répondent avec une liste d'outils. Ce n'est pas la question que votre examen de rétention du mardi pose.

L'anatomie d'un flux de travail de notification push de voyage

Avant les plans, le vocabulaire. Un workflow de notification push de voyage est construit à partir de six types de nœuds. Une fois que vous savez ce que fait chacun, chaque plan se lit comme un diagramme, pas une description.

DÉMARRAGE. Le point d'entrée. Un nœud DÉMARRAGE définit comment le workflow est déclenché, soit par un événement d'abonné (booking_initiated, booking_abandoned, fare_changed, geolocation_changed, trip_completed) soit par un filtre d'audience (lifecycle_stage, loyalty_tier, last_active). Un workflow a exactement un DÉMARRAGE.

ATTENTE. Un délai. Un nœud ATTENTE retient l'abonné pendant une durée spécifiée (minutes pour la réactivité en cours de voyage, heures pour le rythme des réservations abandonnées, jours pour la cadence avant le voyage) ou jusqu'à une heure spécifique du calendrier en utilisant la sémantique wait_until liée à un attribut de l'abonné — departure_date - 7 jours, departure_date - 1 jour, trip_completion_date + 1 an. Les attentes permettent à un workflow de respecter un événement futur connu, pas seulement un événement passé connu.

DÉCISION. Une branche à deux voies. Un nœud DÉCISION vérifie une condition par abonné : la réservation est-elle terminée, le tarif est-il toujours valide (lu à partir d'un attribut d'abonné mis à jour par le système de réservation), le niveau de fidélité est-il supérieur à argent, le voyageur est-il actuellement en voyage. Les nœuds DÉCISION évaluent les filtres d'événements et les filtres d'audience ; ils ne consomment pas directement les corps de réponse HttpRequest. Le modèle qui apporte un état externe à un workflow est l'action HttpRequest qui déclenche le système externe, le système externe écrit dans un attribut d'abonné via l'API REST PushEngage, et la DÉCISION lit l'attribut.

SPLIT_PATH. Une bifurcation basée sur un pourcentage. Les nœuds SPLIT_PATH acheminent les abonnés sur différents chemins en fonction de pourcentages configurés : 50/50 pour un test A/B sur les montants des remises pour réservations abandonnées, 33/33/34 pour un test d'heure d'envoi à trois voies sur les rappels avant le voyage. Une fois que vous avez un gagnant, vous promouvez ce chemin à 100 %.

ACTION. Le travail lui-même. Les nœuds ACTION envoient une notification push, ajoutent l'abonné à un segment, mettent à jour des attributs personnalisés, déclenchent une HttpRequest vers un système de réservation ou une passerelle SMS, démarrent un autre workflow ou en arrêtent un. PushEngage Workflows prend en charge onze types d'actions. Les plus utiles pour le voyage sont SendPushNotification, UpdateAttribute, HttpRequest et Workflow.Start (pour enchaîner avant le voyage, pendant le voyage et après le voyage).

FIN / SORTIE. Le terminal. FIN marque la conclusion naturelle. SORTIE marque une terminaison anticipée — sur le chemin NON d'une Décision lorsque le voyageur n'est plus éligible, lorsque la règle de refroidissement s'active, ou lorsque l'objectif est atteint (réservation terminée, voyage annulé, tarif invalidé).

Chaque blueprint ci-dessous est composé de ces six éléments.

Cinq modèles de flux de travail pour les voyages

Ce ne sont pas des modèles. Ce sont des plans de travail. Chacun liste son déclencheur, son type d'exécution, sa séquence de nœuds, ses critères de sortie et la métrique de rétention de voyage qu'il est conçu pour améliorer. Vous pouvez importer chacun d'eux dans le constructeur PushEngage Workflows et expédier la première version en moins d'une heure. Le guide des notifications push pour le voyage existant couvre les cas d'utilisation plus larges que ces plans implémentent.

Modèle 1 — Bienvenue + parcours de première réservation

• Déclencheur (DÉMARRAGE) : Événement PushEngage.Subscriber.Added OU browse_destination_page_view
• Type d'exécution : Unique (un parcours de bienvenue par voyageur par fenêtre de 90 jours)
• Flux : Notification de bienvenue avec destinations-les-plus-populaires → ATTENDRE 1 jour → notification de préférence de destination demandant quels types de voyage comptent (plage, ski, city break, affaires) → ATTENDRE 2 jours → DÉCISION : le subscriber a-t-il initié une réservation ? → chemin OUI : enchaîner vers le Blueprint 2 s'il abandonne, sinon laisser le flux pré-voyage prendre le relais après réservation_effectuée → chemin NON : envoyer une notification de recommandation de trois destinations, ajouter au segment active_browsers, FIN
• Critères de sortie : Objectif réservation_effectuée
• Métrique de voyage : Taux de conversion navigation-vers-première-réservation à 7 jours.

Modèle 2 — Réservation abandonnée avec sortie de changement de tarif (automatisation des notifications push d'abandon de réservation)

• Déclencheur (DÉMARRAGE) : Événement personnalisé réservation_abandonnée avec payload itinerary_id
• Type d'exécution : Plusieurs parallèles (chaque réservation abandonnée est sa propre instance de flux)
• Flux : ATTENDRE 1 heure → ACTION : HttpRequest GET vers le point de terminaison de vérification des tarifs de votre système de réservation pour l'itinerary_id. Le système de réservation écrit dans un attribut du subscriber via l'API REST PushEngage — fare_status = valid ou fare_status = invalidated — en quelques secondes → DÉCISION : filtre d'audience fare_status = valid ? → chemin NON : envoyer une notification « votre tarif a changé, voici des options similaires au nouveau prix » et SORTIR (réacheminement gracieux, aucune violation de confiance) → chemin OUI : notification de rappel avec le tarif d'origine → ATTENDRE 24 heures → répéter la vérification des tarifs HttpRequest, puis DÉCISION sur fare_status = valid ET filtre d'audience réservation_effectuée = false → chemin OUI : rappel #2 avec un code promo de 10% → ATTENDRE 48 heures → dernier rappel avec une offre plus forte → FIN
• Critères de sortie : Objectif réservation_effectuée correspondant à l'itinerary_id du déclencheur OU filtre d'audience fare_status = invalidated
• Métrique de voyage : Valeur de réservation récupérée par réservation abandonnée. C'est le flux avec la ligne de revenus la plus défendable sur la page. L'article 6 astuces pour réduire l'abandon de réservation couvre la version tactique manuelle de ce blueprint ; la version flux ajoute la sortie de validité du tarif qui transforme une récupération tactique en une récupération qui préserve la confiance de la marque.

Modèle 3 — Parcours avant le voyage (calcul de la date de départ)

Ceci est le flux de notification push pré-voyage qui démontre la sémantique wait_until liée à un attribut du subscriber.

• Déclencheur (DÉMARRAGE) : Événement personnalisé réservation_effectuée (qui écrit departure_date dans un attribut du subscriber)
• Type d'exécution : Unique par réservation
• Flux : ATTENDRE jusqu’à date_de_départ - 14 jours → notification push « votre voyage est dans deux semaines » avec recommandations d’emballage et prévisions météo → ATTENDRE jusqu’à date_de_départ - 7 jours → notification push de revenus auxiliaires (surclassement de siège, surclassement de chambre, ajout de location de voiture, transfert aéroportuaire) → ATTENDRE jusqu’à date_de_départ - 1 jour → notification push de rappel d’enregistrement avec lien vers la carte d’embarquement mobile → ATTENDRE jusqu’à date_de_départ → notification push « bon voyage », FIN
• Critères de sortie : Objectif réservation_annulée
• Métrique de voyage : Revenu auxiliaire par réservation. Le contact 7 jours avant est le moment le plus influent pour les auxiliaires.

Modèle 4 — Géolocalisation en cours de voyage (automatisation des notifications push par géolocalisation)

• Déclencheur (DÉBUT) : Événement personnalisé géolocalisation_modifiée (déclenché par votre application mobile lorsque l’appareil signale une nouvelle lat/lng) ET filtre d’audience voyage_en_cours = vrai
• Type d’exécution : Plusieurs parallèles
• Flux : DÉCISION : le voyageur est-il arrivé dans la ville de destination (le filtre d’audience compare les coordonnées de géolocalisation à un géofence de destination stocké comme attribut d’abonné) ? → chemin OUI : ACTION envoyer une notification push de recommandations locales (hôtels, restaurants, activités locales liées à la destination), ACTION HttpRequest vers l’API météo → si une alerte météo est justifiée, ACTION envoyer une notification météo → FIN → chemin NON : SORTIE (le voyageur est en transit, pas à destination)
• Heures de tranquillité : sensible au fuseau horaire de l’abonné. Workflows.md §9.4 résout les heures de tranquillité d’abord par fuseau horaire de l’abonné, puis par fuseau horaire du site, puis par UTC. Pour les flux en cours de voyage, cela signifie que le fuseau horaire respecte l’heure locale de la destination, et non le marché d’origine de la marque. Les notifications push non critiques utilisent skip ; les alertes de sécurité et météo utilisent reschedule pour garantir la livraison
• Critères de sortie : Objectif voyage_terminé
• Métrique de voyage : Taux d’engagement en cours de voyage et revenus auxiliaires en cours de voyage. Remarque : géolocalisation_modifiée n’est pas un type de déclencheur intégré — il s’agit d’un PushEngage.CustomEvent que votre application mobile déclenche lorsque la localisation de l’appareil est mise à jour, et la vérification à destination est un filtre d’audience sur les attributs d’abonné que l’application maintient. Les notifications push de géolocalisation couvrent la base de segmentation que ce blueprint étend.

Modèle 5 — Bilan post-voyage + nouvelle réservation similaire

• Déclencheur (DÉBUT) : Événement personnalisé voyage_terminé
• Type d’exécution : Plusieurs séquentielles
• Flux : ATTENDRE 3 jours → notification push de demande d’avis faisant référence à la destination par son nom → ATTENDRE jusqu’à date_de_fin_de_voyage + 365 jours (un an plus tard) → notification push « prêt pour votre prochain voyage ? » avec une offre similaire à la destination basée sur le type de voyage précédent → ATTENDRE 7 jours → DÉCISION : le voyageur a-t-il initié une réservation ? → chemin OUI : enchaîner vers le Blueprint 1 ou 2 → chemin NON : SORTIE
• Critères de sortie : Nouvel événement réservation_initiée OU désinscrit
• Métrique de voyage : Taux de réservation répétée à 12 mois. C'est le blueprint le plus ancien — environ 13 mois — et celui qui a le plus fort impact sur la LTV. Le schéma de similarité d'une année sur l'autre est l'analogue de voyage du « win-back » post-achat de l'e-commerce, adapté à la cadence saisonnière que les acheteurs de voyages suivent réellement.

Segmentation par étape du cycle de vie, tests A/B, heures de silence par fuseau horaire de destination, et critères de sortie intégrés au flux de travail

Le schéma dominant dans les articles de push voyage consiste à énumérer ces quatre concepts comme des « meilleures pratiques » — des puces génériques à la fin d'un article de stratégie, dissociées des campagnes qui les utilisent. C'est le mauvais cadre. Ce ne sont pas des meilleures pratiques qui se situent à côté du flux de travail. C'est le flux de travail.

Concept	Cadrage des meilleures pratiques (incorrect)	Cadrage des nœuds de flux (correct)
Segmentation par étape du cycle de vie	« Segmenter les voyageurs par étape de voyage »	Un nœud DECISION sur l'attribut d'abonné lifecycle_stage (navigation / réservation initiée / pré-voyage / en-voyage / post-voyage / inactif) qui redirige les voyageurs pré-voyage vers des incitations accessoires, les voyageurs en-voyage vers des flux de travail géolocalisés, et les voyageurs post-voyage vers des avis et des suggestions de nouvelle réservation similaires.
Tests A/B	« Toujours tester par A/B votre contenu de réservation abandonnée »	Un nœud SPLIT_PATH avec une allocation 50/50, des abonnés répartis uniformément par chemin, et un champ winner_edge_id qui promeut le gagnant à 100 % une fois que le test atteint une signification — la plupart des tests A/B de voyage portent sur le montant de la remise dans le rappel n°2.
Heures de silence par fuseau horaire de destination	« Ne pas envoyer de notifications à 3 heures du matin »	Une option au niveau du flux de travail avec timezone: subscriber et un paramètre fallback qui skip l'envoi (notifications non critiques) ou le reschedule une minute après la fin des heures de silence (sécurité, météo, changement de porte) — essentiel pour les flux de travail en cours de voyage où le fuseau horaire local de l'abonné est la destination, et non le marché d'origine de la marque.
Critères de sortie	« Arrêter la séquence de réservation abandonnée une fois qu'ils réservent »	Une règle au niveau du flux de travail qui vérifie le voyageur par rapport à l'objectif booking_completed ET à l'attribut fare_status = invalidated avant chaque nœud, et annule le flux de travail si l'une ou l'autre condition est remplie — la deuxième condition est ce qu'aucun résultat SERP ne décrit.

La différence est importante car les puces de meilleures pratiques sont faciles à approuver et difficiles à appliquer. Les nœuds de flux de travail sont appliqués par le moteur. Le DECISION s'exécute à chaque fois. Le SPLIT_PATH répartit chaque voyageur. Le mécanisme de repli des heures de silence s'active sans que personne ne pense à vérifier le fuseau horaire de destination. La règle de sortie annule le flux de travail de réservation abandonnée, que le responsable de la campagne y prête attention ou non.

Pour le flux de réservation abandonnée du Blueprint 2, cela signifie qu'au moment où un voyageur réserve — à la première, 30ème ou 73ème heure du flux de travail — la règle de sortie se déclenche, le flux de travail est annulé pour ce voyageur, et plus aucune notification « complétez votre réservation » n'est envoyée à quelqu'un qui a déjà payé la veille. Séparément, au moment où le tarif change et que le système de réservation met à jour fare_status = invalidated, le flux de travail se termine gracieusement et envoie la notification de récupération « tarif modifié, voici des options similaires ». Aucune violation de confiance. Pas d'appel furieux au service client.

Orchestration multicanal : push web, push application, SMS, WhatsApp, e-mail

Les marques de voyage gèrent plus de canaux que les équipes eCommerce, SaaS ou éditeurs. Web push pour le flux de réservation sur ordinateur. App push pour les voyageurs qui ont téléchargé l'application de la marque. SMS comme canal résilient à l'itinérance des données pour les alertes critiques pendant le voyage (changement de porte, retard de vol, météo). WhatsApp pour le service client à forte valeur ajoutée et les voyageurs internationaux dans les régions où WhatsApp est le messager par défaut. Email comme conteneur d'itinéraire détaillé avant le voyage. La composition des cinq à l'intérieur d'un seul flux de travail — en choisissant le canal qui correspond à l'état de l'abonné — est ce qui fait la différence entre une équipe CRM qui offre un parcours cohérent et une autre qui doit s'excuser pour une notification à 3h du matin «votre vol est à l'heure» qui a réveillé un voyageur dans un fuseau horaire de destination.

Un parcours de changement de porte composé pendant le voyage se lit comme suit :

• DÉBUT : Événement personnalisé gate_change pour un itinéraire où trip_in_progress = true
• DÉCISION : le voyageur est-il actuellement sur l'application mobile de la marque ?
  • OUI : ACTION envoyer une notification push via l'application (friction la plus faible, livraison tenant compte de l'itinérance des données)
  • NON : continuer
• DÉCISION : le voyageur est-il en itinérance internationale (filtre d'audience sur country différent de home_country) ?
  • OUI : ACTION envoyer un SMS via HttpRequest à Twilio ou Plivo (le SMS utilise la voix cellulaire, pas les données — résilient lorsque les données d'itinérance sont limitées)
  • NON : ACTION envoyer une notification push web (le voyageur peut être sur le Wi-Fi de l'hôtel)
• ACTION : HttpRequest vers l'ESP pour mettre à jour le prochain récapitulatif d'itinéraire par e-mail
• FIN sur gate_acknowledged ou flight_boarded

Une identité de voyageur, un flux de travail, quatre canaux choisis par état. Le canal viable le moins cher passe en premier. Le SMS — le plus cher par envoi — n'est envoyé que lorsque le voyageur est en itinérance internationale et que le message est critique en termes de temps. Booking.com a présenté la messagerie mobile comme une « interaction client en temps réel » plutôt que comme du marketing de diffusion ; ce flux de travail composé est la même philosophie exprimée comme une architecture de flux de travail.

Exécuter ceci avec des outils séparés signifie cinq connexions à des fournisseurs, deux moteurs de segmentation qui ne sont pas d'accord sur qui est actuellement en voyage, et aucune attribution unique des revenus par voyageur et par canal. Le faire à l'intérieur d'un seul moteur de flux de travail signifie une identité de voyageur, un ensemble de logique de décision et un rapport d'entonnoir qui montre où le parcours se brise réellement. L'action HttpRequest (Workflows.md §5.7) est ce qui rend l'orchestration inter-canaux possible — elle relie le moteur de flux de travail à la passerelle SMS, à l'ESP et au système de réservation sans nécessiter d'outil d'orchestration séparé.

Les mathématiques de la rétention : augmentation de la conversion des réservations et LTV des réservations répétées aux tailles de billets de voyage

La monétisation du voyage est à haute valeur. Les valeurs de réservation vont des vols court-courriers à 300 $ aux forfaits vacances à plus de 5 000 $, ce qui modifie le calcul des coûts par rapport à l'e-commerce (paniers de 50 à 200 $) et au SaaS (99 à 999 $ par an). PushEngage Workflows suit les trois mêmes chiffres à chaque nœud — en attente, terminé, sorti — et le même schéma d'analyse au niveau du nœud s'applique. Les revenus par réservation récupérée éclipsent les revenus par panier récupéré, ce qui rend la contribution du workflow au compte de résultat plus facile à défendre.

Voici à quoi ressemblent les analyses au niveau du nœud pour un workflow actif d'abandon de réservation dans une OTA de marché intermédiaire avec 5 000 abandons de réservation par mois pour un prix moyen de 1 200 $ (chiffres illustratifs) :

Nœud	En file d'attente	Terminé	Sorti	Notes
DÉMARRER (réservation_abandonnée)	0	5,000	0	Tous les itinéraires abandonnés entrent
ATTENDRE 1 heure	92	4,900	8	8 réservés dans la première heure sans intervention
ACTION : HttpRequest vérification_tarif	0	4,900	0	Le système de réservation met à jour l'attribut statut_tarif
DÉCISION : statut_tarif valide	0	4,410	490	490 itinéraires invalidés pour cause de tarif avant la première intervention — sortie gracieuse via une notification push « tarif modifié »
ACTION : rappel n°1 (tarif d'origine)	0	4,410	0	Premier rappel envoyé
ATTENDRE 24 heures	134	3,950	326	326 réservés après le rappel n°1
Deuxième vérification de tarif + DÉCISION	0	3,720	230	230 autres itinéraires invalidés pour cause de tarif — sortie gracieuse
ACTION : rappel n°2 + promotion de 10 %	0	3,720	0	Deuxième rappel
ATTENDRE 48 heures	78	3,200	442	442 autres réservés après le rappel n°2
ACTION : dernier rappel + offre plus avantageuse	0	3,200	0	Dernière notification
FIN	N/A	3,200	N/A	3 200 n'ont pas réservé

Dans cette cohorte, 776 itinéraires abandonnés ont été convertis en réservations pendant le workflow — un taux de récupération de 15,5 %. À 1 200 $ de valeur de réservation moyenne, cela représente 931 200 $ de revenus récupérés par mois, soit 11,2 M$ annualisés. Les sorties pour changement de tarif ont permis d'éviter que 720 relations voyageurs supplémentaires ne reçoivent une notification trompeuse « terminez votre réservation de 399 $ » alors que le tarif avait déjà augmenté — 720 tickets de service client et violations de la confiance de la marque que le workflow a évités, indépendamment de l'augmentation des conversions de réservation.

Le calcul des coûts est différent pour le voyage. Les notifications push web et app sont gratuites par envoi après consentement. Les SMS via Twilio coûtent environ 0,0079 $ par message national aux États-Unis et 0,05 à 0,30 $ par message international — pour 5 000 cohortes d'abandons de réservation par mois avec une part de 10 % de SMS pendant le voyage, cela représente 40 à 150 $ par cohorte en dépenses SMS. La tarification de WhatsApp Business Platform est basée sur les sessions. Les e-mails évoluent avec le contrat ESP. Le rôle du workflow est d'utiliser d'abord le canal le moins cher viable et de passer au SMS ou à WhatsApp uniquement lorsque l'état l'exige. La ligne « workflow d'abandon de réservation a récupéré 931K $ de réservations mensuelles pour un coût de canal tout compris de 1 500 $ » est le type de compte de résultat qui permet de gagner la conversation budgétaire de l'année prochaine.

Créez-le dans les flux de travail PushEngage pour votre marque de voyage

Chacun des cinq modèles de voyage correspond directement aux composants de PushEngage Workflows. La correspondance :

Modèle	Types de nœuds utilisés	Types d'actions utilisés	Option de workflow
Bienvenue + suivi de la première réservation	DÉMARRER, ATTENDRE, DÉCISION, ACTION, TERMINER	SendPushNotification, AddSegment	Type d'exécution : Unique
Abandon de réservation avec sortie pour changement de tarif	DÉMARRER, ATTENDRE, ACTION, DÉCISION, TERMINER	SendPushNotification, HttpRequest, UpdateAttribute	Type d'exécution : Plusieurs parallèles ; sortie à l'objectif booking_completed OU filtre d'audience fare_status=invalidated
Suivi pré-voyage (calcul de la date de départ)	DÉMARRER, ATTENDRE (wait_until), ACTION, TERMINER	SendPushNotification	Type d'exécution : Unique par réservation ; wait_until lié à l'attribut departure_date
Géolocalisation en cours de voyage	DÉMARRER, DÉCISION, ACTION, FIN	SendPushNotification, HttpRequest, UpdateAttribute	Type d'exécution : Plusieurs parallèles ; déclencheur d'événement personnalisé + filtre d'audience
Examen post-voyage + nouvelle réservation similaire	DÉMARRER, ATTENDRE, ACTION, ATTENDRE (wait_until), ACTION, DÉCISION, FIN	SendPushNotification	Type d'exécution : Séquentiel multiple

Le moteur Workflows est livré avec plus de 60 modèles préconfigurés qui couvrent les éléments constitutifs de chaque plan. La plupart des modèles sont conçus pour le e-commerce, mais l'adaptation au voyage est simple : la logique du modèle d'abandon de panier devient un flux de travail de réservation abandonnée en remplaçant l'événement de déclenchement par booking_abandoned, en ajoutant le modèle de vérification de tarif HttpRequest-and-attribute-update du Blueprint 2, et en utilisant un critère de sortie d'invalidation de tarif aux côtés de booking_completed. Le modèle de bienvenue correspond directement au Blueprint 1. Le modèle de diffusion de géolocalisation — déjà dans le catalogue — est la base du flux de travail en cours de voyage du Blueprint 4.

Pour le contexte plus large de la promotion de voyages — cas d'utilisation spécifiques à une niche (hôtels, vols, locations de vacances) et stratégies de saisonnalité — le guide des notifications push pour les sites de voyage existant catalogue les types de campagnes que ces plans mettent en œuvre.

Pour le parcours d'essai immédiat, le plan gratuit vous donne 200 abonnés, tous les canaux (web push, app push, WhatsApp, chat en direct) et le moteur Workflows complet dès le premier jour. C'est suffisant pour déployer les Blueprints 1 et 2 sur votre prochaine cohorte d'itinéraires abandonnés et capturer les analyses au niveau des nœuds avant le prochain QBR. Pour le positionnement de PushEngage dans le secteur du voyage — tarification, intégrations, exemples clients — PushEngage pour le voyage est la page de destination canonique.

Ce que cela change

Si vous retenez une chose de cet article, retenez ceci : l'automatisation des notifications push pour les voyages est une architecture de flux de travail, pas des diffusions de confirmation de réservation avec un déclencheur de réservation abandonnée ajouté à la hâte. Le parcours de réservation abandonnée qui se termine gracieusement en cas de changement de tarif, le flux de travail pré-voyage qui se déclenche à departure_date - 7 jours, le flux de travail de géolocalisation en cours de voyage qui respecte le fuseau horaire de destination — ils ont tous la même forme. Un DÉMARRAGE, quelques ATTENTES, quelques DÉCISIONS, quelques ACTIONS, une SORTIE. Trois déclencheurs autonomes ne peuvent pas faire cela. Un moteur de flux de travail le peut. La LTV de réservation répétée se compose à partir de là.

Commencez avec le plan gratuit pour déployer le premier blueprint sur votre prochaine cohorte d'itinéraires abandonnés.