Автоматизация push-уведомлений для путешествий: 5 шаблонов рабочих процессов

Сейчас вторник, вторая половина дня, и проверка удержания завершилась в 14:15. Коэффициент конверсии бронирований снизился на 1,4 пункта в прошлом квартале — с 3,6% до 2,2%. Команда лояльности считает, что рассылка писем для восстановления слишком задерживается. Мобильная команда считает, что уведомление о незавершенном бронировании пересекается с оповещениями о снижении цен. Никто не может доказать, что именно это является причиной. Через два часа после совещания в ветке Slack все сходятся во мнении только в одном: панель мониторинга недостаточно детализирована, чтобы разрешить спор.

Автоматизация push-уведомлений для путешествий находится в центре этого спора, и никто в команде удержания не знает, как ее защитить. Автоматическое push-уведомление о подтверждении бронирования отправляется при завершении бронирования. Триггер незавершенного бронирования повторно отправляет уведомление по тому же маршруту через 24 часа — и иногда этот маршрут уже не соответствует цене, которую путешественник оставил, потому что тариф изменился за ночь. Триггер предупреждения об оттоке, который кто-то настроил два года назад, по-прежнему срабатывает, когда количество активных пользователей за день (DAU) падает в приложении, но он не знает, что подписчик в данный момент находится в поездке и на самом деле не уходит, а просто в отпуске. Три «автоматизированных» механизма, ни один из которых не осведомлен о других, ни один из которых не имеет четкого представления о том, на каком этапе жизненного цикла находится путешественник.

В этой статье рассказывается о том, как на самом деле должна выглядеть автоматизация push-уведомлений для путешествий — архитектура рабочего процесса, а не рассылки подтверждений бронирования с добавленным триггером незавершенного бронирования — и предлагаются пять шаблонов рабочих процессов для путешествий с указанием времени, критериев выхода для момента изменения тарифа, обработки в поездке на основе геолокации и математики доходов, которая превращает каждый из них в обоснованный пункт для рекламного отдела и команды лояльности.

Почему ваши «автоматические push-уведомления» для путешествий приводят к утечке доходов в момент изменения тарифа

Слово автоматизация выполняло ту же незаслуженную работу в сфере путешествий, что и в электронной коммерции, SaaS и издательском деле. Когда большинство CRM-команд в сфере путешествий говорят об автоматизированных push-уведомлениях для путешествий, они имеют в виду планирование массовых рассылок по триггеру событий: уведомление срабатывает при известном событии, без состояния, без сегментации, без задержек между касаниями, без условий выхода и — что критически важно — без понимания того, что исходное предложение может быть уже недействительным к моменту второго касания.

Рабочий процесс — это нечто иное. Рабочий процесс — это многошаговое путешествие с состоянием. Он знает, когда путешественник отказался от бронирования, какой тариф он видел, какой тариф сейчас указан в этом маршруте, каков статус его поездки и какие условия отменяют путешествие. Рабочий процесс отказа от бронирования не просто отправляет одно напоминание push через 24 часа. Он проверяет, действителен ли тариф перед каждым касанием, завершает рабочий процесс в тот момент, когда бронирование завершено, и отдельно завершается, если тариф изменился — потому что отправка сообщения «завершите ваше бронирование за 399 долларов» путешественнику, когда тариф теперь составляет 529 долларов, разрушает доверие так, как не оправдывает ни одно восстановленное бронирование.

Последняя часть — это разница. Триггеры событий не имеют памяти о внешнем состоянии. Рабочие процессы — имеют. Если ваша автоматизация отказа от бронирования продолжает повторно отправлять запросы путешественникам по старой цене после того, как цена изменилась, у вас нет автоматизации. У вас есть триггер, которому никто не сказал проверять.

Для команды CRM в сфере путешествий среднего рынка это различие — разница между LTV от повторных бронирований, который растет, и тем, который подрывается ошибками, разрушающими доверие в момент изменения тарифа. Три триггера, работающие параллельно, создают три канала трения. Пять рабочих процессов, работающих скоординированно, создают одно путешествие на путешественника на этапе поездки, разветвленное и ограниченное состоянием бронирования, действительностью тарифа и статусом поездки. Результаты поиска на первой странице по этому ключевому слову представляют проблему как «5 сценариев использования в путешествиях» и отвечают списком инструментов. Это не тот вопрос, который задает ваш обзор удержания во вторник.

Анатомия рабочего процесса push-уведомлений для путешествий

Прежде чем перейти к чертежам, — к словарю. Рабочий процесс push-уведомлений для путешествий строится из шести типов узлов. Как только вы узнаете, что делает каждый из них, каждый чертеж будет читаться как диаграмма, а не описание.

START. Точка входа. Узел START определяет, как запускается рабочий процесс, либо событием подписчика (booking_initiated, booking_abandoned, fare_changed, geolocation_changed, trip_completed), либо фильтром аудитории (lifecycle_stage, loyalty_tier, last_active). Рабочий процесс имеет ровно один START.

WAIT. Задержка. Узел WAIT удерживает подписчика в течение указанного времени (минуты для реагирования во время поездки, часы для отслеживания бронирований, оставленных без завершения, дни для поддержания связи перед поездкой) или до определенного времени в календаре с использованием семантики wait_until, связанной с атрибутом подписчика — departure_date - 7 дней, departure_date - 1 день, trip_completion_date + 1 год. Ожидания — это способ, которым рабочий процесс учитывает известное будущее событие, а не только известное прошлое.

DECISION. Двустороннее разветвление. Узел DECISION проверяет условие для каждого подписчика: завершено ли бронирование, действителен ли тариф (читается из атрибута подписчика, который обновляет система бронирования), находится ли уровень лояльности выше серебряного, находится ли путешественник в данный момент в поездке. Узлы DECISION оценивают фильтры событий и фильтры аудитории; они не обрабатывают тела ответов HttpRequest напрямую. Шаблон, который переносит внешнее состояние в рабочий процесс, заключается в том, что действие HttpRequest запускает внешнюю систему, внешняя система записывает данные обратно в атрибут подписчика через PushEngage REST API, а DECISION считывает атрибут.

SPLIT_PATH. Разветвление на основе процентов. Узлы SPLIT_PATH направляют подписчиков по разным путям на основе настроенных процентов: 50/50 для A/B-тестирования скидок на бронирования, оставленные без завершения, 33/33/34 для трехстороннего тестирования времени отправки напоминаний перед поездкой. Как только у вас появится победитель, вы продвигаете этот путь до 100%.

ACTION. Сама работа. Узлы ACTION отправляют push-уведомление, добавляют подписчика в сегмент, обновляют пользовательские атрибуты, отправляют HttpRequest в систему бронирования или SMS-шлюз, запускают другой рабочий процесс или останавливают его. PushEngage Workflows поддерживает одиннадцать типов действий. Наиболее полезными для путешествий являются SendPushNotification, UpdateAttribute, HttpRequest и Workflow.Start (для последовательного соединения этапов перед поездкой, во время поездки и после поездки).

END / EXIT. Терминал. END отмечает естественное завершение. EXIT отмечает досрочное прекращение — по пути НЕТ в Decision, когда путешественник больше не соответствует требованиям, когда срабатывает правило охлаждения или когда цель достигнута (бронирование завершено, поездка отменена, тариф недействителен).

Каждый приведенный ниже шаблон состоит из этих шести частей.

Пять шаблонов рабочих процессов для путешествий

Это не шаблоны. Это рабочие чертежи. Каждый из них перечисляет свой триггер, тип выполнения, последовательность узлов, критерии выхода и метрику удержания путешественников, которую он призван улучшить. Вы можете загрузить каждый из них в конструктор PushEngage Workflows и выпустить первую версию менее чем за час. В устаревшем руководстве по push-уведомлениям для путешественников рассматриваются более широкие варианты использования, которые реализуют эти чертежи.

Шаблон 1 — Приветствие + развитие первого бронирования

• Триггер (START): Событие PushEngage.Subscriber.Added ИЛИ browse_destination_page_view
• Тип выполнения: Одиночный (одно приветственное путешествие на путешественника в течение 90-дневного окна)
• Поток: Приветственное push-уведомление с самыми популярными направлениями → ПОДОЖДИТЕ 1 день → push-уведомление о предпочтениях в поездках с вопросом, какие типы поездок важны (пляж, лыжи, городской отдых, деловая поездка) → ПОДОЖДИТЕ 2 дня → РЕШЕНИЕ: инициировал ли подписчик бронирование? → Путь ДА: перейдите к Blueprint 2, если они откажутся, в противном случае позвольте рабочему процессу перед поездкой вступить в силу после booking_completed → Путь НЕТ: отправьте тщательно подобранное push-уведомление с рекомендацией трех направлений, добавьте в сегмент active_browsers, ЗАВЕРШИТЬ
• Критерии выхода: Цель booking_completed
• Метрика путешествий: Коэффициент конверсии от просмотра до первого бронирования на 7-й день.

Шаблон 2 — Незавершенное бронирование с выходом при изменении тарифа (автоматизация push-уведомлений о незавершенном бронировании)

• Триггер (СТАРТ): Пользовательское событие booking_abandoned с полезной нагрузкой itinerary_id
• Тип выполнения: Несколько параллельных (каждое отмененное бронирование — это отдельный экземпляр рабочего процесса)
• Поток: ПОДОЖДИТЕ 1 час → ДЕЙСТВИЕ: HttpRequest GET к конечной точке проверки тарифов вашей системы бронирования для itinerary_id. Система бронирования записывает ответ в атрибут подписчика через PushEngage REST API — fare_status = valid или fare_status = invalidated — в течение нескольких секунд → РЕШЕНИЕ: фильтр аудитории fare_status = valid? → Путь НЕТ: отправьте push-уведомление «ваш тариф изменился, вот похожие варианты по новой цене» и ЗАВЕРШИТЕ (корректное перенаправление, без нарушения доверия) → Путь ДА: напоминание с первоначальным тарифом → ПОДОЖДИТЕ 24 часа → повторите проверку тарифа HttpRequest, затем РЕШЕНИЕ по fare_status = valid И фильтр аудитории booking_completed = false → Путь ДА: напоминание № 2 с промокодом 10% → ПОДОЖДИТЕ 48 часов → финальное напоминание с более выгодным предложением → ЗАВЕРШИТЬ
• Критерии выхода: Цель booking_completed, соответствующая itinerary_id из триггера, ИЛИ фильтр аудитории fare_status = invalidated
• Метрика путешествий: Восстановленная стоимость бронирования на одно отмененное бронирование. Это рабочий процесс с наиболее обоснованной строкой дохода на странице. В посте 6 советов по снижению количества отказов от бронирования рассматривается ручная версия этой схемы; версия рабочего процесса добавляет выходные данные о действительности тарифа, которые превращают тактическое восстановление в сохраняющее доверие к бренду.

Шаблон 3 — Развитие перед поездкой (расчет даты отправления)

Это рабочий процесс push-уведомлений перед поездкой, демонстрирующий семантику wait_until, привязанную к атрибуту подписчика.

• Триггер (СТАРТ): Пользовательское событие booking_completed (которое записывает departure_date в атрибут подписчика)
• Тип выполнения: Один на бронирование
• Поток: WAIT до departure_date - 14 дней → push «ваша поездка через две недели» с рекомендациями по упаковке и прогнозом погоды → WAIT до departure_date - 7 дней → push с дополнительным доходом (повышение класса места, повышение класса номера, дополнительная аренда автомобиля, трансфер из аэропорта) → WAIT до departure_date - 1 день → push-напоминание о регистрации с ссылкой на мобильный посадочный талон → WAIT до departure_date → push «счастливого пути», END
• Критерии выхода: Goal booking_cancelled
• Метрика путешествия: Дополнительный доход на бронирование. Касание за 7 дней до поездки — это момент с наибольшим влиянием на дополнительные доходы.

Шаблон 4 — Геолокация в поездке (автоматизация push-уведомлений по геолокации)

• Триггер (СТАРТ): Пользовательское событие geolocation_changed (запускается вашим мобильным приложением, когда устройство сообщает новые координаты широты/долготы) И фильтр аудитории trip_in_progress = true
• Тип запуска: Несколько параллельных
• Поток: РЕШЕНИЕ: прибыл ли путешественник в город назначения (фильтр аудитории сравнивает координаты геолокации с геозоной назначения, хранящейся как атрибут подписчика)? → Путь ДА: ACTION отправить push с местными рекомендациями (отели, рестораны, местные мероприятия, связанные с местом назначения), ACTION HttpRequest к API погоды → если требуется оповещение о погоде, ACTION отправить уведомление о погоде → END → Путь НЕТ: EXIT (путешественник в пути, не в пункте назначения)
• Тихие часы: с учетом часового пояса подписчика. Workflows.md §9.4 разрешает тихие часы сначала по часовому поясу подписчика, затем по часовому поясу сайта, затем по UTC. Для рабочих процессов во время поездки это означает, что часовой пояс учитывает местное время назначения, а не домашний рынок бренда. Некритические push-уведомления используют skip; оповещения о безопасности и погоде используют reschedule для обеспечения доставки
• Критерии выхода: Goal trip_completed
• Метрика путешествия: Вовлеченность во время поездки и дополнительный доход во время поездки. Примечание: geolocation_changed не является встроенным типом триггера — это PushEngage.CustomEvent, которое ваше мобильное приложение запускает при обновлении местоположения устройства, а проверка прибытия в пункт назначения — это фильтр аудитории по атрибутам подписчика, которые поддерживает приложение. Статья push-уведомления о геолокации охватывает основу сегментации, которую расширяет этот шаблон.

Шаблон 5 — Обзор после поездки + повторное бронирование по схожим профилям

• Триггер (СТАРТ): Пользовательское событие trip_completed
• Тип запуска: Несколько последовательных
• Поток: WAIT 3 дня → push с запросом отзыва, ссылающийся на место назначения по имени → WAIT до trip_completion_date + 365 дней (год спустя) → push «готовы к следующей поездке?» с предложением, похожим на место назначения, основанным на предыдущем типе поездки → WAIT 7 дней → РЕШЕНИЕ: инициировал ли путешественник бронирование? → Путь ДА: цепочка в Blueprint 1 или 2 → Путь НЕТ: EXIT
• Критерии выхода: Новое событие booking_initiated ИЛИ unsubscribed
• Метрика путешествий: Коэффициент повторного бронирования за 12 месяцев. Это самый долгосрочный шаблон — около 13 месяцев — и тот, который оказывает наибольшее влияние на LTV. Шаблон сравнения год к году является аналогом в сфере путешествий для возврата клиентов после покупки в электронной коммерции, адаптированный к сезонному ритму, которому действительно следуют покупатели туристических услуг.

Сегментация по этапам жизненного цикла, A/B-тестирование, тихие часы по часовому поясу назначения и критерии выхода встроены в рабочий процесс

Доминирующий шаблон в статьях о push-уведомлениях для путешествий заключается в перечислении этих четырех концепций как «лучших практик» — общих пунктов в конце стратегического поста, оторванных от кампаний, которые их используют. Это неправильный подход. Это не лучшие практики, которые находятся рядом с рабочим процессом. Это и есть рабочий процесс.

Концепция	Формулировка лучших практик (неправильно)	Формулировка узлов рабочего процесса (правильно)
Сегментация по этапам жизненного цикла	«Сегментируйте путешественников по этапу поездки»	Узел РЕШЕНИЕ (DECISION) по атрибуту подписчика lifecycle_stage (просмотр / начало бронирования / до поездки / в поездке / после поездки / потерянный), который направляет путешественников до поездки к дополнительным напоминаниям, путешественников в поездке к рабочим процессам геолокации, путешественников после поездки к отзывам и повторному бронированию по схожим профилям.
A/B тестирование	«Всегда проводите A/B-тестирование текстов для бронирований, которые были брошены»	Узел РАЗДЕЛЕНИЕ_ПУТИ (SPLIT_PATH) с распределением 50/50, сбалансированной нагрузкой подписчиков на каждый путь и полем winner_edge_id, которое продвигает победителя до 100%, как только тест достигнет значимости — большинство A/B-тестов в сфере путешествий проводятся по размеру скидки во втором напоминании.
Тихие часы по часовому поясу назначения	«Не отправляйте уведомления в 3 часа ночи»	Параметр на уровне рабочего процесса с timezone: subscriber и настройкой fallback, которая либо skip (пропускает) отправку (некритические push-уведомления), либо reschedule (переносит) ее на одну минуту после окончания тихих часов (безопасность, погода, изменение выхода на посадку) — критически важно для рабочих процессов в поездке, где местный часовой пояс подписчика является часовым поясом назначения, а не домашнего рынка бренда.
Критерии выхода	«Остановите последовательность бронирований, которые были брошены, как только они забронируют»	Правило на уровне рабочего процесса, которое проверяет путешественника на соответствие цели booking_completed И атрибуту fare_status = invalidated перед каждым узлом и отменяет рабочий процесс, если любое из условий совпадает — второе условие — это то, что не описывает ни один результат SERP.

Разница имеет значение, потому что лучшие практики легко одобрить кивком, но трудно применить. Узлы рабочего процесса применяются движком. РЕШЕНИЕ выполняется каждый раз. РАЗДЕЛЕНИЕ_ПУТИ балансирует каждого путешественника. Отсрочка тихих часов срабатывает без необходимости кому-либо помнить о проверке часового пояса назначения. Правило выхода отменяет рабочий процесс бронирования, которое было брошено, независимо от того, обращает ли владелец кампании на это внимание.

Для потока бронирований, которые были брошены, в Шаблоне 2, в тот момент, когда путешественник бронирует — в первый час, через 30 часов или через 73 часа рабочего процесса — срабатывает правило выхода, рабочий процесс отменяется для этого путешественника, и больше никаких push-уведомлений «завершите бронирование» не отправляется тому, кто уже заплатил вчера. Отдельно, в тот момент, когда меняется тариф и система бронирования обновляет fare_status = invalidated, рабочий процесс корректно завершается и отправляет восстановительное push-уведомление «тариф изменился, вот похожие варианты». Никакого нарушения доверия. Никаких гневных звонков в службу поддержки.

Многоканальная оркестровка: веб-push, push в приложении, SMS, WhatsApp, email

Туристические бренды используют больше каналов, чем команды, работающие с eCommerce, SaaS или издательским контентом. Веб-пуши для процесса бронирования на десктопе. Push-уведомления в приложении для путешественников, загрузивших приложение бренда. SMS как устойчивый к роумингу канал для критических уведомлений во время поездки (смена выхода на посадку, задержка рейса, погода). WhatsApp для высокоуровневого обслуживания клиентов и международных путешественников в регионах, где WhatsApp является мессенджером по умолчанию. Email как контейнер для подробного маршрута перед поездкой. Составление всех пяти сообщений в рамках одного рабочего процесса — выбор канала, соответствующего состоянию подписчика — вот что отличает команду CRM, обеспечивающую целостное путешествие, от той, которой приходится извиняться за push-уведомление в 3 часа ночи «ваш рейс вовремя», разбудившее путешественника в другом часовом поясе.

Путешествие с уведомлением о смене выхода на посадку во время поездки выглядит так:

• НАЧАЛО: Пользовательское событие gate_change для маршрута, где trip_in_progress = true
• РЕШЕНИЕ: находится ли путешественник в данный момент в мобильном приложении бренда?
  • ДА: ДЕЙСТВИЕ отправить push-уведомление в приложение (минимальное взаимодействие, доставка с учетом роуминга)
  • НЕТ: продолжить
• РЕШЕНИЕ: находится ли путешественник в международном роуминге (фильтр аудитории по country не равно home_country)?
  • ДА: ДЕЙСТВИЕ отправить SMS через HttpRequest в Twilio или Plivo (SMS работает через сотовую связь, а не данные — устойчиво при ограниченном роуминге данных)
  • НЕТ: ДЕЙСТВИЕ отправить веб-пуш (путешественник может быть в отеле с Wi-Fi)
• ДЕЙСТВИЕ: HttpRequest в ESP для обновления следующего сводного отчета по маршруту по электронной почте
• ВЫХОД по gate_acknowledged или flight_boarded

Одна личность путешественника, один рабочий процесс, четыре канала, выбранные по состоянию. Сначала используется самый дешевый из возможных каналов. SMS — самый дорогой за отправку — используется только тогда, когда путешественник находится в международном роуминге, а сообщение имеет критическое значение по времени. Booking.com позиционировал мобильные сообщения как «взаимодействие с клиентом в реальном времени», а не как массовый маркетинг; этот составной рабочий процесс — та же философия, выраженная в архитектуре рабочего процесса.

Запуск этого с помощью отдельных инструментов означает пять входов для поставщиков, две системы сегментации, которые не согласны относительно того, кто находится в поездке в данный момент, и отсутствие единой атрибуции дохода на одного путешественника по каналу. Выполнение этого внутри одного движка рабочих процессов означает одну личность путешественника, один набор логики принятия решений и один отчет воронки, который показывает, где именно происходит сбой в путешествии. Действие HttpRequest (Workflows.md §5.7) обеспечивает межканальную оркестровку — оно связывает движок рабочих процессов с SMS-шлюзом, ESP и системой бронирования без необходимости использования отдельного инструмента оркестровки.

Математика удержания: повышение конверсии бронирований и пожизненная ценность повторных бронирований при размерах билетов на путешествия

Монетизация путешествий — это высокодоходный сегмент. Стоимость бронирований варьируется от 300 долларов за короткие перелеты до 5000+ долларов за пакетные туры, что меняет математику затрат по сравнению с электронной коммерцией (корзины на 50–200 долларов) и SaaS (годовая подписка 99–999 долларов). PushEngage Workflows отслеживает одни и те же три показателя в каждом узле — в очереди, завершено, вышло — и применяется тот же шаблон аналитики на уровне узлов. Доход от восстановленного бронирования значительно превосходит доход от восстановленной корзины, что облегчает обоснование вклада рабочего процесса в P&L.

Вот как выглядит аналитика на уровне узлов для активного рабочего процесса восстановления бронирований у OTA среднего размера с 5000 ежемесячных незавершенных бронирований при среднем чеке в 1200 долларов (иллюстративные цифры):

Узел	В очереди	Завершено	Выбыло	Примечания
НАЧАЛО (бронирование_отменено)	0	5,000	0	Все незавершенные маршруты поступают
WAIT 1 час	92	4,900	8	8 забронировано в первый час без взаимодействия
ДЕЙСТВИЕ: HttpRequest проверка_тарифа	0	4,900	0	Система бронирования обновляет атрибут fare_status
РЕШЕНИЕ: fare_status действителен	0	4,410	490	490 маршрутов с недействительным тарифом до первого взаимодействия — корректный выход через push-уведомление «изменился тариф»
ДЕЙСТВИЕ: напоминание №1 (исходный тариф)	0	4,410	0	Отправлено первое напоминание
ПОДОЖДАТЬ 24 часа	134	3,950	326	326 забронировано после напоминания №1
Вторая проверка тарифа + РЕШЕНИЕ	0	3,720	230	Еще 230 маршрутов с недействительным тарифом — корректный выход
ДЕЙСТВИЕ: напоминание №2 + 10% промо	0	3,720	0	Второе напоминание
ОЖИДАНИЕ 48 часов	78	3,200	442	Еще 442 забронировано после напоминания №2
ДЕЙСТВИЕ: финальное напоминание + более выгодное предложение	0	3,200	0	Финальный push
КОНЕЦ	н/д	3,200	н/д	3200 не забронировали

В этой когорте 776 незавершенных маршрутов были преобразованы в бронирования во время нахождения в рабочем процессе — показатель восстановления 15,5%. При среднем значении бронирования в 1200 долларов это составляет 931 200 долларов восстановленного дохода в месяц или 11,2 млн долларов в годовом исчислении. Выходы из-за изменения тарифа позволили сохранить еще 720 отношений с путешественниками, предотвратив отправку вводящего в заблуждение push-уведомления «завершите ваше бронирование за 399 долларов», когда тариф уже вырос — 720 обращений в службу поддержки и нарушений доверия к бренду, предотвращенных рабочим процессом, помимо увеличения конверсии бронирований.

Математика затрат пересматривается для путешествий. Веб-push и app-push бесплатны для отправки после получения согласия. SMS через Twilio стоят примерно 0,0079 доллара за сообщение внутри США и 0,05–0,30 доллара за международное сообщение — при 5000 когорт незавершенных бронирований в месяц с 10% долей SMS в поездке это составляет 40–150 долларов за когорту расходов на SMS. WhatsApp Business Platform тарифицируется на основе сеансов. Электронная почта масштабируется в соответствии с контрактом ESP. Задача рабочего процесса — сначала использовать самый дешевый жизнеспособный канал и переходить к SMS или WhatsApp только тогда, когда этого требует состояние. Строка «рабочий процесс восстановления незавершенных бронирований принес 931 тыс. долларов в виде ежемесячных бронирований при совокупной стоимости канала 1500 долларов» — это то самое заявление о P&L, которое выигрывает обсуждение бюджета на следующий год.

Создайте это в PushEngage Workflows для вашего туристического бренда

Каждый из пяти шаблонов для путешествий напрямую сопоставляется с компонентами PushEngage Workflows. Сопоставление:

Шаблон	Используемые типы узлов	Типы используемых действий	Параметр рабочего процесса
Приветствие + развитие первого бронирования	НАЧАЛО, ОЖИДАНИЕ, РЕШЕНИЕ, ДЕЙСТВИЕ, КОНЕЦ	SendPushNotification, AddSegment	Тип запуска: Одиночный
Незавершенное бронирование с выходом из-за изменения тарифа	НАЧАЛО, ОЖИДАНИЕ, ДЕЙСТВИЕ, РЕШЕНИЕ, КОНЕЦ	SendPushNotification, HttpRequest, UpdateAttribute	Тип выполнения: Несколько параллельных; выход по цели booking_completed ИЛИ фильтр аудитории fare_status=invalidated
Предварительное развитие перед поездкой (расчет даты вылета)	НАЧАЛО, ОЖИДАНИЕ (wait_until), ДЕЙСТВИЕ, КОНЕЦ	SendPushNotification	Тип запуска: Один на бронирование; wait_until привязан к атрибуту departure_date
Геолокация в поездке	СТАРТ, РЕШЕНИЕ, ДЕЙСТВИЕ, КОНЕЦ	SendPushNotification, HttpRequest, UpdateAttribute	Тип запуска: Несколько параллельных; триггер CustomEvent + фильтр аудитории
Обзор после поездки + повторное бронирование по похожим аудиториям	СТАРТ, ОЖИДАНИЕ, ДЕЙСТВИЕ, ОЖИДАНИЕ (wait_until), ДЕЙСТВИЕ, РЕШЕНИЕ, КОНЕЦ	SendPushNotification	Тип запуска: Несколько последовательных

Движок Workflows поставляется с более чем 60 готовыми шаблонами, которые охватывают строительные блоки для каждого чертежа. Большинство шаблонов ориентированы на электронную коммерцию, но адаптация к путешествиям проста: логика шаблона "брошенная корзина" становится рабочим процессом "брошенное бронирование" путем замены триггерного события на booking_abandoned, добавления шаблона проверки тарифа с HttpRequest-and-attribute-update из Чертежа 2 и использования критерия выхода "недействительность тарифа" вместе с booking_completed. Шаблон "приветствие" напрямую подходит для Чертежа 1. Шаблон "геолокация по рассылке" — уже в каталоге — является основой для рабочего процесса "в поездке" Чертежа 4.

Для более широкого контекста продвижения в сфере путешествий — нишевых случаев использования (отели, авиабилеты, аренда жилья на время отпуска) и сезонных стратегий — устаревший сборник рекомендаций по пуш-уведомлениям для сайтов путешествий каталогизирует типы кампаний, которые реализуют эти чертежи.

Для немедленного пути пробного использования бесплатный план дает вам 200 подписчиков, все каналы (веб-пуш, пуш в приложении, WhatsApp, живой чат) и полный движок Workflows с первого дня. Этого достаточно, чтобы запустить Чертежи 1 и 2 для вашей следующей когорты брошенных маршрутов и получить аналитику на уровне узлов перед следующим QBR. Для позиционирования PushEngage в туристическом сегменте — цены, интеграции, примеры клиентов — PushEngage для путешествий является канонической целевой страницей.

Что это меняет

Если вы вынесете из этой статьи что-то одно, то вот что: автоматизация пуш-уведомлений для путешествий — это архитектура рабочего процесса, а не трансляции подтверждения бронирования с добавленным триггером брошенного бронирования. Путешествие с брошенным бронированием, которое изящно завершается при изменении тарифа, рабочий процесс перед поездкой, который срабатывает за 7 дней до departure_date, рабочий процесс геолокации в поездке, который учитывает часовой пояс назначения — все они имеют одинаковую форму. Один СТАРТ, несколько ОЖИДАНИЙ, несколько РЕШЕНИЙ, несколько ДЕЙСТВИЙ, один ВЫХОД. Три отдельных триггера не могут этого сделать. Один движок рабочего процесса может. Повторное бронирование LTV накапливается оттуда.

Начните с бесплатного плана, чтобы запустить первый чертеж для вашей следующей когорты брошенных маршрутов.