Do chat ao contrato: a reserva temporária, o pagamento e a reserva no seu painel
O erro mais caro no aluguer não é um cancelamento: é vender duas vezes a mesma unidade. Um cancelamento custa faturação. Uma venda dupla custa faturação, um telefonema de desculpas, alguma reputação e, quase sempre, um upgrade grátis. Por isso a parte mais crítica do caminho do chat até à reserva são os quinze minutos entre escolher e pagar.
Este artigo abre esses quinze minutos: o que acontece no sistema quando o cliente diz «fico com esse», o que acontece se o pagamento falhar e porque é que a reserva aparece no seu painel como um contrato normal e não como registo de um canal à parte.
Primeiro a decisão: comparação e detalhe
Os clientes escolhem normalmente entre três opções. O momento da decisão não é o ecrã onde os cartões estão listados, mas aquele em que preço, capacidade, entrega e cancelamento ficam lado a lado. Cada número ali tem uma fonte: a taxa de entrega vem da tarifa, o prazo de cancelamento vem da política de cancelamento.
Tomada a decisão, o cliente desce ao detalhe: características, fotos e total. Mostrar a caução dentro do total importa, porque no aluguer quase todas as surpresas no pagamento são a caução.
Quinze minutos: a reserva temporária
Assim que o cliente diz «reserve», a unidade é bloqueada. Esse bloqueio não é uma declaração de intenções mas uma restrição ao nível da base de dados: a mesma unidade não pode receber um segundo bloqueio para o mesmo intervalo de datas. Não importa se quem pede é o assistente ou alguém no painel; ambos esbarram na mesma restrição.
A distinção parece técnica, mas a consequência é totalmente operacional. A abordagem «dois sistemas avisam-se» fica exposta à venda dupla em cada instante em que o aviso pode atrasar. Com um único bloqueio não há atraso: o segundo pedido não passa enquanto o primeiro não terminar.
Pagamento e 3-D Secure
No passo do pagamento o cliente confirma nome, contacto e morada de entrega, e depois paga com cartão. Os dados do cartão não são guardados; a verificação é feita no banco através do 3-D Secure. A contagem decrescente permanece no ecrã até ao fim — o cliente sabe quanto tempo tem, e só isso baixa o abandono.
Se o pagamento falhar, o bloqueio não é cancelado: mantém-se até expirar. O cliente pode corrigir o cartão e tentar de novo. Se o tempo acabar, a unidade é libertada automaticamente e volta a aparecer na pesquisa. Não fica nenhum estado intermédio a exigir intervenção manual.
Confirmação: o contrato no seu painel
Assim que o pagamento é aprovado, o bloqueio torna-se reserva e aparece no seu painel como contrato. O canal fica registado — pode analisar que reservas vieram do assistente — mas o fluxo é o mesmo de sempre: mesmos documentos, mesma entrega, mesma faturação.
Que a sua equipa não tenha nada de novo para aprender é uma escolha deliberada. Um canal novo costuma significar um ecrã novo e um hábito novo; duas semanas depois, esse ecrã deixa de ser visto. Quando a reserva cai no sítio do costume, esse risco desaparece.
O lado do cliente, depois da reserva
O cliente vê as suas reservas e pesquisas guardadas na sua conta. A pesquisa guardada é um pormenor pequeno mas eficaz: guardada a pesquisa «insuflável para 20 em Garland», o cliente é avisado quando é acrescentado um produto compatível ou quando um cancelamento liberta uma data.
A tradução operacional é esta: os cancelamentos deixam de ser capacidade morta. Hoje um cancelamento deixa quase sempre apenas um buraco no calendário. Uma pesquisa guardada leva esse buraco a alguém que já procurava aquela data.
O remédio para a venda dupla não é dois sistemas avisarem-se, é haver um único bloqueio.
Lista de verificação curta
O lado do cancelamento e do reembolso
A segunda metade de um fluxo de reserva é o cancelamento e, na maioria dos sistemas, é a parte mais desarrumada. A regra é simples: valem as condições de cancelamento que o cliente viu no momento da reserva. Se a tabela comparativa dizia «48 h», alterar a política depois não mexe nessa reserva. Uma reserva leva consigo uma fotografia das suas próprias condições.
O valor do reembolso é calculado a partir dessa mesma fotografia: que linhas são devolvidas, quando a caução é libertada, se a taxa de entrega está incluída. Como as respostas ficam fixadas no momento da reserva, não há discussão depois — e essa discussão é uma das maiores rubricas de apoio ao cliente no aluguer.
Uma data cancelada volta à pesquisa de imediato. No mesmo instante, os clientes que tinham guardado essa data são avisados. Assim, em vez de deixar um buraco no calendário, um cancelamento tem a hipótese de gerar procura nova.
O que este fluxo pede do seu lado é pouco, e provavelmente quase tudo já está feito:
- O calendário tem de ser o único lugar de registo — as reservas por telefone também entram no painel.
- A sua política de cancelamento tem de estar definida; o cliente vê-a na tabela comparativa.
- A taxa e a zona de entrega têm de estar escritas na tarifa.
- A caução tem de estar definida ao nível do produto ou da categoria.
- O seu fornecedor de pagamentos tem de ter o 3-D Secure ativo.
Com estes cinco pontos, uma reserva vinda do chat difere de uma reserva feita por telefone num único aspeto: ninguém teve de atender o telefone.
RentGPTA pesquisa de aluguer que responde em frases, não em filtrosExplorar o recurso