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 14h15. Sua taxa de conversão de reservas caiu 1,4 ponto no último trimestre — de 3,6% para 2,2%. A equipe de fidelidade acha que a cadência de e-mails de recuperação está sendo disparada tarde demais. A equipe móvel acha que o push de reserva abandonada está se sobrepondo aos alertas de queda de preço. Ninguém consegue provar que um dos dois é a causa. Duas horas após a thread do Slack pós-reunião, a única coisa em que todos concordam é que o painel não é granular o suficiente para resolver a discussão.

A automação de notificações push para viagens está no centro dessa discussão, e ninguém da equipe de retenção tem certeza de como defendê-la. O push automático de confirmação de reserva é disparado quando uma reserva é concluída. O gatilho de reserva abandonada re-sinaliza o mesmo itinerário 24 horas depois — e às vezes esse itinerário não está mais com o preço que o viajante abandonou, porque a tarifa mudou durante a noite. O gatilho de aviso de churn que alguém configurou há dois anos ainda dispara quando o DAU cai no aplicativo, mas ele não sabe que o assinante está atualmente em viagem e não está realmente desistindo, apenas de férias. Três mecanismos "automatizados", nenhum deles ciente um do outro, nenhum deles mantendo uma visão coerente de onde o viajante se encontra no ciclo de vida da viagem.

Este artigo detalha como a automação de push para viagens realmente deveria ser — arquitetura de fluxo de trabalho, não transmissões de confirmação de reserva com um gatilho de reserva abandonada acoplado — e apresenta cinco modelos de fluxo de trabalho com formato de viagem, com tempo, critérios de saída para o momento da alteração da tarifa, tratamento durante a viagem acionado por geolocalização e a matemática de receita que transforma cada um em um item defensável para operações de publicidade e a equipe de fidelidade.

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

A palavra automação tem feito o mesmo trabalho não merecido em viagens que fez no comércio eletrônico, SaaS e publicação. Quando a maioria das equipes de CRM de viagens fala sobre notificações push automatizadas para viagens, o que elas querem dizer é o agendamento de transmissão acionado por eventos: uma notificação é disparada quando um evento conhecido ocorre, sem estado, sem segmentação, sem esperas entre os contatos, sem condições de saída e — criticamente — sem consciência de que a oferta subjacente pode não ser mais válida quando o segundo contato for disparado.

Um fluxo de trabalho é algo diferente. Um fluxo de trabalho é uma jornada de várias etapas com estado. Ele sabe quando o viajante abandonou a reserva, qual tarifa ele viu, qual tarifa está sendo cotada atualmente nesse itinerário, qual é o status da viagem dele e quais condições cancelam a jornada. O fluxo de trabalho de reserva abandonada não dispara apenas um lembrete push 24 horas depois. Ele verifica se a tarifa ainda é válida antes de cada contato, sai do fluxo de trabalho no momento em que a reserva é concluída e sai separadamente se a tarifa mudar — porque enviar “complete sua reserva de US$ 399” para um viajante quando a tarifa agora é de US$ 529 destrói a confiança de uma forma que nenhuma reserva recuperada justifica.

Essa última cláusula é a diferença. Gatilhos de eventos não têm memória do estado externo. Fluxos de trabalho têm. Se sua automação de reserva abandonada continuar a recontactar viajantes com a tarifa antiga depois que a tarifa mudou, você não tem uma automação. Você tem um gatilho que ninguém instruiu a verificar.

Para uma equipe de CRM de viagens de médio porte, essa distinção é a diferença entre um LTV de reserva recorrente que se compõe e um que é corroído por erros que destroem a confiança no momento da mudança de tarifa. Três gatilhos executados em paralelo produzem três canais de atrito. Cinco fluxos de trabalho executados em coordenação produzem uma jornada por viajante por estágio de viagem, ramificada e limitada pelo estado da reserva, validade da tarifa e status da viagem. Os resultados da pesquisa na página inicial 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 sua revisão de retenção de terça-feira está fazendo.

A anatomia de um fluxo de trabalho de notificação 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 você saiba o que cada um faz, cada projeto será lido como um diagrama, não como uma descrição.

INICIAR. O ponto de entrada. Um nó INICIAR 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 INICIAR.

AGUARDE. Um atraso. Um nó WAIT retém o assinante por um período especificado (minutos para reatividade durante a viagem, horas para o ritmo de reserva abandonada, dias para a cadência pré-viagem) ou até um horário de calendário específico usando semântica wait_until vinculada a um atributo do assinante — departure_date - 7 dias, departure_date - 1 dia, trip_completion_date + 1 ano. 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ó DECISION 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. Nós DECISION 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 é que a ação HttpRequest aciona o sistema externo, o sistema externo escreve de volta em um atributo do assinante via PushEngage REST API, e a DECISÃO lê o atributo.

SPLIT_PATH. Um garfo baseado em porcentagem. Nós SPLIT_PATH roteiam assinantes por caminhos com base em porcentagens configuradas: 50/50 para um teste A/B em valores de desconto de reserva abandonada, 33/33/34 para um teste de três vias de horário de envio em lembretes pré-viagem. Uma vez que você tenha um vencedor, você o promove para 100%.

AÇÃO. O trabalho em si. Nós ACTION 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. END marca a conclusão natural. EXIT 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 resfriamento dispara, ou quando o objetivo é atingido (reserva concluída, viagem cancelada, tarifa invalidada).

Cada blueprint abaixo se compõe dessas 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 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 que ele é construído para mover. Você pode carregá-los no construtor PushEngage Workflows e enviar a primeira versão em menos de uma hora. O guia legado travel push notifications guide cobre os casos de uso mais amplos que esses projetos implementam.

Modelo 1 — Boas-vindas + nutrição para a 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: Push de boas-vindas com destinos-mais-populares → AGUARDE 1 dia → push de preferência de destino perguntando quais tipos de viagem importam (praia, esqui, city break, negócios) → AGUARDE 2 dias → DECISÃO: o assinante iniciou uma reserva? → caminho SIM: encadeie no Blueprint 2 se abandonar, caso contrário, deixe o fluxo pré-viagem assumir após booking_completed → caminho NÃO: envie um push com recomendação curada de três destinos, adicione ao segmento active_browsers, FIM
• Critérios de saída: Meta booking_completed
• Métrica de viagem: Taxa de conversão de navegação para primeira reserva em 7 dias.

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: AGUARDE 1 hora → AÇÃO: HttpRequest GET para o endpoint de verificação de tarifa do seu sistema de reservas para o itinerary_id. O sistema de reservas escreve de volta em um atributo do assinante via PushEngage REST API — fare_status = valid ou fare_status = invalidated — em segundos → DECISÃO: filtro de público fare_status = valid? → caminho NÃO: envie um push “sua tarifa mudou, aqui estão opções semelhantes com o novo preço” e SAIA (redirecionamento gracioso, sem violação de confiança) → caminho SIM: push de lembrete com a tarifa original → AGUARDE 24 horas → repita a verificação de tarifa HttpRequest, então DECISÃO sobre fare_status = valid E filtro de público booking_completed = false → caminho SIM: lembrete nº 2 com um código promocional de 10% → AGUARDE 48 horas → lembrete final com uma oferta mais forte → FIM
• Critérios de saída: Meta booking_completed correspondente ao itinerary_id do gatilho OU filtro de público 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. O post 6 dicas para reduzir o abandono de reservas cobre a versão tática manual deste blueprint; a versão do fluxo adiciona a saída de validade da tarifa que transforma uma recuperação tática em uma que preserva a confiança na marca.

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

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

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

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

• Gatilho (INÍCIO): Evento personalizado geolocalizacao_alterada (disparado pelo seu aplicativo móvel quando o dispositivo informa uma nova lat/lng) E filtro de público viagem_em_andamento = true
• Tipo de execução: Múltiplos Paralelos
• Fluxo: DECISÃO: o viajante chegou à cidade de destino (filtro de público 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 API de clima → se um alerta climático for justificado, AÇÃO enviar notificação climática → FIM → Caminho NÃO: SAIR (viajante está 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 por UTC. Para fluxos durante a viagem, isso significa que o fuso horário respeita o horário local do destino, não o mercado de origem da marca. Pushes não críticos usam skip; alertas de segurança e clima usam reschedule para garantir a entrega
• Critérios de saída: Meta viagem_concluida
• Métrica de viagem: Taxa de engajamento durante a viagem e receita acessória durante a viagem. Observação: geolocalizacao_alterada não é um tipo de gatilho integrado — é um PushEngage.CustomEvent que seu aplicativo móvel dispara quando a localização do dispositivo é atualizada, e a verificação no destino é um filtro de público em atributos do assinante que o aplicativo mantém. As notificações push de geolocalização cobrem a base de segmentação que este blueprint estende.

Modelo 5 — Avaliação pós-viagem + remarketing para reservas semelhantes

• Gatilho (INÍCIO): Evento personalizado viagem_concluida
• Tipo de execução: Múltiplos Sequenciais
• Fluxo: AGUARDE 3 dias → push de solicitação de avaliação referenciando o destino pelo nome → AGUARDE até data_conclusao_viagem + 365 dias (um ano depois) → push “pronto para sua próxima viagem?” com uma oferta semelhante ao destino com base no tipo de viagem anterior → AGUARDE 7 dias → DECISÃO: o viajante iniciou uma reserva? → Caminho SIM: encadeie no Blueprint 1 ou 2 → Caminho NÃO: SAIR
• Critérios de saída: Novo evento reserva_iniciada OU desinscrito
• Métrica de viagem: Taxa de recompra em 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 lookalike 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 estágio do ciclo de vida, testes A/B, horários de silêncio por fuso horário de destino e critérios de saída vivem dentro do fluxo de trabalho

O padrão dominante em artigos de push de viagens é listar esses quatro conceitos como “melhores práticas” — marcadores genéricos no final de um post 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	Enquadramento de melhores práticas (errado)	Enquadramento de nó de fluxo de trabalho (correto)
Segmentação por estágio do ciclo de vida	“Segmentar viajantes por estágio da viagem”	Um nó DECISION no atributo do assinante lifecycle_stage (navegando / reserva iniciada / pré-viagem / em viagem / pós-viagem / inativo) que direciona viajantes pré-viagem para incentivos auxiliares, viajantes em viagem para fluxos de trabalho de geolocalização, viajantes pós-viagem para avaliações e recompra lookalike
Teste A/B	“Sempre teste A/B sua cópia 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 nº 2
Horário de silêncio por fuso horário de destino	“Não envie às 3 da manhã”	Uma opção em nível de fluxo de trabalho com timezone: subscriber e uma configuração fallback que skip (pula) o envio (notificações não críticas) ou reschedule (reenvia) para um minuto após o término do horário de silêncio (segurança, clima, troca 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érios de saída	“Pare a sequência de reserva abandonada assim que eles reservarem”	Uma regra em 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 qualquer um deles corresponder — a segunda condição é o que nenhum resultado de SERP descreve

A diferença importa porque os marcadores 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 é executado todas as vezes. O SPLIT_PATH balanceia todos os viajantes. O fallback de horário de silêncio é ativado sem que ninguém se lembre de verificar o fuso horário de destino. A regra de saída cancela o fluxo de trabalho de reserva abandonada, quer o proprietário da campanha esteja prestando atenção ou não.

Para o fluxo de reserva abandonada do Blueprint 2, isso significa que no momento em que um viajante reserva — na hora 1, hora 30 ou hora 73 do fluxo de trabalho — a regra de saída é acionada, o fluxo de trabalho é cancelado para esse viajante, e nenhuma outra notificação de “complete sua reserva” é enviada para 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 sai graciosamente e envia a notificação de recuperação “tarifa alterada, aqui estão opções semelhantes”. Nenhuma violação de confiança. Nenhuma ligação irritada para o atendimento ao cliente.

Orquestração multicanal: push da web, push do app, SMS, WhatsApp, e-mail

Marcas de viagens gerenciam mais canais do que equipes de eCommerce, SaaS ou publicadoras. Web push para o fluxo de reserva no desktop. App push para viajantes que baixaram o aplicativo da marca. SMS como o canal resiliente a roaming de dados para alertas críticos durante a viagem (mudança de portão, atraso de voo, clima). WhatsApp para atendimento ao cliente de alto contato e viajantes internacionais em regiões onde o WhatsApp é o mensageiro padrão. E-mail como o contêiner do itinerário pré-viagem em formato longo. Compor todos os cinco dentro de um único fluxo de trabalho — escolhendo o canal que corresponde ao estado do assinante — é o que faz a diferença entre uma equipe de CRM que oferece uma jornada coerente e uma que tem que se desculpar por um push às 3 da manhã "seu voo está no horário" que acordou um viajante em um fuso horário de destino.

Uma jornada composta de mudança de portão durante a viagem lê assim:

• INÍCIO: Evento personalizado gate_change para um itinerário onde trip_in_progress = true
• DECISÃO: o viajante está atualmente no aplicativo móvel da marca?
  • SIM: AÇÃO disparar app push (menor atrito, entrega ciente de roaming de dados)
  • NÃO: continuar
• DECISÃO: o viajante está em roaming internacional (filtro de público por country diferente de home_country)?
  • SIM: AÇÃO enviar SMS via HttpRequest para Twilio ou Plivo (SMS usa a rede celular, não dados — resiliente quando dados de roaming são limitados)
  • NÃO: AÇÃO disparar web push (o viajante pode estar no Wi-Fi do hotel)
• AÇÃO: HttpRequest para ESP para atualizar o próximo resumo do itinerário por e-mail
• 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ó dispara quando o viajante está em roaming internacional e a mensagem é crítica em tempo. Booking.com enquadrou a comunicação móvel como "interação em tempo real com o cliente" em vez de marketing de transmissão; este fluxo de trabalho composto é a mesma filosofia expressa como arquitetura de fluxo de trabalho.

Executar isso com ferramentas separadas significa cinco logins de fornecedores, 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 isso 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 — ela conecta o motor de fluxo de trabalho ao gateway SMS, ao ESP e ao sistema de reservas sem a necessidade de uma ferramenta de orquestração separada.

A matemática da retenção: aumento da conversão de reservas e LTV de reservas recorrentes em tamanhos de bilhetes de viagem

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

Veja como são as análises de nível de nó para um fluxo de trabalho ativo de reserva abandonada em uma OTA de mercado intermediário com 5.000 reservas abandonadas mensais a um tíquete médio de US$ 1.200 (números ilustrativos):

Nó	Na Fila	Concluídos	Saíram	Observações
INÍCIO (reserva_abandonada)	0	5,000	0	Todos os itinerários abandonados entram
AGUARDAR 1 hora	92	4,900	8	8 reservados na primeira hora sem interação
AÇÃO: HttpRequest verificação_tarifa	0	4,900	0	Sistema de reservas atualiza o atributo status_tarifa
DECISÃO: status_tarifa válido	0	4,410	490	490 itinerários com tarifa invalidada antes da primeira interação — saída graciosa via push de “tarifa alterada”
AÇÃO: lembrete nº 1 (tarifa original)	0	4,410	0	Primeiro lembrete enviado
AGUARDAR 24 horas	134	3,950	326	326 reservados após o lembrete nº 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 nº 2 + 10% de promoção	0	3,720	0	Segundo lembrete
AGUARDAR 48 horas	78	3,200	442	Mais 442 reservados após o lembrete nº 2
AÇÃO: lembrete final + oferta mais forte	0	3,200	0	Push final
FIM	n/d	3,200	n/d	3.200 não reservaram

Nesta coorte, 776 itinerários abandonados foram convertidos em reservas enquanto estavam no fluxo de trabalho — uma taxa de recuperação de 15,5%. A US$ 1.200 de valor médio de reserva, isso representa US$ 931.200 em receita recuperada por mês, ou US$ 11,2 milhões anualizados. As saídas por alteração de tarifa salvaram outros 720 relacionamentos de viajantes de receber um push enganoso de “complete sua reserva de US$ 399” quando a tarifa já havia aumentado — 720 chamados de atendimento ao cliente e violações de confiança na marca que o fluxo de trabalho evitou, separadamente do aumento na conversão de reservas.

A matemática de custos se reformula para viagens. Push da web e push do aplicativo não custam nada por envio após o opt-in. SMS via Twilio custa aproximadamente US$ 0,0079 por mensagem doméstica nos EUA e US$ 0,05–US$ 0,30 por mensagem internacional — com 5.000 coortes de reserva abandonada por mês e uma participação de 10% de SMS em viagens, isso representa US$ 40–US$ 150 por coorte em gastos com SMS. A precificação da WhatsApp Business Platform é baseada em sessão. O e-mail escala com o contrato do ESP. O trabalho do fluxo de trabalho é usar o canal viável mais barato primeiro e escalar para SMS ou WhatsApp apenas quando o estado exigir. O item que diz “fluxo de trabalho de reserva abandonada recuperou US$ 931 mil em reservas mensais a um custo total de canal de US$ 1.500” é o tipo de declaração de P&L que ganha a conversa de orçamento do próximo ano.

Crie no PushEngage Workflows para sua marca de viagens

Cada um dos cinco blueprints de viagem mapeia diretamente para os componentes do PushEngage Workflows. O mapeamento:

Blueprint	Tipos de nós usados	Tipos de ação usados	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 na meta reserva_concluída OU filtro de público status_tarifa=invalidado
Nutrição pré-viagem (cálculo da data de partida)	INÍCIO, ESPERA (esperar_até), AÇÃO, FIM	SendPushNotification	Tipo de execução: Único por reserva; wait_until vinculado ao atributo departure_date
Geolocalização durante a viagem	INÍCIO, DECISÃO, AÇÃO, FIM	SendPushNotification, HttpRequest, UpdateAttribute	Tipo de execução: Múltiplo Paralelo; gatilho de evento personalizado + filtro de público
Revisão pós-viagem + remarcação com público semelhante	INÍCIO, ESPERAR, AÇÃO, ESPERAR (wait_until), AÇÃO, DECISÃO, FIM	SendPushNotification	Tipo de execução: Múltiplo Sequencial

O mecanismo Workflows vem com mais de 60 modelos prontos que cobrem os blocos de construção de cada blueprint. A maioria dos modelos é voltada para o e-commerce, mas a adaptação para viagens é simples: a lógica do modelo de abandono de carrinho se torna um fluxo de trabalho de reserva abandonada, trocando o evento de gatilho para booking_abandoned, adicionando o padrão de verificação de tarifa HttpRequest-and-attribute-update do Blueprint 2 e usando um critério de saída de invalidação de tarifa junto com booking_completed. O modelo de boas-vindas se encaixa diretamente no Blueprint 1. O modelo de gotejamento de geolocalização — já no catálogo — é a base para o fluxo de trabalho durante a viagem do Blueprint 4.

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

Para o caminho de teste imediato, o plano gratuito oferece 200 assinantes, todos os canais (push da web, push do aplicativo, WhatsApp, chat ao vivo) e o mecanismo completo de Workflows desde o primeiro dia. Isso é suficiente para implementar os Blueprints 1 e 2 em 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 isso 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 sai graciosamente em uma alteração de tarifa, o fluxo de trabalho pré-viagem que dispara em departure_date - 7 dias, o fluxo de trabalho de geolocalização durante a viagem que respeita o fuso horário de destino — todos eles têm a mesma forma. Um INÍCIO, alguns ESPERARs, algumas DECISÕES, algumas AÇÕEs, uma SAÍDA. Três gatilhos independentes não podem fazer isso. Um mecanismo de fluxo de trabalho pode. O LTV de reserva repetida se compõe a partir daí.

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