Comunicar com os hóspedes a partir da reserva

Escolhe a reserva correta como contexto de conversa

Abre Convidados → Mensagens ou as mensagens de detalhes do convidado. Pesquise por número de reserva, hóspede, datas ou quarto e verifique o painel de contexto antes de escrever.

Somente reservas vinculadas a um hóspede principal podem ser enviadas por mensagem. Corrige um link perdido no registro do hóspede ou da reserva em vez de criar outra pessoa.

Inicia cada conversa a partir da reserva exata. Pesquise por número de reserva, hóspede ou datas de estadia, abre o registro e compara destinatário, chegada, saída, categoria de quarto, estado atual e origem da reserva. O mesmo hóspede pode ter várias estadias passadas ou futuras, e um perfil por si só não identifica a qual chegada, cancelamento ou fatura a mensagem se refere. STRYK, portanto, usa hóspede e reserva juntos. Se o contexto da reserva não estiver claro, pare antes de escrever e resolva o problema no registro de origem. Mantém os detalhes privados dentro da conversa de reserva autorizada e usa uma referência de reserva ou quarto nas notas de entrega, em vez de copiar os dados de contato em outro lugar. A verificação de contexto é concluída quando outro colega consegue identificar o destinatário pretendido e permanecer sem adivinhar o corpo da mensagem.

Entenda o canal a partir da fonte de reserva

As reservas manuais, por telefone, walk-in, e-mail, website e motor de reservas utilizam e-mail, com assunto e formatos simples ou HTML. Verifica primeiro o endereço armazenado.

As reservas de canais e OTA usam uma conversa de canal em texto simples. Não ignore isso com um e-mail separado, ou o histórico de reservas ficará incompleto.

Lê o canal de comunicação da fonte de reserva. Reservas manuais e diretas utilizam email; As reservas de OTA ou de canal usam o canal de reserva como uma conversa em texto simples. O compositor não fornece uma escolha livre de canal porque alterar a rota quebraria o relacionamento entre a origem da reserva e o histórico da mensagem. Confirma o canal exibido e o destinatário disponível antes de selecionar um modelo. O e-mail pode usar texto simples ou HTML aprovado com visualização, enquanto as mensagens do canal permanecem em texto simples e não devem depender de formatação não suportada. Se uma rota de contato diferente for operacionalmente necessária, trata-a como um processo autorizado separadamente e documenta o motivo; não esconda a mudança dentro do compositor. Para reservas no portal, o STRYK envia a mensagem de texto simples através da rota conectada Booking.com ou Airbnb e mantém todas as respostas na mesma conversa de reserva.

Escolhe um modelo por finalidade, canal e idioma

A lista mostra modelos ativos que correspondem ao canal derivado. Escolhe pelo propósito da viagem do convidado e pelo idioma necessário, e não por um nome com som semelhante.

STRYK aplica formato, assunto e corpo. As correções recorrentes pertencem ao modelo central; detalhes pontuais permanecem no rascunho. Evita cópias privadas desatualizadas.

Escolhe um modelo de acordo com um propósito concreto, o canal exibido e o idioma do convidado. Informações de chegada, lembrete de pagamento, dados faltantes e agradecimentos pós-estadia são decisões diferentes e não devem ser combinadas em uma mensagem vaga e universal. Usa apenas um modelo ativo oferecido para o canal derivado. Lê-o antes de se inscrever: verifica a saudação, o tom, os horários do hotel, os links, o texto de cancelamento ou pagamento e a assinatura em relação às práticas atuais do hotel. Um modelo é um ponto de partida revisado, não uma permissão para envio inalterado. Se o idioma do hóspede for diferente do padrão do hotel, seleciona ou escreve uma versão completa nesse idioma; um assunto traduzido com corpo em idiomas mistos não está pronto. Remover parágrafos que não se aplicam a esta estadia e adicionar apenas factos já aprovados na reserva, política ou configurações do hotel.

Revise os espaços reservados no contexto real da reserva

O selecionador expõe valores que podem ser resolvidos no contexto atual do hóspede e da reserva. Lê a visualização resolvida e compara datas, quartos e detalhes de reserva com o painel de contexto.

Espaços reservados não resolvidos são mostrados abaixo da visualização. Corrige os dados de origem ausentes, recarregue e revise novamente; se não estiver disponível por design, remove o token ou reescreva a frase.

Resolve todos os espaços reservados na visualização em relação à reserva atual. Verifica saudação e nome do hóspede, hotel, chegada e saída, categoria ou quarto atribuído, número da reserva, total, valor pendente, política de cancelamento e dados de contato de acordo com a finalidade do modelo. Um token não resolvido, um traço vazio ou um valor implausível é um bloqueador, não um texto cosmético. Corrigir dados de origem ausentes quando deveriam existir; caso contrário, reescreva a frase sem fazer uma promessa. Se nenhum quarto for atribuído, diga a categoria reservada em vez de adivinhar o número do quarto. Se um valor de pagamento for contestado, não o substitua manualmente na mensagem; resolve as finanças primeiro. Os espaços reservados de alias podem ser renderizados para compatibilidade, mas o selecionador deve usar os valores canônicos atuais disponíveis neste contexto de reserva. A visualização final deve conter apenas dados reais e explicáveis.

Lê o conteúdo como anfitrião e revisor

Lê como o hóspede: as duas primeiras frases devem explicar por que o hotel escreve e o que acontece a seguir. Usa horários claros e linguagem cotidiana, não códigos internos.

Em seguida, revise o destinatário, a saudação, o número da reserva, as datas, as solicitações de quarto, as referências de preços, os links, a assinatura e o idioma. HTML precisa de revisão visual; as mensagens do canal permanecem em texto simples e claro.

Lê a mensagem final duas vezes: primeiro como anfitrião e depois como revisor. Como anfitrião, torne óbvia a próxima ação do hóspede, usa uma linguagem respeitosa e inclua apenas informações que ajudem na estadia. Como revisor, verifica os fatos da reserva, datas, valores, declarações de política, links, prazo de resposta, assinatura e privacidade. Uma mensagem deve ter um objetivo principal e uma resposta clara sobre o que o hóspede deve saber ou fazer. Evita jargões internos, culpas, promessas legais que o hotel não pode cumprir e dados sensíveis não necessários para o efeito. Para uma mudança urgente, indica o que mudou, qual estadia foi afetada e onde o hóspede pode responder. Para e-mail HTML, inspeciona a visualização formatada e o texto legível; para mensagens do canal, certifique-se de que o significado sobreviva ao texto simples. Uma mensagem específica e concisa é mais segura do que um modelo longo cheio de cláusulas irrelevantes.

Envia uma vez e comprove o resultado no tópico

Confirma a reserva, envia uma vez e aguarde. Se STRYK mostrar um erro, mantém o rascunho, corrige a causa e não registres o sucesso prematuramente.

Após sucesso, encontre a mensagem no mesmo tópico de reserva e verifique direção, horário, canal, assunto quando aplicável e número de reserva. Se não estiver visível, recarregue antes de tentar novamente.

Envia uma vez e aguarde o resultado real. Um botão desativado, um botão giratório ou uma rede lenta não permitem clicar repetidamente. Em caso de sucesso, reabra a mesma conversa de reserva e verifique exatamente uma entrada de saída com carimbo de data/hora correto, canal, assunto quando aplicável e conteúdo visível. Para e-mail, um resultado de aplicação bem-sucedido e uma entrada no thread provam que STRYK aceitou o envio; as falhas de entrega devem permanecer visíveis através do status ou acompanhamento apropriado. Para uma conversa de canal, confirma se a mensagem de texto simples está no tópico de reserva correto. Se o envio falhar, preserve o rascunho, lê o erro e corrige o destinatário, canal, conteúdo ou conexão na sua origem. Nunca cries uma entrada de sucesso local ou copie a mensagem para outra reserva apenas para fazer com que o histórico pareça completo.

Verifica dois erros comuns com um teste separado. Primeiro caso: o hóspede não possui um endereço de e-mail utilizável numa reserva direta. O resultado correto não é adivinhar o destinatário ou utilizar o endereço de outro hóspede, mas sim o bloqueio visível e o esclarecimento dos dados de contato no perfil do hóspede ou na reserva. Segundo caso: Eles escolheriam um modelo de e-mail para reserva de OTA. O canal e o formato de texto simples derivado pelo sistema devem permanecer visíveis; não copie manualmente a mensagem para um e-mail separado, perdendo a conexão da conversa. Para ambos os ensaios, anota o número da reserva, canal esperado, feedback real e próximo responsável. Dessa forma, a equipe pode lidar não apenas com o envio bem-sucedido, mas também com a parada segura quando os dados de origem ou canal não forem adequados.

Mantém um padrão de mensagens de equipe

Define um modelo responsável por situação recorrente, canal e idioma, com propriedade e revisão regular. Prefere um conjunto pequeno e claro a muitos nomes semelhantes.

O Hotel Nordlicht testa email simples direto, visualização direta de HTML, canal simples OTA, um espaço reservado ausente e um hóspede com duas reservas. Os problemas são corrigidos no nível de origem, modelo ou reserva.

Mantém um padrão de equipe pequena para mensagens recorrentes. Cada modelo aprovado precisa de propósito, canal, idioma, proprietário, data da última revisão e acionador da próxima revisão. Revise após alterações nos horários de check-in, processo de pagamento, política de cancelamento, contato do hotel, links ou jornada do hóspede. Mantém o conteúdo do modelo no catálogo central de back-end e os espaços reservados no sistema central de modelos, em vez de trechos pessoais ou arquivos locais. Experimenta uma conversa real após ativação na demonstração isolada do Hotel Nordlicht, verificando contexto de reserva, valores resolvidos, qualidade editorial e envio único; nunca uses um inquilino de cliente existente como prova de documentação. Retira modelos obsoletos em vez de deixar ativos quase duplicados. O processo é confiável quando um colega consegue entender posteriormente o propósito, destinatário, estadia, canal, conteúdo exato e resultado apenas da conversa de reserva.

Experimenta pelo menos três conversas por mês ou após cada mudança operacional significativa: um e-mail direto, um canal de mensagem de texto simples e um caso em que o envio teve que ser bloqueado. Verifica o contato de reserva correto, o idioma do hóspede, o espaço reservado desbloqueado, a meta clara, a linha de saída única e o fechamento responsável do erro. Não copie conteúdo pessoal em um documento educacional; o controle de qualidade deve registrar apenas a referência e o resultado da reserva necessária. Em caso de erro recorrente, não corrija cada mensagem uma a uma: identifica se é causado por template, dados centrais do hotel, fonte de reserva ou processo da equipe, solicite uma correção e um novo teste.

Regista a data e a pessoa responsável pela revisão ao lado do modelo para que o motivo e o prazo da próxima revisão fiquem claros para todos os colegas.