Preciso da API oficial do WhatsApp para esses fluxos?

Sim. Lembrete e cobrança são mensagens iniciadas pela empresa fora da janela de 24 horas, o que só é possível com template aprovado na plataforma oficial. Ferramentas não oficiais que automatizam o aplicativo violam os termos e o número acaba bloqueado.

Como evitar que dois clientes marquem o mesmo horário?

Com bloqueio temporário do horário no momento em que o bot oferece as opções, gravado em transação no banco com restrição de unicidade. Sem esse lock, duas conversas simultâneas leem a mesma disponibilidade e as duas confirmam.

O bot pode dar baixa no pagamento sozinho?

Pode, quando a confirmação vem do webhook do gateway e não da palavra do cliente. Pagamento por Pix e cartão gera evento assíncrono confiável; comprovante enviado em foto pelo cliente exige conferência humana.

Bot de WhatsApp que agenda, confirma e cobra

Um bot de WhatsApp que agenda, confirma e cobra não é um chatbot: são três fluxos independentes ligados ao mesmo registro de compromisso, cada um com sua integração e seu jeito próprio de quebrar. Quem trata os três como "um robô de atendimento" descobre o problema no dia em que dois clientes marcam o mesmo horário.

Fluxo 1: agendamento com disponibilidade real

O erro clássico é o bot oferecer horários de uma lista fixa e alguém conferir na agenda depois. Isso não é agendamento, é formulário. O fluxo que se sustenta tem cinco passos:

Consulta de disponibilidade ao vivo na fonte da verdade da agenda (Google Calendar, agenda interna do sistema, agenda do profissional). Não em cópia, não em planilha.
Bloqueio temporário do horário assim que o bot mostra as opções: um registro com status reservado e expiração de 5 a 10 minutos.
Confirmação do cliente, que converte a reserva em compromisso definitivo.
Gravação no calendário, guardando o identificador do evento externo do lado do sistema, para conseguir atualizar e cancelar depois.
Expiração automática da reserva quando o cliente some, devolvendo o horário para a disponibilidade.

Os detalhes que doem em produção:

Fuso e horário de verão. Guarde tudo em UTC e converta na exibição usando o fuso do estabelecimento, nunca o do servidor. Agenda gravada em horário local vira bagunça em qualquer troca de infraestrutura.
Duração e intervalo. Um atendimento de 50 minutos com 10 de intervalo não é um bloco de 60. Modele duração, buffer antes e buffer depois como campos separados.
Conflito externo. O profissional marca algo direto no Google Calendar. O sistema precisa reagir a isso, por notificação de mudança do calendário ou sincronização periódica, senão vende horário ocupado.
Bloqueios recorrentes. Almoço, folga, feriado, escala. Sem isso o bot agenda no domingo de manhã.

Fluxo 2: confirmação e lembrete que liberam a agenda

Lembrete só vale a pena se a resposta do cliente mudar alguma coisa no sistema. Mandar "não esqueça do seu horário" sem tratar a resposta é gasto de mensagem.

O desenho usual são dois disparos: D-1 (véspera, em horário comercial) e D-2h (duas horas antes). Ambos partem da empresa fora da janela de 24 horas de conversa, então exigem template aprovado na plataforma oficial do WhatsApp. Depois que o cliente responde, abre a janela e o bot pode conversar livremente.

As três respostas que precisam existir:

Confirmo: marca o compromisso como confirmado e para os lembretes seguintes.
Remarcar: devolve o cliente para o fluxo 1, já com o horário antigo em reserva até a nova escolha ser fechada.
Cancelar: libera o horário na hora, avisa o profissional e, se houver fila de espera, dispara oferta para o próximo.

A liberação automática é o que transforma lembrete em receita. Sem ela, o horário cancelado às 8h da manhã continua bloqueado até alguém abrir a agenda ao meio-dia.

Fluxo 3: cobrança e baixa automática

O fluxo de pagamento tem duas metades: enviar a forma de pagar e reconhecer que pagou. A segunda é a que dá trabalho.

O envio é simples: link de pagamento do gateway ou Pix copia e cola gerado por cobrança individual, com identificador do compromisso amarrado à transação. Nunca envie uma chave Pix genérica com valor solto, porque a conciliação vira trabalho manual.

O reconhecimento vem do webhook do gateway, não do cliente. Quando chega o evento de pagamento aprovado, o sistema baixa a cobrança, marca o compromisso como pago e para a régua. Essa regra de parada é obrigatória: cliente que já pagou e continua recebendo cobrança é a reclamação mais garantida do projeto.

Dois cuidados técnicos:

Idempotência. Gateways reenviam webhook quando não recebem resposta 200 rápido. Guarde o identificador do evento e ignore repetições, senão a mesma cobrança é baixada duas vezes e o relatório financeiro fica errado.
Validação de origem. Confira a assinatura do webhook. Endpoint público de pagamento sem verificação de assinatura aceita qualquer POST forjado.

Tabela dos três fluxos

Fluxo	Gatilho	Integração necessária	Ponto de falha típico
Agendamento	Cliente pede horário	Agenda (Google Calendar ou interna) + banco com lock	Dupla marcação por conversas simultâneas
Reserva temporária	Bot ofereceu opções	Banco com expiração de reserva	Reserva que nunca expira e trava a agenda
Confirmação D-1	Job diário	Template aprovado + agenda	Disparo em feriado ou fora de horário
Lembrete D-2h	Job por compromisso	Template aprovado	Fuso errado manda lembrete na madrugada
Cancelamento	Resposta do cliente	Agenda + fila de espera	Horário não volta para disponibilidade
Cobrança	Compromisso confirmado	Gateway de pagamento	Cobrança enviada a quem já pagou
Baixa	Webhook do gateway	Gateway + financeiro	Webhook duplicado gera baixa em dobro

Os pontos de falha que ninguém prevê no orçamento

Corrida entre duas conversas. Duas pessoas pedem o mesmo horário no mesmo segundo. Ambas leem "disponível", ambas confirmam. A correção é transação com restrição de unicidade na tabela de compromissos (profissional mais início de horário) ou lock no registro, não uma verificação extra em código de aplicação. Se o segundo insert falha, o bot volta com "esse horário acabou de ser preenchido, tenho estes outros" em vez de agendar por cima.

Cliente que responde três dias depois. Ele recebe o lembrete de terça e responde "confirmo" na sexta. O bot precisa checar o estado atual do compromisso antes de agir sobre uma mensagem antiga. Toda resposta deve carregar o identificador do compromisso no contexto e ser validada contra o estado presente, nunca contra o estado de quando a mensagem foi enviada.

Mensagem em rajada. O cliente manda "oi", "quero marcar", "para quinta" em três mensagens seguidas. Sem uma janela de agrupamento de poucos segundos antes de processar, o bot responde três vezes e se atrapalha sozinho.

Número não é identidade. O mesmo aparelho atende a família inteira. Antes de mostrar histórico, valor devido ou dado pessoal, peça um segundo dado de conferência.

Falha silenciosa do envio. O template pode ser rejeitado, o número pode estar sem WhatsApp, o gateway pode cair. Todo disparo precisa de status registrado e alerta quando a taxa de falha sobe. Sistemas de agendamento costumam parar de mandar lembrete semanas antes de alguém perceber.

O que exige revisão humana

Nem tudo deve ser automático, e a linha é bem clara:

Desconto, cortesia e isenção de taxa de cancelamento. Decisão comercial, com aprovação de gente.
Comprovante enviado em foto. O cliente manda print do Pix. Trate como pedido de conferência, não como pagamento confirmado.
Reagendamento fora da política (terceira remarcação, cliente com histórico de falta).
Cliente irritado. Detecte o tom e transfira. Bot insistindo em cobrança com alguém reclamando piora tudo.
Contestação de cobrança. Abre chamado, não responde com script.

Em projetos assim, a parte de conversa costuma ser a mais fácil. O trabalho de verdade está na máquina de estados do compromisso, no lock da agenda e na conciliação com o financeiro. É isso que a Retti Tech verifica primeiro quando um bot de agendamento chega para manutenção: quase sempre o problema não está no texto que o robô manda, e sim no estado que ele deixou de gravar.