Automação de notificações push para viagens: 5 modelos de fluxo de trabalho

É terça-feira à tarde e a revisão de retenção terminou às 14:15. A sua taxa de conversão de reservas caiu 1,4 pontos no último trimestre — de 3,6% para 2,2%. A equipa de fidelização acha que a cadência de e-mails de recuperação está a ser enviada demasiado tarde. A equipa móvel acha que o envio de notificações de reserva abandonada está a sobrepor-se aos alertas de alteração de preço. Ninguém consegue provar que uma ou outra seja a causa. Duas horas após a discussão no Slack pós-reunião, a única coisa em que todos concordam é que o painel de controlo não é suficientemente granular para resolver a discussão.

A automação de notificações push para viagens está no centro desta discussão, e ninguém na equipa de retenção tem a certeza de como a defender. O envio automático de confirmação de reserva é ativado quando uma reserva é concluída. O gatilho de reserva abandonada reenvia o mesmo itinerário 24 horas depois — e por vezes esse itinerário já não tem o preço que o viajante abandonou, porque a tarifa mudou durante a noite. O gatilho de aviso de cancelamento que alguém configurou há dois anos ainda é ativado quando o DAU (utilizadores ativos diários) diminui na aplicação, mas não sabe que o assinante está atualmente em viagem e não está realmente a cancelar, apenas de férias. Três mecanismos “automatizados”, nenhum deles ciente dos outros, nenhum deles com uma visão coerente de onde o viajante se encontra no ciclo de vida da viagem.

Este artigo explora como deve ser a automação de notificações push para viagens — arquitetura de fluxo de trabalho, não transmissões de confirmação de reserva com um gatilho de reserva abandonada adicionado — e apresenta cinco modelos de fluxo de trabalho em forma de viagem com temporização, critérios de saída para o momento da alteração da tarifa, tratamento em viagem acionado por geolocalização e a matemática da receita que transforma cada um num item defensável para operações de publicidade e para a equipa de fidelização.

Por que as suas "notificações push automatizadas" de viagens estão a perder receita no momento da alteração da tarifa

A palavra automação tem vindo a desempenhar o mesmo trabalho não merecido nas viagens que desempenha no comércio eletrónico, SaaS e publicação. Quando a maioria das equipas de CRM de viagens fala em notificações push automatizadas para viagens, o que querem dizer é o agendamento de transmissões acionadas por eventos: uma notificação é disparada quando ocorre um evento conhecido, sem estado, sem segmentação, sem esperas entre contactos, sem condições de saída e — criticamente — sem consciência de que a oferta subjacente pode já não ser válida quando o segundo contacto é disparado.

Um fluxo de trabalho é algo diferente. Um fluxo de trabalho é uma jornada de vários passos com estado. Sabe quando o viajante abandonou a reserva, que tarifa viu, que tarifa está atualmente cotada para esse itinerário, qual é o estado da sua viagem e quais as condições que cancelam a jornada. O fluxo de trabalho de reserva abandonada não dispara apenas um lembrete push 24 horas depois. Verifica se a tarifa ainda é válida antes de cada contacto, sai do fluxo de trabalho no momento em que a reserva é concluída e sai separadamente se a tarifa mudar — porque enviar “conclua a sua reserva de 399 €” a um viajante quando a tarifa é agora 529 € destrói a confiança de uma forma que nenhuma reserva recuperada justifica.

Essa última cláusula é a diferença. Os gatilhos de eventos não têm memória do estado externo. Os fluxos de trabalho têm. Se a sua automação de reserva abandonada continuar a recontactar os viajantes com a tarifa antiga depois de a tarifa ter mudado, você não tem uma automação. Tem um gatilho que ninguém disse para verificar.

Para uma equipa de CRM de viagens de mercado médio, esta distinção é a diferença entre um LTV de reservas repetidas que se compõe e um que é corroído por erros que destroem a confiança no momento da alteração da tarifa. Três gatilhos a funcionar em paralelo produzem três canais de atrito. Cinco fluxos de trabalho a funcionar em coordenação produzem uma jornada por viajante por fase da viagem, ramificada e limitada pelo estado da reserva, validade da tarifa e estado da viagem. Os resultados da pesquisa na página um para esta palavra-chave enquadram o problema como “5 casos de uso de viagens” e respondem com uma lista de ferramentas. Essa não é a pergunta que a sua revisão de retenção de terça-feira está a fazer.

A anatomia de um fluxo de trabalho de notificações push de viagens

Antes dos projetos, o vocabulário. Um fluxo de trabalho de notificação push de viagens é construído a partir de seis tipos de nós. Uma vez que saiba o que cada um faz, cada projeto lê-se como um diagrama, não como uma descrição.

INÍCIO. O ponto de entrada. Um nó INÍCIO define como o fluxo de trabalho é acionado, seja por um evento do assinante (booking_initiated, booking_abandoned, fare_changed, geolocation_changed, trip_completed) ou por um filtro de público (lifecycle_stage, loyalty_tier, last_active). Um fluxo de trabalho tem exatamente um INÍCIO.

ESPERAR. Um atraso. Um nó ESPERAR retém o assinante por um período especificado (minutos para reatividade durante a viagem, horas para ritmo de reserva abandonada, dias para cadência pré-viagem) ou até uma hora específica do calendário usando semântica wait_until associada a um atributo do assinante — data_partida - 7 dias, data_partida - 1 dia, data_conclusao_viagem + 1 ano. As esperas são como um fluxo de trabalho honra um evento futuro conhecido, não apenas um passado.

DECISÃO. Um ramal de duas vias. Um nó DECISÃO verifica uma condição por assinante: a reserva foi concluída, a tarifa ainda é válida (lida de um atributo do assinante que o sistema de reservas atualiza), o nível de fidelidade está acima de prata, o viajante está atualmente em viagem. Os nós DECISÃO avaliam filtros de eventos e filtros de público; eles não consomem corpos de resposta HttpRequest diretamente. O padrão que traz estado externo para um fluxo de trabalho é a ação HttpRequest aciona o sistema externo, o sistema externo escreve de volta para um atributo do assinante via API REST PushEngage, e a DECISÃO lê o atributo.

DIVIDIR_CAMINHO. Um garfo baseado em percentagem. Os nós DIVIDIR_CAMINHO roteiam assinantes através de caminhos com base em percentagens configuradas: 50/50 para um teste A/B em montantes de desconto de reserva abandonada, 33/33/34 para um teste de hora de envio de três vias em lembretes pré-viagem. Uma vez que tenha um vencedor, promove esse caminho para 100%.

AÇÃO. O trabalho em si. Os nós AÇÃO enviam uma notificação push, adicionam o assinante a um segmento, atualizam atributos personalizados, disparam um HttpRequest para um sistema de reservas ou gateway SMS, iniciam outro fluxo de trabalho ou param um. PushEngage Workflows suporta onze tipos de ação. Os mais úteis para viagens são SendPushNotification, UpdateAttribute, HttpRequest e Workflow.Start (para encadear pré-viagem em durante a viagem em pós-viagem).

FIM / SAÍDA. O terminal. FIM marca a conclusão natural. SAÍDA marca uma terminação antecipada — no caminho NÃO de uma Decisão quando o viajante não se qualifica mais, quando a regra de arrefecimento dispara, ou quando o objetivo é atingido (reserva concluída, viagem cancelada, tarifa invalidada).

Cada modelo abaixo compõe-se destas seis peças.

Cinco modelos de fluxo de trabalho para viagens

Estes não são modelos. São projetos de trabalho. Cada um lista o seu gatilho, tipo de execução, sequência de nós, critérios de saída e a métrica de retenção de viagens para a qual é construído para mover. Pode carregar cada um para o construtor PushEngage Workflows e enviar a primeira versão em menos de uma hora. O guia legado notificações push de viagens cobre os casos de uso mais amplos que estes projetos implementam.

Modelo 1 — Boas-vindas + nutrição da primeira reserva

• Gatilho (INÍCIO): Evento PushEngage.Subscriber.Added OU browse_destination_page_view
• Tipo de execução: Único (uma jornada de boas-vindas por viajante por janela de 90 dias)
• Fluxo: Notificação de boas-vindas com destinos-mais-populares → AGUARDAR 1 dia → Notificação de preferência de destino a perguntar que tipos de viagem importam (praia, esqui, escapadela urbana, negócios) → AGUARDAR 2 dias → DECISÃO: o assinante iniciou uma reserva? → caminho SIM: encadear para o Blueprint 2 se abandonarem, caso contrário, deixar o fluxo pré-viagem assumir após booking_completed → caminho NÃO: enviar uma notificação de recomendação curada de três destinos, adicionar ao segmento active_browsers, TERMINAR
• Critérios de saída: Objetivo booking_completed
• Métrica de viagem: Taxa de conversão de navegação para primeira reserva ao dia 7.

Modelo 2 — Reserva abandonada com saída por alteração de tarifa (automação de notificações push de abandono de reserva)

• Gatilho (INÍCIO): Evento personalizado booking_abandoned com payload itinerary_id
• Tipo de execução: Múltiplos Paralelos (cada reserva abandonada é uma instância de fluxo própria)
• Fluxo: AGUARDAR 1 hora → AÇÃO: HttpRequest GET para o endpoint de verificação de tarifas do seu sistema de reservas para o itinerary_id. O sistema de reservas escreve de volta para um atributo do assinante através da API REST PushEngage — fare_status = valid ou fare_status = invalidated — em segundos → DECISÃO: filtro de audiência fare_status = valid? → caminho NÃO: enviar uma notificação “a sua tarifa mudou, aqui estão opções semelhantes com o novo preço” e TERMINAR (reencaminhamento gracioso, sem violação de confiança) → caminho SIM: notificação de lembrete com a tarifa original → AGUARDAR 24 horas → repetir a HttpRequest de verificação de tarifas, depois DECISÃO sobre fare_status = valid E filtro de audiência booking_completed = false → caminho SIM: lembrete #2 com um código promocional de 10% → AGUARDAR 48 horas → lembrete final com uma oferta mais forte → TERMINAR
• Critérios de saída: Objetivo booking_completed correspondente ao itinerary_id do gatilho OU filtro de audiência fare_status = invalidated
• Métrica de viagem: Valor de reserva recuperado por reserva abandonada. Este é o fluxo com a linha de receita mais defensável na página. A publicação 6 dicas para reduzir o abandono de reservas cobre a versão tática manual deste blueprint; a versão de fluxo adiciona a saída de validade da tarifa que transforma uma recuperação tática numa que preserva a confiança na marca.

Modelo 3 — Nutrição pré-viagem (matemática da data de partida)

Este é o fluxo de notificações push pré-viagem que demonstra a semântica wait_until ligada a um atributo do assinante.

• Gatilho (INÍCIO): Evento personalizado booking_completed (que escreve departure_date para um atributo do assinante)
• Tipo de execução: Único por reserva
• Fluxo: AGUARDAR até data_partida - 14 dias → push “a sua viagem é daqui a duas semanas” com recomendações de bagagem e previsão meteorológica → AGUARDAR até data_partida - 7 dias → push de receita acessória (upgrade de lugar, upgrade de quarto, aluguer de carro adicional, transfer do aeroporto) → AGUARDAR até data_partida - 1 dia → push de lembrete de check-in com link para o cartão de embarque móvel → AGUARDAR até data_partida → push de bom viagem, FIM
• Critérios de saída: Objetivo reserva_cancelada
• Métrica de viagem: Receita acessória por reserva. O contacto 7 dias antes é o momento de maior alavancagem para receitas acessórias.

Modelo 4 — Geolocalização em viagem (automação de notificações push por geolocalização)

• Gatilho (INÍCIO): Evento personalizado geolocalizacao_alterada (disparado pela sua aplicação móvel quando o dispositivo reporta uma nova lat/lng) E filtro de audiência viagem_em_curso = verdadeiro
• Tipo de execução: Múltiplos Paralelos
• Fluxo: DECISÃO: o viajante chegou à cidade de destino (filtro de audiência compara coordenadas de geolocalização com um geofence de destino armazenado como atributo do assinante)? → caminho SIM: AÇÃO enviar push de recomendações locais (hotéis, restaurantes, atividades locais ligadas ao destino), AÇÃO HttpRequest para a API meteorológica → se um alerta meteorológico for justificado, AÇÃO enviar notificação meteorológica → FIM → caminho NÃO: SAIR (viajante em trânsito, não no destino)
• Horário de silêncio: ciente do fuso horário do assinante. Workflows.md §9.4 resolve o horário de silêncio primeiro pelo fuso horário do assinante, depois pelo fuso horário do site, depois pelo UTC. Para fluxos de viagem, isto significa que o fuso horário respeita a hora local do destino, não o mercado de origem da marca. Pushes não críticos usam skip; alertas de segurança e meteorológicos usam reschedule para garantir a entrega
• Critérios de saída: Objetivo viagem_concluida
• Métrica de viagem: Taxa de engagement durante a viagem e receita acessória durante a viagem. Nota: geolocalizacao_alterada não é um tipo de gatilho incorporado — é um PushEngage.CustomEvent que a sua aplicação móvel dispara quando a localização do dispositivo é atualizada, e a verificação de chegada ao destino é um filtro de audiência em atributos do assinante que a aplicação mantém. As notificações push de geolocalização cobrem a base de segmentação que este blueprint estende.

Modelo 5 — Revisão pós-viagem + remarcação semelhante

• Gatilho (INÍCIO): Evento personalizado viagem_concluida
• Tipo de execução: Múltiplos Sequenciais
• Fluxo: AGUARDAR 3 dias → push de pedido de avaliação referenciando o destino pelo nome → AGUARDAR até data_conclusao_viagem + 365 dias (um ano depois) → push “pronto para a sua próxima viagem?” com uma oferta semelhante ao destino com base no tipo de viagem anterior → AGUARDAR 7 dias → DECISÃO: o viajante iniciou uma reserva? → caminho SIM: encadear no Blueprint 1 ou 2 → caminho NÃO: SAIR
• Critérios de saída: Evento reserva_iniciada novo OU cancelou_subscricao
• Métrica de viagem: Taxa de reserva repetida aos 12 meses. Este é o blueprint de maior duração — cerca de 13 meses — e o que tem o maior impacto no LTV. O padrão de semelhança ano a ano é o análogo de viagem do 'win-back' pós-compra do eCommerce, adaptado à cadência sazonal que os compradores de viagens realmente seguem.

Segmentação por fase do ciclo de vida, testes A/B, horas de silêncio por fuso horário do destino e critérios de saída vivem dentro do fluxo de trabalho

O padrão dominante nos artigos de 'push' de viagens é listar estes quatro conceitos como “melhores práticas” — 'bullets' genéricos no final de um artigo de estratégia, divorciados das campanhas que os utilizam. Essa é a moldura errada. Não são melhores práticas que ficam ao lado do fluxo de trabalho. Eles são o fluxo de trabalho.

Conceito	Moldura de melhores práticas (errada)	Moldura de nós de fluxo de trabalho (correta)
Segmentação por fase do ciclo de vida	“Segmentar viajantes por fase da viagem”	Um nó DECISION no atributo do assinante lifecycle_stage (navegação / início de reserva / pré-viagem / em viagem / pós-viagem / inativo) que encaminha viajantes em pré-viagem para 'nudges' auxiliares, viajantes em viagem para fluxos de trabalho de geolocalização, viajantes pós-viagem para revisão e semelhança para remarcação.
Testes A/B	“Teste sempre A/B o seu texto de reserva abandonada”	Um nó SPLIT_PATH com alocação 50/50, assinantes balanceados por caminho, e um campo winner_edge_id que promove o vencedor para 100% assim que o teste atinge significância — a maioria dos testes A/B de viagens é executada no valor do desconto no lembrete #2.
Horário de silêncio por fuso horário do destino	“Não envie às 3 da manhã”	Uma opção a nível de fluxo de trabalho com timezone: subscriber e uma configuração fallback que ou skip o envio (notificações não críticas) ou o reschedule para um minuto após o fim do horário de silêncio (segurança, meteorologia, alteração de portão) — crítico para fluxos de trabalho em viagem onde o fuso horário local do assinante é o destino, não o mercado de origem da marca.
Critério de saída	“Pare a sequência de reserva abandonada assim que eles reservarem”	Uma regra a nível de fluxo de trabalho que verifica o viajante contra o objetivo booking_completed E o atributo fare_status = invalidated antes de cada nó, e cancela o fluxo de trabalho se algum deles corresponder — a segunda condição é o que nenhum resultado de SERP descreve.

A diferença importa porque os 'bullets' de melhores práticas são fáceis de concordar e difíceis de impor. Os nós de fluxo de trabalho são impostos pelo motor. O DECISION executa todas as vezes. O SPLIT_PATH balanceia todos os viajantes. O 'fallback' de horário de silêncio ativa-se sem que ninguém se lembre de verificar o fuso horário do destino. A regra de saída cancela o fluxo de trabalho de reserva abandonada, quer o proprietário da campanha esteja atento ou não.

Para o fluxo de reserva abandonada do Blueprint 2, isto significa que no momento em que um viajante reserva — à hora 1, hora 30 ou hora 73 do fluxo de trabalho — a regra de saída dispara, o fluxo de trabalho é cancelado para esse viajante, e nenhuma outra notificação “complete a sua reserva” é enviada a alguém que já pagou ontem. Separadamente, no momento em que a tarifa muda e o sistema de reservas atualiza fare_status = invalidated, o fluxo de trabalho termina graciosamente e envia a notificação de recuperação “tarifa alterada, aqui estão opções semelhantes”. Nenhuma violação de confiança. Nenhuma chamada zangada para o serviço de apoio ao cliente.

Orquestração multicanal: notificações push web, notificações push app, SMS, WhatsApp, e-mail

As marcas de viagens gerem mais canais do que equipas de eCommerce, SaaS ou editoras. Notificações push web para o fluxo de reserva no desktop. Notificações push de app para viajantes que descarregaram a app da marca. SMS como canal resiliente a roaming de dados para alertas críticos durante a viagem (alteração de portão, atraso de voo, meteorologia). WhatsApp para atendimento ao cliente de alto contacto e viajantes internacionais em regiões onde o WhatsApp é o mensageiro padrão. Email como contentor do itinerário pré-viagem em formato longo. Compor todos os cinco dentro de um único fluxo de trabalho — escolher o canal que corresponde ao estado do subscritor — é o que faz a diferença entre uma equipa de CRM que oferece uma jornada coerente e uma que tem de pedir desculpa por uma notificação push às 3 da manhã “o seu voo está no horário” que acordou um viajante num fuso horário de destino.

Uma jornada composta de alteração de portão durante a viagem lê-se assim:

• INÍCIO: Evento personalizado gate_change para um itinerário onde trip_in_progress = true
• DECISÃO: o viajante está atualmente na app móvel da marca?
  • SIM: AÇÃO disparar notificação push de app (menor atrito, entrega ciente de roaming de dados)
  • NÃO: continuar
• DECISÃO: o viajante está em roaming internacional (filtro de audiência em country diferente de home_country)?
  • SIM: AÇÃO enviar SMS via HttpRequest para Twilio ou Plivo (SMS utiliza a rede celular, não dados — resiliente quando os dados de roaming são limitados)
  • NÃO: AÇÃO disparar notificação push web (o viajante pode estar em Wi-Fi do hotel)
• AÇÃO: HttpRequest para o ESP para atualizar o próximo resumo do itinerário por email
• FIM em gate_acknowledged ou flight_boarded

Uma identidade de viajante, um fluxo de trabalho, quatro canais escolhidos pelo estado. O canal viável mais barato vai primeiro. SMS — o mais caro por envio — só é disparado quando o viajante está em roaming internacional e a mensagem é crítica em termos de tempo. Booking.com enquadrou a comunicação móvel como “interação em tempo real com o cliente” em vez de marketing de difusão; este fluxo de trabalho composto é a mesma filosofia expressa como arquitetura de fluxo de trabalho.

Executar isto com ferramentas separadas significa cinco logins de fornecedor, dois motores de segmentação que discordam sobre quem está atualmente em viagem, e nenhuma atribuição de receita única por viajante por canal. Fazer isto dentro de um único motor de fluxo de trabalho significa uma identidade de viajante, um conjunto de lógica de decisão, e um relatório de funil que mostra onde a jornada realmente falha. A ação HttpRequest (Workflows.md §5.7) é o que torna a orquestração entre canais possível — liga o motor de fluxo de trabalho ao gateway SMS, ao ESP, e ao sistema de reservas sem necessitar de uma ferramenta de orquestração separada.

A matemática da retenção: aumento da conversão de reservas e LTV (valor vitalício do cliente) de reservas repetidas em tamanhos de bilhetes de viagem

A monetização de viagens é de alto valor. Os valores das reservas variam entre voos de curta distância de $300 a pacotes de férias de mais de $5.000 — o que altera a matemática de custos em comparação com o comércio eletrónico (carrinhos de $50–$200) e SaaS ($99–$999 ARR). Os Fluxos de Trabalho do PushEngage rastreiam os mesmos três números em cada nó — em fila, concluído, saído — e o mesmo padrão de análise a nível de nó aplica-se. A receita por reserva recuperada supera em muito a receita por carrinho recuperado, o que torna a contribuição do fluxo de trabalho para o P&L mais fácil de defender.

Eis como se apresentam as análises a nível de nó para um fluxo de trabalho ativo de reserva abandonada numa OTA de mercado intermédio com 5.000 reservas abandonadas mensais a um valor médio de $1.200 (números ilustrativos):

Nó	Enfileirado	Concluído	Saído	Notas
INÍCIO (reserva_abandonada)	0	5,000	0	Todas as viagens abandonadas entram
ESPERA 1 hora	92	4,900	8	8 reservadas na primeira hora sem interação
AÇÃO: HttpRequest verificação de tarifa	0	4,900	0	Sistema de reservas atualiza o atributo fare_status
DECISÃO: fare_status válido	0	4,410	490	490 itinerários com tarifa invalidada antes da primeira interação — saída graciosa via notificação push de “tarifa alterada”
AÇÃO: lembrete #1 (tarifa original)	0	4,410	0	Primeiro lembrete enviado
AGUARDAR 24 horas	134	3,950	326	326 reservadas após o lembrete #1
Segunda verificação de tarifa + DECISÃO	0	3,720	230	Mais 230 itinerários com tarifa invalidada — saída graciosa
AÇÃO: lembrete #2 + promoção de 10%	0	3,720	0	Segundo lembrete
ESPERAR 48 horas	78	3,200	442	Mais 442 reservadas após o lembrete #2
AÇÃO: lembrete final + oferta mais forte	0	3,200	0	Notificação final
FIM	n/d	3,200	n/d	3.200 não reservaram

Nesta coorte, 776 itinerários abandonados converteram-se em reservas enquanto estavam no fluxo de trabalho — uma taxa de recuperação de 15,5%. A $1.200 de valor médio de reserva, isso representa $931.200 em receita recuperada por mês, ou $11,2M anualizados. As saídas por alteração de tarifa pouparam mais 720 relações com viajantes de receberem uma notificação enganosa de “complete a sua reserva de $399” quando a tarifa já tinha subido — 720 chamadas de apoio ao cliente e violações de confiança na marca que o fluxo de trabalho evitou, separadamente do aumento da conversão de reservas.

A matemática de custos reformula-se para viagens. As notificações push web e app não custam nada por envio após a adesão. SMS via Twilio custa aproximadamente $0,0079 por mensagem doméstica nos EUA e $0,05–$0,30 por mensagem internacional — com 5.000 coortes de reservas abandonadas por mês e uma participação de 10% de SMS durante a viagem, isso representa $40–$150 por coorte em gastos com SMS. A plataforma WhatsApp Business tem preços baseados em sessões. O email escala com o contrato do ESP. A função do fluxo de trabalho é usar primeiro o canal viável mais barato e escalar para SMS ou WhatsApp apenas quando o estado o exigir. O item de linha que diz “fluxo de trabalho de reserva abandonada recuperou $931K em reservas mensais a um custo total de canal de $1.500” é o tipo de declaração de P&L que ganha a conversa de orçamento do próximo ano.

Construa-o em Fluxos de Trabalho PushEngage para a sua marca de viagens

Cada um dos cinco modelos de viagem mapeia diretamente para os componentes dos Fluxos de Trabalho do PushEngage. O mapeamento:

Modelo	Tipos de nós utilizados	Tipos de ação utilizados	Opção de fluxo
Boas-vindas + nutrição da primeira reserva	INÍCIO, ESPERA, DECISÃO, AÇÃO, FIM	SendPushNotification, AddSegment	Tipo de execução: Único
Reserva abandonada com saída por alteração de tarifa	INÍCIO, ESPERA, AÇÃO, DECISÃO, FIM	SendPushNotification, HttpRequest, UpdateAttribute	Tipo de execução: Múltiplos Paralelos; sair no objetivo booking_completed OU filtro de audiência fare_status=invalidated
Nutrição pré-viagem (cálculo da data de partida)	INÍCIO, ESPERA (wait_until), AÇÃO, FIM	SendPushNotification	Tipo de execução: Único por reserva; wait_until associado ao atributo departure_date
Geolocalização durante a viagem	INÍCIO, DECISÃO, AÇÃO, FIM	SendPushNotification, HttpRequest, UpdateAttribute	Tipo de execução: Múltiplos Paralelos; Gatilho de evento personalizado + filtro de público
Revisão pós-viagem + remarketing para reserva	INÍCIO, ESPERAR, AÇÃO, ESPERAR (wait_until), AÇÃO, DECISÃO, FIM	SendPushNotification	Tipo de execução: Múltiplo Sequencial

O motor Workflows vem com mais de 60 modelos pré-configurados que cobrem os blocos de construção para cada projeto. A maioria dos modelos é moldada para e-commerce, mas a adaptação para viagens é direta: a lógica do modelo de abandono de carrinho torna-se um fluxo de trabalho de reserva abandonada, trocando o evento de gatilho para booking_abandoned, adicionando o padrão de verificação de tarifa de atualização de atributo e solicitação HTTP do Projeto 2, e usando um critério de saída de invalidação de tarifa juntamente com booking_completed. O modelo de boas-vindas adapta-se diretamente ao Projeto 1. O modelo de gotejamento de geolocalização — já no catálogo — é a base para o fluxo de trabalho durante a viagem do Projeto 4.

Para o contexto mais amplo de envio para viagens — casos de uso específicos de nicho (hotéis, voos, aluguéis de temporada) e estratégias de sazonalidade — o manual de notificações push de sites de viagens legado cataloga os tipos de campanha que esses projetos implementam.

Para o caminho de teste imediato, o plano gratuito oferece 200 assinantes, todos os canais (notificações push web, push de aplicativo, WhatsApp, chat ao vivo) e o motor Workflows completo desde o primeiro dia. Isso é suficiente para implementar os Projetos 1 e 2 na sua próxima coorte de itinerários abandonados e capturar análises de nível de nó antes do próximo QBR. Para o posicionamento de viagens da PushEngage — preços, integrações, exemplos de clientes — PushEngage para viagens é a página de destino canônica.

O que isto muda

Se você tirar uma coisa deste artigo, tire isto: a automação de notificações push para viagens é arquitetura de fluxo de trabalho, não transmissões de confirmação de reserva com um gatilho de reserva abandonada adicionado. A jornada de reserva abandonada que termina graciosamente com uma alteração de tarifa, o fluxo de trabalho pré-viagem que é acionado em departure_date - 7 dias, o fluxo de trabalho de geolocalização durante a viagem que respeita o fuso horário do destino — todos eles têm a mesma forma. Um INÍCIO, alguns ESPERARs, algumas DECISÕES, algumas AÇÕEs, um FIM. Três gatilhos independentes não podem fazer isso. Um motor de fluxo de trabalho pode. O LTV de reserva repetida se compõe a partir daí.

Comece no plano gratuito para implementar o primeiro projeto na sua próxima coorte de itinerários abandonados.