As solicitações de aluguel de carros chegam a qualquer hora do dia. O cliente escreve no WhatsApp e pergunta sobre disponibilidade, datas, preço, seguro, caução e entrega. Para transformar essa conversa em uma reserva, um atendente precisa reunir dezenas de parâmetros, um a um.
Enquanto o atendente está ocupado ou dormindo, o cliente continua procurando. Na maioria das vezes, a reserva fica com a locadora que respondeu primeiro.
Para a YETI, construímos não apenas um chatbot, mas um sistema de vendas com IA feito sob medida. Ele recebe as mensagens do WhatsApp, entende o pedido, conduz o cliente pelo processo de reserva, busca dados atualizados dos veículos, verifica documentos e monta um negócio pronto no Kommo CRM.
Nesse sistema, o WhatsApp é apenas a interface de conversa com o cliente. O trabalho de verdade acontece dentro de uma arquitetura de servidor que gerencia agentes de IA, dados, filas de mensagens e o estado de cada negócio.
O projeto em números
Dentro da solução:
- 3 agentes de IA especializados;
- 12 etapas de reserva;
- WhatsApp Business como canal principal;
- Kommo CRM como sistema de trabalho dos atendentes;
- um banco de dados separado de carros e tarifas;
- preenchimento automático do cartão do negócio;
- reconhecimento de documentos por visão computacional;
- suporte a russo e inglês;
- armazenamento do contexto da conversa;
- filas de mensagens recebidas;
- proteção contra o processamento paralelo de um mesmo negócio;
- proteção contra o envio de respostas duplicadas;
- a nossa própria aplicação de servidor.
A primeira versão funcional foi construída no n8n. Depois que a lógica foi validada em conversas reais, todo o sistema foi transferido para uma aplicação independente em Node.js.
Por que um chatbot comum não bastava
De fora, alugar um carro pode parecer simples:
Mas esse pedido não é suficiente para oferecer um carro específico e calcular as condições do aluguel.
O atendente precisa descobrir:
- a cidade do aluguel;
- a data de início;
- a duração do aluguel;
- a categoria de carro preferida;
- um modelo adequado;
- o tipo de seguro;
- as condições de caução;
- serviços adicionais;
- como o carro será retirado;
- os dados de contato;
- os documentos necessários.
E o cliente raramente envia tudo em uma única mensagem. Uma conversa típica é assim:
Preciso de um carro
Por uma semana
Algo barato
Em Dubai
A partir da próxima segunda
Para uma pessoa, isso é um único pensamento dividido em várias mensagens. Para um sistema de software, são vários eventos separados que podem chegar — e começar a ser processados — ao mesmo tempo.
Por isso, a tarefa não era só ensinar a IA a responder perguntas. Era preciso construir um processo controlado no qual o sistema:
- entende o que o cliente já disse;
- determina a etapa atual da reserva;
- pede apenas os dados que faltam;
- busca a informação atualizada no banco de dados;
- grava o resultado no CRM;
- passa a conversa a um atendente no momento certo.
Como o sistema funciona
O fluxo geral é assim:
A esse processo também está conectado um agente de IA separado, que analisa as fotos dos documentos.
Quando o cliente escreve no WhatsApp, a mensagem não vai direto para o modelo de linguagem. Primeiro o sistema identifica o cliente e o negócio, salva a mensagem, verifica se o negócio já está sendo processado e espera para ver se o cliente envia uma continuação.
Depois disso, várias mensagens curtas podem ser reunidas em um único pedido. Por exemplo:
Tem carro?
Por uma semana
Um barato
O sistema entrega à IA não quatro eventos independentes, mas um pensamento montado:
Em seguida, o administrador de IA analisa o histórico da conversa, os dados do negócio e a etapa atual da reserva. Ele descobre o que já é conhecido, o que falta e qual ação executar a seguir. Pode ser:
- pedir a cidade;
- confirmar a data;
- salvar a duração do aluguel;
- buscar carros no banco de dados;
- mostrar opções;
- solicitar um documento;
- preencher um campo no Kommo;
- passar a conversa a um atendente.
Depois disso, um apresentador de IA separado formula a resposta ao cliente.
Por que três agentes de IA trabalham por dentro
No começo, dá para tentar fazer um único modelo cuidar de tudo de uma vez: entender o cliente, gerenciar as etapas, procurar carros, tomar decisões, escrever respostas e verificar documentos.
Em conversas longas, essa abordagem fica imprevisível. O modelo pode ignorar dados que já tem, fazer várias perguntas ao mesmo tempo, oferecer um carro que não existe ou mudar as condições do aluguel por conta própria.
Por isso dividimos o sistema em três papéis estreitos.
1. O administrador de IA
É o agente que controla o sistema. Ele não fala diretamente com o cliente. Sua função é decidir a próxima ação.
O administrador recebe:
- a nova mensagem;
- o histórico da conversa;
- os dados do cartão do negócio no Kommo;
- a etapa atual da reserva;
- os parâmetros já preenchidos;
- as ações disponíveis no sistema.
Após a análise, ele retorna uma decisão estruturada:
- qual campo salvar;
- qual etapa está definida agora;
- se há dados suficientes para buscar um carro;
- se é preciso consultar o banco de dados;
- se é preciso verificar um documento;
- qual pergunta fazer;
- se é hora de passar o negócio a um atendente.
O administrador não pode inventar preços, modelos ou condições. Ele obtém os dados comerciais apenas do banco de dados.
2. O apresentador de IA
É o único agente que escreve para o cliente. Ele pega a decisão pronta do administrador e a transforma em uma mensagem curta e natural no idioma do cliente.
Por exemplo, o administrador decide:
O apresentador formula:
A principal restrição do apresentador é uma pergunta por mensagem. Ele não entrega ao cliente um formulário de oito itens nem sobrecarrega a conversa. O processo parece uma conversa normal com um atendente.
3. O agente de IA de checagem de documentos
Esse agente entra em ação quando o cliente envia a foto de um documento. Ele analisa a imagem e determina:
- se o arquivo é realmente um documento;
- qual é o tipo de documento;
- se a foto está legível;
- se áreas importantes ficaram cortadas;
- se é possível continuar o atendimento.
O sistema aceita passaporte, Emirates ID ou carteira de motorista. Um documento adequado já basta para continuar.
A IA não toma a decisão jurídica sobre se o cliente pode alugar. Ela apenas descarta imagens claramente inadequadas e pede uma nova foto se o documento não puder ser lido. A decisão final fica com a equipe da locadora.
As 12 etapas da reserva
A conversa é construída em torno de um estado formal do negócio. O sistema sempre sabe em que etapa o cliente está e quais dados já foram coletados. O processo tem 12 etapas:
- Definição da cidade, data de início e duração do aluguel.
- Escolha da categoria de carro.
- Busca dos carros disponíveis.
- Escolha de um modelo específico.
- Escolha do seguro.
- Escolha das condições de caução.
- Escolha de serviços adicionais.
- Entrega ou retirada.
- Confirmação das condições finais.
- Coleta e verificação de documentos.
- Confirmação dos dados de contato.
- Passagem do negócio a um atendente e desligamento da IA.
As etapas não significam que o bot faz mecanicamente 12 perguntas seguidas. O cliente pode escrever logo de cara:
O sistema vai extrair dessa mensagem a cidade, a categoria, a data e a duração. Esses dados são salvos, e a IA não vai perguntá-los de novo.
Condições rígidas entre as etapas
Algumas etapas não podem ser puladas. Por exemplo, o sistema não deve mostrar carros enquanto não souber:
- a cidade;
- a data de início;
- a duração do aluguel;
- a categoria de carro.
Sem esses parâmetros, não dá para verificar a disponibilidade nem definir o preço corretamente. Por isso, antes de consultar o banco de dados, o sistema verifica os campos obrigatórios. Se algum estiver faltando, a IA continua coletando dados.
Esse mecanismo impede o modelo de "ajudar o cliente" com uma resposta inventada. A IA não decide quais carros existem. Ela decide quais dados pedir, e obtém a lista de carros de uma fonte da verdade separada.
De onde a IA obtém carros e preços
As informações da frota ficam armazenadas separadamente do modelo de linguagem. No banco de dados estão:
- modelos de carros;
- categorias;
- cidades;
- tarifas;
- restrições;
- opções disponíveis;
- condições adicionais.
Quando os parâmetros obrigatórios estão reunidos, o administrador de IA chama uma função de busca no servidor. A função retorna apenas os carros que correspondem ao pedido do cliente. Depois, o apresentador monta uma oferta clara.
Como os dados chegam ao Kommo
O Kommo não é apenas onde a conversa fica armazenada. Ao longo da conversa, o sistema atualiza o cartão do negócio:
- cidade;
- data de início do aluguel;
- duração;
- categoria escolhida;
- carro escolhido;
- seguro;
- caução;
- serviços adicionais;
- forma de retirada;
- status dos documentos;
- idioma do cliente;
- etapa atual da reserva.
Quando a IA passa o negócio a um atendente, ele não precisa reler toda a conversa e copiar os dados na mão. Ele recebe um cartão estruturado, com os parâmetros já coletados. A conversa permanece no Kommo, então o atendente pode conferir o contexto e continuar de onde parou.
O problema de engenharia que o cliente não vê
A parte mais difícil de projetos assim não é redigir as respostas. Os principais problemas surgem em torno de eventos paralelos, persistência de estado e sincronização de vários sistemas.
O cliente envia várias mensagens seguidas
Uma pessoa pode enviar quatro mensagens em cinco segundos. Se você acionar a IA em cada uma delas, o sistema gera várias respostas em paralelo.
Por isso adicionamos uma janela de agregação. Depois de uma mensagem recebida, o sistema faz uma pausa curta. Se novas mensagens chegam nesse intervalo, elas são reunidas e processadas juntas.
Um mesmo negócio não pode ser processado em paralelo
Enquanto o sistema está montando uma resposta, o cliente pode enviar outra mensagem. Sem um bloqueio, dois processos leem o mesmo estado do negócio ao mesmo tempo e começam a alterá-lo. O resultado pode ser:
- duas respostas;
- ações duplicadas;
- valores de campo conflitantes;
- a etapa de reserva errada.
Para evitar isso, o negócio fica bloqueado durante o processamento. A qualquer momento, apenas um processo lida com um determinado negócio. Novos eventos esperam na fila.
WhatsApp e CRM precisam permanecer sincronizados
Uma mensagem passa por vários sistemas: WhatsApp, o canal, o Kommo, a aplicação de servidor, o modelo de IA e o banco de dados. Qualquer evento pode ser entregue duas vezes ou com atraso. Por isso o sistema guarda os identificadores dos eventos já processados e, antes de enviar, verifica se aquela resposta já foi produzida.
O estado não pode ficar só no histórico da conversa
O histórico das mensagens importa, mas por si só não é um estado confiável do negócio. Por isso são armazenados separadamente:
- a etapa atual;
- os parâmetros coletados;
- o carro escolhido;
- as opções mostradas antes;
- o idioma do cliente;
- o estado da passagem ao atendente;
- o resultado da checagem de documento.
A IA recebe essa estrutura junto com o histórico, em vez de reconstruir todo o processo do zero a cada mensagem.
Primeira versão: um início rápido no n8n
Construímos a primeira versão do sistema no n8n. Para prototipar, foi a escolha certa. O n8n permitiu conectar o Kommo rapidamente, receber mensagens, chamar a IA, testar prompts, trabalhar com o banco de carros, verificar documentos e iniciar as primeiras conversas reais.
Assim testamos não uma apresentação nem um conceito abstrato, mas o processo real em atendimentos ao vivo. À medida que o projeto crescia, o diagrama chegou a cerca de cem nós. Nesse ponto surgiram os limites.
Complexidade das mudanças
Um pequeno ajuste podia tocar vários ramos do processo. Antes de cada alteração, era preciso verificar se ela não quebraria a lógica vizinha.
Filas e bloqueios
Um construtor visual lida bem com integrações sequenciais, mas gerencia com mais dificuldade mensagens paralelas, bloqueios e reentrega de eventos. A confiabilidade tinha que ser sustentada com construções alternativas.
Depuração
Quando um processo tem dezenas de ramos e cerca de cem nós, encontrar a causa de um erro leva cada vez mais tempo. É preciso descobrir qual ramo rodou, quais dados estavam em cada nó, se um segundo processo começou, onde o estado mudou e por que uma resposta específica foi enviada.
Manutenção
O sistema já atendia clientes reais. Isso significava que ele precisava não só ser desenvolvido, mas também atualizado com segurança. Em determinado momento, o custo de manter o processo visual ficou maior que o de mover a lógica para código.
O n8n cumpriu seu papel: permitiu validar a hipótese do produto rapidamente. Mas o sistema de produção tinha superado o formato de protótipo.
Migração para a nossa própria aplicação
Depois que a lógica de negócio foi validada, movemos o sistema para uma aplicação de servidor independente em Node.js. O comportamento para o cliente permaneceu o mesmo:
- o mesmo WhatsApp;
- o mesmo estilo de conversa;
- as mesmas etapas;
- os mesmos carros;
- a mesma passagem ao atendente.
O que mudou foi a arquitetura interna. A lógica foi dividida em módulos independentes:
- recebimento de eventos;
- agregação de mensagens;
- a fila de processamento;
- bloqueio de negócios;
- armazenamento de estado;
- o administrador de IA;
- o apresentador de IA;
- a checagem de documentos;
- a integração com o Kommo;
- o trabalho com o banco de carros;
- o envio de mensagens;
- o registro de erros.
Depois da migração, cada parte pode ser alterada e testada de forma isolada.
Stack tecnológica
A versão final usa:
- Node.js — o ambiente de servidor;
- Express — recebimento dos eventos de entrada e a camada HTTP;
- Redis — filas, estado temporário e bloqueios;
- PostgreSQL — carros, tarifas e dados persistentes;
- Kommo API — negócios, campos, etapas e a conversa;
- WhatsApp Business API — o canal de comunicação;
- OpenAI GPT — análise da conversa e geração de respostas;
- visão computacional (um modelo de visão) — análise das imagens de documentos;
- Docker — implantação dos serviços;
- Git — controle de versão do código e dos prompts.
Os prompts dos agentes de IA ficam armazenados separadamente da lógica principal da aplicação e também têm versionamento. Isso permite ver qual regra estava em vigor em um dado momento, comparar versões e reverter uma alteração se necessário.
Como o projeto evoluiu
O projeto passou por várias etapas sucessivas.
- Versão 1. Prova de conceito. Uma IA básica responde mensagens e coleta parte dos dados.
- Versão 2. Um processo formal de reserva. A conversa é dividida em etapas. Surgem o estado do negócio e as condições obrigatórias de transição.
- Versão 3. Integração com a frota real. A IA deixa de oferecer carros por conta própria e passa a obtê-los do banco de dados.
- Versão 4. Três agentes especializados. A tomada de decisão, a redação das respostas e a análise de documentos são separadas.
- Versão 5. Trabalho com filas de mensagens. São adicionados a agregação de mensagens, os bloqueios de negócios e a proteção contra duplicatas.
- Versão 6. Checagem de documentos. O sistema começa a analisar as imagens enviadas e a pedir uma nova foto quando necessário.
- Versão 7. Migração do n8n. Depois de validado o processo, toda a lógica de produção foi movida para a nossa própria aplicação.
- Versão 8. Operação gerenciada. São adicionados registro de logs, versionamento de prompts, controle de erros e a possibilidade de alterar componentes individuais com segurança.
O que tivemos que refazer
O projeto não surgiu pronto na sua forma final. Alguns componentes reescrevemos várias vezes. Em particular, nós:
- mudamos o modelo de armazenamento do estado da conversa;
- refizemos o tratamento de várias mensagens seguidas;
- reforçamos a proteção contra respostas paralelas;
- dividimos as funções de uma IA entre vários agentes;
- mudamos as regras de transição entre etapas;
- refizemos o mecanismo de seleção de carros;
- movemos a lógica do n8n para o Node.js;
- tiramos os prompts do processo para arquivos separados e versionados.
Essa é uma parte normal da construção de um sistema de IA que trabalha com clientes reais, não em uma demonstração. O difícil aqui não é obter do modelo uma resposta bonita. O difícil é tornar o comportamento do sistema robusto diante de dados incompletos, eventos repetidos, mensagens fora do padrão e conversas paralelas.
O que o sistema não faz
A YETI não substitui todo o time de vendas. O sistema deliberadamente não faz algumas coisas.
- Não toma a decisão final sobre o cliente. A IA pode verificar o tipo e a qualidade da foto de um documento, mas não decide a elegibilidade jurídica para alugar.
- Não recebe pagamento nem entrega o carro. Pagamento, contrato, confirmação final e entrega do carro ficam com uma pessoa.
- Não inventa disponibilidade nem preços. Todos os dados comerciais vêm do banco de dados.
- Não continua a conversa depois da passagem. Quando o negócio está pronto, a IA entra em modo fechado. A partir daí, um humano assume.
- Não tenta resolver qualquer disputa sozinha. Situações fora do padrão e questões delicadas vão para uma pessoa.
O objetivo do sistema não é remover as pessoas do processo. É tirar delas a parte rotineira e entregar ao atendente um cliente no momento em que uma decisão humana é realmente necessária.
O que mudou para o negócio
Depois da implantação, a forma de tratar uma solicitação ficou padronizada.
- As solicitações são atendidas 24 horas por dia. A primeira resposta não depende mais da escala dos atendentes. Solicitações da madrugada entram direto na qualificação.
- Os dados são coletados de forma consistente. O sistema não esquece de perguntar a data, a duração, a cidade, o seguro ou a caução.
- O atendente recebe um negócio preparado. Os principais parâmetros do aluguel já estão preenchidos no cartão do Kommo. O funcionário entra não na primeira mensagem, mas em uma solicitação já formada.
- Os carros são oferecidos a partir da disponibilidade real. A IA não se baseia no próprio conhecimento de modelos e preços — a oferta é montada com os dados da frota.
- A conversa não depende do idioma do atendente. O sistema responde em russo ou inglês conforme o idioma do cliente.
- A arquitetura pode escalar. Novas etapas, idiomas, regras, tarifas e integrações são adicionados como componentes separados, não como extensões de um único script gigante.
Não publicamos números de crescimento de conversão ou de faturamento: esses dados pertencem ao cliente. O resultado verificável do projeto é um sistema de produção em funcionamento que recebe solicitações 24 horas por dia, conduz o cliente por um processo formal, sincroniza com o CRM e entrega ao atendente um negócio estruturado.
O que é preciso para criar um sistema assim
Para colocar IA em um processo de vendas real, conectar um modelo de linguagem ao WhatsApp não basta. É preciso projetar todo o sistema em ordem.
1. Formalizar o processo de negócio
Descreva o que o atendente deve receber, quais dados são obrigatórios, em que ordem coletá-los, quais etapas não podem ser puladas e em que ponto um humano entra.
2. Definir as fontes da verdade
A IA não pode inventar preços, disponibilidade, tarifas, descontos, prazos ou condições comerciais. Cada tipo de dado precisa de uma fonte controlada.
3. Separar decisões da redação
O agente que conduz o processo e o agente que fala com o cliente fazem trabalhos diferentes. Separá-los torna o sistema mais previsível.
4. Armazenar um estado formal
Só o histórico da conversa não basta. A etapa do negócio e os parâmetros coletados precisam ser armazenados separadamente.
5. Projetar o processamento paralelo
Antes de lançar, decida como reunir mensagens curtas, como bloquear um negócio, como tratar eventos repetidos, como evitar respostas duplicadas e como recuperar o processo após um erro.
6. Conectar o CRM como parte do processo
A IA não deve apenas responder, mas também alterar o sistema de trabalho: preencher campos, mover etapas, salvar resultados, passar a responsabilidade e se desligar depois de entregar a uma pessoa.
7. Começar com um lançamento controlado
Ligue o sistema primeiro em uma parte limitada das conversas, analise os atendimentos reais e ajuste as regras.
Conclusão
Para a YETI, construímos um sistema de vendas com IA feito sob medida para uma locadora. Ele reúne WhatsApp, Kommo CRM, o banco de carros, três agentes de IA, visão computacional, filas de mensagens e lógica de servidor.
O cliente vê uma conversa comum no WhatsApp. Mas por trás dessa conversa roda um sistema que entende o pedido, gerencia as etapas da reserva, guarda o estado do negócio, busca carros atualizados, verifica documentos, preenche o CRM, se protege contra eventos paralelos e repetidos e entrega uma solicitação pronta a um atendente.
É por isso que é mais correto chamar o resultado de sistema de vendas com IA, e não de bot. O bot aqui é só a parte visível. O valor de verdade está na arquitetura que transforma a conversa livre do cliente em um processo de negócio gerenciado.