“Pronto, ficou para terça às 15h.”
Essa frase parece o fim do trabalho.
Pode ser só o começo do problema.
O cliente pediu um horário pelo WhatsApp. O agente entendeu “terça às 15h”, respondeu com confiança e seguiu a conversa. Só que a integração expirou antes de gravar. Ou gravou duas vezes porque tentou de novo. Ou marcou no fuso errado. Ou remarcou o compromisso de outra pessoa com nome parecido.
A conversa ficou ótima. A agenda, criativa.
Agendamento com IA não é extrair data e hora. É manter o mesmo estado entre conversa, disponibilidade, agenda, confirmação e mudança posterior.
Resposta curta
Antes de deixar um agente marcar sozinho, ele precisa fazer sete coisas:
- identificar quem está pedindo e qual serviço precisa;
- entender duração, local, profissional e fuso quando importam;
- consultar a disponibilidade no sistema que realmente manda;
- pedir confirmação antes de executar quando houver ambiguidade;
- gravar uma vez e verificar o resultado;
- devolver confirmação com identificador e instruções claras;
- remarcar, cancelar e recuperar falha sem perder o vínculo com o agendamento original.
Se uma dessas etapas não existe, o agente ainda pode ajudar. Mas deveria coletar dados e passar para uma pessoa, não prometer que marcou.
Data e hora são a parte fácil
“Quero amanhã depois do almoço” já exige contexto. Amanhã em qual fuso? Depois do almoço começa às 13h ou às 15h? O serviço dura 20 minutos ou duas horas? Pode ser com qualquer profissional? É presencial, telefone ou vídeo?
A conversa real fica mais interessante:
- “Pode ser no mesmo horário da última vez?”
- “Quero mudar só o retorno, não a primeira consulta.”
- “Cancela o de quarta e coloca sexta.”
- “Marca para mim e para minha esposa.”
- “Se não tiver com ela, pode ser com outra pessoa.”
- “Confirmado?”
O agente não precisa adivinhar bem. Precisa saber o que ainda falta para executar com segurança.
O estado mínimo que precisa existir
Antes da chamada à agenda, monte um registro simples:
| Campo | Pergunta operacional | Exemplo |
|---|---|---|
| pessoa | quem está agendando e para quem? | titular / dependente / convidado |
| intenção | criar, consultar, confirmar, remarcar ou cancelar? | remarcar |
| serviço | o que será feito e quanto dura? | avaliação, 45 min |
| recurso | com quem ou em qual local? | qualquer profissional habilitado |
| janela | qual data, horário e fuso são aceitáveis? | terça, 14h–17h, Brasília |
| vínculo | qual agendamento anterior será alterado? | identificador ou combinação confirmada |
| estado | solicitado, disponível, aguardando confirmação, gravado, falhou, cancelado? | aguardando confirmação |
| evidência | o que prova a última ação? | ID da reserva + resposta da agenda |
Esse registro pode começar numa planilha ou num objeto simples na automação. O nome da tecnologia importa menos que uma regra: o agente não anuncia estado que o sistema ainda não confirmou.
Cartão de estado do agendamento
Use esta ficha para revisar 20 conversas. Inclua casos felizes e casos feitos para quebrar o fluxo.
Separou consulta, criação, confirmação, remarcação e cancelamento sem tratar toda menção a horário como nova reserva.
Confirmou pessoa, serviço e vínculo antes de mexer em uma reserva existente. Nome parecido não é identificador.
Leu a agenda responsável pelo horário, respeitou duração, recurso, bloqueio, intervalo e fuso.
Guardou um identificador, evitou repetir a criação depois de timeout e verificou o resultado antes de responder.
Data, hora, fuso, local, serviço, instrução e código da reserva bateram com a agenda.
Informou a limitação, preservou o pedido, abriu tarefa ou chamou humano com contexto em vez de inventar confirmação.
O erro mais caro costuma ser a certeza antes da gravação
A sequência correta é:
pedido → disponibilidade → confirmação do cliente → gravação → verificação → resposta final
Uma sequência perigosa é:
pedido → resposta final → tentativa de gravação
Se a agenda falhar depois da frase “está marcado”, a operação criou uma promessa que talvez ninguém veja até o cliente aparecer.
A documentação do Google Calendar ajuda a enxergar um detalhe técnico com consequência operacional. Ao criar um evento, a aplicação pode definir o próprio identificador. Isso permite manter o registro local ligado ao evento e evita criar duplicidade se a operação tiver funcionado no calendário, mas a resposta se perder no caminho.
Não é preciso usar Google Calendar para aplicar a disciplina. A regra vale para qualquer agenda: cada tentativa precisa de uma chave estável, e uma repetição precisa verificar antes de criar de novo.
Remarcar não é cancelar e criar sem memória
Às vezes o sistema realmente implementa uma remarcação cancelando um item e criando outro. Tudo bem. O problema é perder o vínculo.
Uma remarcação precisa guardar:
- qual reserva era a original;
- quem pediu a mudança;
- qual motivo foi informado;
- qual horário substituiu o anterior;
- se a nova reserva depende de aprovação;
- quais notificações foram enviadas;
- qual estado ficou valendo no fim.
A API da Cal.com, por exemplo, trata criar, remarcar e cancelar como operações diferentes. Na remarcação, a resposta pode preservar os identificadores da reserva anterior e da nova. No cancelamento, existe motivo e há regra específica para recorrência.
De novo: não é argumento para escolher Cal.com. É evidência de que “mudar horário” possui mais estado do que a conversa deixa parecer.
Se houver recorrência, pergunte qual ocorrência muda
“Cancela a aula de terça” pode significar:
- apenas a próxima terça;
- todas as terças;
- esta e as seguintes;
- a série inteira;
- o horário de uma pessoa, sem mexer nas outras.
A documentação do Google Calendar separa série recorrente e instâncias. A Cal.com também diferencia reservas comuns, recorrentes e subsequentes no cancelamento.
O agente não deveria escolher sozinho quando a frase admite mais de uma leitura. Pergunte. Uma mensagem extra custa menos que cancelar o mês inteiro com eficiência impecável.
O teste de 12 conversas
Antes do go-live, rode esta bateria em ambiente de teste ou numa agenda controlada:
Se quiser preencher, copiar ou baixar a bateria completa, abra o template de teste de agendamento com IA.
| # | Conversa | Resultado esperado |
|---|---|---|
| 1 | “Quero terça às 15h.” | pergunta serviço/pessoa quando necessário, consulta e confirma |
| 2 | “Amanhã depois do almoço.” | resolve data, janela e fuso sem inventar horário |
| 3 | “Pode ser qualquer profissional.” | aplica recurso elegível, não o primeiro nome encontrado |
| 4 | “Marca para mim e para outra pessoa.” | separa participantes ou reservas conforme a regra |
| 5 | “Muda o meu horário de quarta.” | identifica qual reserva será alterada |
| 6 | “Cancela tudo.” | confirma escopo antes de agir |
| 7 | “Só esta terça, não as próximas.” | altera uma ocorrência, preserva a série |
| 8 | dois pedidos idênticos seguidos | não cria duplicidade |
| 9 | timeout depois de gravar | verifica pelo identificador antes de tentar de novo |
| 10 | horário ocupado entre consulta e gravação | oferece novas opções, não promete conflito |
| 11 | agenda indisponível | preserva o pedido e cria saída humana ou retorno |
| 12 | cliente pergunta “está confirmado?” | responde com o estado real, não com intenção |
Para cada teste, guarde conversa, chamada feita, resposta do sistema, estado final e mensagem enviada ao cliente.
Fluxo para não transformar agenda em loteria
Quando a planilha e o link de agenda bastam
Não comece pelo agente se o volume é baixo e o processo ainda muda toda semana.
O caminho simples costuma ser suficiente quando:
- um link de agenda já mostra disponibilidade confiável;
- o cliente consegue criar, remarcar e cancelar sozinho;
- poucas pessoas ou recursos participam;
- a equipe revisa manualmente exceções;
- confirmação e lembrete saem pela própria ferramenta;
- não há regra complexa de elegibilidade, prioridade ou pagamento.
Nesse estágio, o WhatsApp pode só explicar o serviço e entregar o link certo. Menos cinematográfico. Frequentemente mais seguro.
Onde começa a quebrar
A solução simples começa a falhar quando:
- o agente precisa combinar conversa e agenda sem tirar o cliente do canal;
- existem vários serviços, durações, locais, profissionais ou recursos;
- CRM e agenda precisam compartilhar cliente, oportunidade ou caso;
- há pagamento, autorização, elegibilidade ou prioridade antes da reserva;
- remarcação e cancelamento dependem de política;
- a operação precisa evitar duplicidade entre sistemas;
- falha precisa abrir tarefa com SLA e dono;
- QA precisa reconstruir o que o agente entendeu, executou e confirmou.
Aí o problema não é colocar um calendário dentro do chat. É operar uma ação com estado, limite e evidência.
O que fazer agora
Escolha 20 agendamentos recentes. Preencha o cartão e procure três falhas: promessa antes da gravação, mudança sem vínculo e erro sem saída.
Depois rode os 12 testes numa agenda controlada. Se o fluxo falhar, mantenha o agente em coleta ou sugestão. Ele pode organizar o pedido e entregar para uma pessoa até a execução ficar confiável.
Se a dúvida é quanto poder dar à automação, leia IA no atendimento: quando usar, evitar e como medir. Para testar integração fora e outros casos ruins, use O teste da IA não é a demo. É a fila cheia. Se a falha precisa cair numa fila humana, leia Fila de exceções: o trabalho que a IA devolve.
Se o problema principal é agenda, CRM, disponibilidade e integração, MakeITsimple pode fazer sentido. Se existe um agente atendendo cliente, executando ações, pedindo confirmação, passando exceções e gerando evidência para QA, a conversa tende a ser Zild. A rota vem depois do teste; antes dele, a agenda pode estar só concordando educadamente com a conversa.
Se você prefere ver em vídeo
Eu não encontrei um vídeo em português que eu colocaria como resposta principal para este teste. Há demonstrações de agentes marcando o horário feliz. Poucas tentam duplicidade, conflito entre consulta e gravação, remarcação ambígua, recorrência e agenda indisponível.
Um vídeo útil teria que quebrar o fluxo de propósito e mostrar a recuperação. Se bastante gente pedir, o assunto entra na fila de gravação. Não é promessa.