IA para Hotelaria: Agente de Guest Journey

Como pode a inteligência artificial acompanhar o hóspede antes da chegada ao hotel?

Um agente orientado a eventos começa quando a reserva é confirmada, não quando o hóspede pergunta. Envia o welcome, responde por email às dúvidas de preparação da viagem, encaminha para um portal de pré-check-in quando são precisos dados estruturados, apresenta serviços adicionais no contexto da conversa e, depois do check-out, pede e organiza o feedback.

Uma reserva não é o fim do processo comercial. É o início de uma relação.

Muitos hotéis concentram o processo digital em dois momentos — reserva e check-in. Entre um e outro podem passar dias, semanas ou meses, e é tempo que quase sempre fica em silêncio.

Nesse intervalo o hóspede tem perguntas concretas: a que horas pode chegar, se há estacionamento, se se pode preparar um transfer do aeroporto, se há bons restaurantes perto, se pode fazer early check-in, se pode adiantar os dados do check-in. Quase todas se repetem — e quase todas são, ao mesmo tempo, uma oportunidade comercial e uma oportunidade de melhorar a experiência.

A diferença deste agente é que ele começa a conversa

Um chatbot espera que alguém abra a janela e pergunte. Aqui é a reserva confirmada que desencadeia a interação: o evento chega à aplicação, o AWS Lambda carrega o contexto daquela reserva e daquele hotel, e o agente prepara um email de boas-vindas concreto — nome, datas, unidade, número de hóspedes — que diz ao cliente que pode responder àquele email para o que precisar.

A partir daí o email deixa de ser um canal de notificações e passa a ser a interface da conversa. «Chegamos ao aeroporto por volta das 19h, qual é a melhor forma de chegar ao hotel?» «Viajamos com duas crianças, o que recomenda fazer na zona?» O hóspede não instala aplicação nenhuma, não volta ao site e não recomeça uma conversa do zero: responde.

A fase da viagem é, ela própria, contexto

É esta a parte que distingue um agente de guest journey de um assistente que responde a perguntas. A mesma pergunta feita três semanas antes ou dois dias antes da chegada não merece a mesma resposta.

Três semanas antes, o assunto é preparar a viagem. Dois dias antes, é o pré-check-in, a hora prevista de chegada, o transfer e as últimas instruções. Durante a estadia, são serviços e destino. Depois do check-out, é feedback. O agente usa a fase como parte do contexto, e por isso o que é útil comunicar muda sozinho ao longo do tempo — sem campanhas separadas nem listas de envio a decidir por ele.

E cada mensagem não é tratada como se fosse a primeira. Quando o hóspede escreve apenas «sim, queríamos o transfer», isso só faz sentido dentro da conversa anterior — a reserva, as datas, o que já foi perguntado e o que já foi pedido fazem parte do que o agente considera antes de responder.

Upselling contextual é o contrário de uma campanha

Um email promocional enviado a todos os hóspedes não sabe nada sobre a intenção de cada um. Uma conversa sabe, porque o cliente acabou de a explicar.

Quem escreve «o nosso voo chega muito cedo, podemos deixar as malas?» está a dizer que talvez lhe interesse um early check-in, se o hotel o tiver. Quem menciona que vai celebrar um aniversário de casamento está a abrir a porta a outra coisa. O agente compreende o contexto antes de apresentar seja o que for — e a regra de negócio do hotel decide se há alguma coisa a apresentar. O objetivo é mais relevância, não mais mensagens comerciais.

O mesmo vale para o cross-selling: «como chegamos do aeroporto?» pode tornar relevante um transfer; «queremos jantar perto do hotel» pode tornar relevante o restaurante da casa. A pergunta de serviço e a oportunidade comercial passam a ser a mesma conversa.

Recomendar não é listar as vinte melhores coisas para fazer

«Só temos uma tarde livre, o que recomenda?» «Estamos com crianças pequenas.» «Vai chover, o que podemos fazer?» Estas perguntas não têm resposta numa página estática de atrações, porque dependem inteiramente de contexto — a localização do hotel, a duração da estadia, com quem se viaja, o que já se disse preferir.

Para muitos hóspedes o hotel é também o ponto de partida para descobrir o destino, e essa camada — restaurantes, museus, praias, atividades, transportes, sugestões locais — pode ser adaptada à zona concreta de cada unidade em vez de ser genérica.

Nem tudo deve ser conversa: o pré-check-in é um portal

Cada interface serve para uma coisa, e forçar tudo por um chat é um erro comum. O email é bom para conversa, perguntas, sugestões, acompanhamento e para o que se prolonga por semanas. Um portal é melhor para formulários estruturados, documentos, seleção de opções e ações que exigem confirmação.

Por isso o email do agente pode incluir uma ligação personalizada para um portal de pré-check-in, onde o hóspede fornece os dados antes da chegada: email → portal → dados estruturados → Lambda → validação → preparação da chegada. Os dois canais completam-se em vez de competirem.

O modelo escreve. O Lambda decide quando e com o quê.

O agente não é um modelo de linguagem a enviar emails. O AWS Lambda recebe ou identifica a reserva, determina em que fase da estadia o hóspede está, carrega o contexto adequado, processa as respostas que chegam por email, identifica a intenção, chama o modelo, estrutura os dados da conversa, cria as ligações para o pré-check-in, executa as regras do fluxo, prepara as comunicações seguintes e pede o feedback no fim.

A divisão é a mesma que aplicamos noutros projetos: o modelo compreende e produz linguagem; o software coordena o processo e guarda as regras. Um modelo genérico sabe muito sobre Lisboa ou o Algarve, mas não sabe os horários daquele hotel, os tipos de quarto, as políticas ou os serviços — e é o conhecimento autorizado da unidade que responde por essas coisas, não o que o modelo julga saber sobre hotéis.

Depois do check-out, o feedback deixa de ser um número de 1 a 5

Um questionário tradicional obriga o hóspede a traduzir a experiência em escalas: quarto 1 a 5, limpeza 1 a 5, pequeno-almoço 1 a 5. Perde-se exatamente a parte que interessa — o porquê.

Um comentário como «gostámos muito da localização e da equipa, mas o quarto era um pouco ruidoso durante a noite» pode ser estruturado em sentimento geral positivo, aspetos positivos (localização, equipa), aspeto negativo (ruído) e área relacionada (quarto, conforto). Ao longo do tempo, isso permite ver temas recorrentes — pequeno-almoço, limpeza, ruído, check-in, estacionamento — em volumes que ninguém leria à mão. A decisão sobre o que fazer com essa informação continua a ser da equipa do hotel.

A hospitalidade é humana e continua a sê-lo

O agente cobre o que é repetitivo e o que acontece fora de horas — o hóspede pode responder ao email às duas da manhã, estar noutro fuso, preparar a viagem ao domingo. Numa indústria global, boa parte da relação acontece a milhares de quilómetros e semanas antes de alguém pôr o pé na receção.

Mas a hospitalidade não é uma tarefa que se automatize. As situações complexas, as exceções, a resolução de problemas, o atendimento presencial e as decisões comerciais continuam a ser das pessoas. O que muda é quanto tempo lhes sobra para isso, depois de a repetição sair do caminho.