Código da Porta 72h Antes: o Timing Que Custa Avaliações

A reserva que ninguém esquece

Sexta de Carnaval, 22h47. Hóspede te liga (você pegou o telefone só porque já são 11 chamadas perdidas):

"Tô na porta com a família, escuro, sem o código. Você mandou?"

Você abre o painel: sim, mandou. Há três dias. Domingo às 9h, exatamente quando a régua do Stays mandou disparar "72 horas antes do check-in". A mensagem está lá no histórico, perfeita, com todas as informações. E completamente invisível: enterrada sob 247 mensagens de Carnaval, grupos de família, e um vídeo do sobrinho que o pai mandou pra todo mundo.

O hóspede vai dormir num hotel próximo. A avaliação chega na segunda: 3 estrelas em comunicação. O comentário público é educado, mas a mensagem privada pro suporte do Airbnb não é.

Por que velocidade ≠ timing

A literatura de hospitalidade fala muito de velocidade de resposta, e com razão: tanto Airbnb quanto Booking.com transformam isso em métrica que afeta visibilidade.

• O Airbnb publica em seu Help Center que para se qualificar como Superhost o anfitrião precisa manter taxa de resposta de pelo menos 90% e responder novas consultas em até 24 horas.
• O Booking.com, no painel do parceiro, exibe "Tempo de resposta" como um dos indicadores que afetam o desempenho da propriedade nas buscas.

Mas velocidade resolve conversa — quando o hóspede pergunta algo, você responde rápido. Não resolve disparo: quando você precisa proativamente entregar uma informação no momento útil dela.

Disparo é problema de timing, e timing tem três variáveis que nenhuma régua simples por offset captura:

Régua "72h antes do check-in" não vê nenhuma dessas variáveis. É um cron job vestido de automação.

Os 3 modos em que o offset fixo falha

1. A mensagem chega cedo demais e some no rolo. Hóspede tem ~80 mensagens/dia em alta temporada (estimativa de uso médio reportada por pesquisas como a Panorama Mobile Time / Opinion Box sobre uso de WhatsApp no Brasil). Sua mensagem de checkin entregue 72h antes compete com tudo isso e perde.

2. A mensagem chega tarde demais. O oposto: anfitrião configurou "1h antes do checkin" mas o hóspede dirigiu 6h e parou só uma vez. Chega no destino sem ter recebido o código porque a régua dispara em função da hora oficial de checkin, não da hora real de chegada.

3. A mensagem chega para o hóspede errado. A régua dispara para a reserva, não para o status. Hóspede ainda não completou o cadastro, mas recebe o código mesmo assim — porque o gatilho é "tempo até o checkin", não "está tudo em ordem para receber o código".

O que muda quando a automação responde ao contexto

Uma régua contextual pergunta antes de disparar:

1. Que horas o hóspede vai chegar de verdade? Se ele informou check-in às 22h, a mensagem do código sai às 19h, não às 9h.
2. O cadastro está completo? Se faltam documentos, o disparo é da cobrança do cadastro — não do código.
3. Em que canal ele responde? Hóspede que sempre respondeu no WhatsApp recebe lá; hóspede do Airbnb sem WhatsApp informado recebe na plataforma.
4. Em que idioma? Detectado pela conversa, não pela bandeirinha do país de origem.

A IA do InnSync lê esses quatro sinais a cada disparo e decide o conteúdo no momento do envio. O resultado é menos mensagem, mais relevante.

A rede de segurança: quando a mensagem se perde mesmo assim

Mesmo a melhor automação não controla a caixa de entrada do hóspede. Por isso, todo fluxo de check-in precisa de uma rede de segurança — um lugar canônico onde o hóspede sabe que pode achar a informação, sem depender de rolar conversa.

É o que faz o portal do hóspede: link único enviado na confirmação da reserva, com endereço, código (revelado apenas em proximidade do check-in), wifi, regras da casa, contato. Se a mensagem do WhatsApp se perdeu, o hóspede abre o portal e encontra. Se ele nem ligou — abriu o link sozinho — você economizou a chamada.

Como o InnSync resolve

O InnSync combina três camadas que substituem a régua simples:

Camada 1 — Disparo contextual: a IA dispara mensagens em função de hora de check-in real, status do cadastro, canal preferido, e fuso. Não há "régua de 72h" hardcoded; há condições que precisam estar todas verdadeiras.

Camada 2 — IA de atendimento contextual: quando o hóspede pergunta no WhatsApp ou no Airbnb "qual o código?", a IA consulta os dados da reserva no Stays.net, confirma que está em janela de check-in, e responde com o código correto da unidade dele. Sem template, sem template errado, sem confusão de unidade.

Camada 3 — Portal como fallback: o hóspede tem sempre um link onde a verdade canônica vive. Se a mensagem se perdeu, ele acha. Se você atualizou o código pós-troca de fechadura, o portal já mostra o novo.

Erros comuns na configuração de réguas

1. Achar que "antes é mais seguro". Mensagem mais cedo = mais tempo pra perder = mais pessoas que chegam sem ela. Antecedência não é defesa, é diluição.

2. Não considerar fuso. Hóspede internacional faz check-in às 14h (horário Brasília), que é 04h no horário dele de origem. Régua que dispara "10h antes" manda mensagem 4h da manhã para ele. Quase ninguém checa o WhatsApp às 4h da manhã.

3. Disparar código antes do cadastro estar completo. Falha de segurança disfarçada de eficiência. O código existe pra dar acesso a quem está autorizado — autorizar antes de verificar inverte a ordem.

4. Confiar só no WhatsApp. Hóspede pode estar sem internet móvel, sem roaming, com WhatsApp travado. Sem rede de segurança (portal), você fica refém do canal.

5. Não medir o que aconteceu. Quem leu? Quem chegou sem ter lido? Sem dado, você está otimizando no escuro.

Como começar essa semana

1. Auditoria rápida: nas últimas 10 reservas, em quantas o hóspede perguntou "qual o código?" pelo WhatsApp ou no Airbnb depois que a mensagem automática já tinha sido disparada? Esse é seu indicador de "régua não funciona".
2. Levante os fusos das suas últimas 30 reservas. Quantos hóspedes vinham de fora do Brasil? A régua atual considera isso?
3. Implemente uma rede de segurança simples — um link, um documento, qualquer coisa que viva fora do WhatsApp e que o hóspede possa abrir a qualquer hora.
4. Migre uma régua para contextual — comece pela do código da porta. Em vez de "X horas antes do check-in", configure "no dia do check-in e cadastro completo e dentro de janela útil".
5. Meça em 30 dias: caiu o número de "qual o código?" tardio? Subiu a nota de comunicação? Esse é o ROI da régua bem feita.

A régua certa não é uma régua. É um conjunto de condições que a automação verifica a cada disparo. Quando o contexto pede, ela manda; quando não pede, ela espera. É a diferença entre automação e agendamento.

Fontes

• Airbnb — Critérios de Superhost: Como funciona o programa Superhost, Help Center oficial. Taxa de resposta ≥90%, resposta a novas consultas em até 24h.
• Booking.com Partner Hub: partner.booking.com — indicadores de tempo de resposta no painel do parceiro.
• Panorama Mobile Time / Opinion Box: Pesquisas sobre uso de WhatsApp no Brasil, referência sobre uso médio do app por usuário brasileiro.
• Stays.net — Documentação da API de reservas: developers.stays.net, origem dos dados de hora de check-in usados pela automação contextual.
• Lei Geral de Proteção de Dados (LGPD): Lei 13.709/2018 — exigência de minimização e controle de acesso a dados (Art. 6).

Leia também

• Como Automatizar Respostas de Hóspedes com IA — o lado da conversa, complementar a este post sobre disparo
• Documentos do Hóspede: Por que Pedir por WhatsApp Não Funciona — quando a régua não dispara o código porque o cadastro está incompleto, o que vem antes
• InnSync vs Automações do Stays.net — comparativo das réguas nativas vs. contextuais
• Conheça o portal do hóspede — a rede de segurança quando a mensagem se perde
• Calculadora de economia — quanto o tempo gasto resolvendo "qual o código?" custa por mês