O cliente pede o caminho mais barato mas descreve um problema grande — a IA segue o pedido ou resolve o conflito?
Nem um nem outro. Quando o lead pede o caminho mais barato mas descreve um problema que pede a solução completa, dois sinais empurram pra rotas diferentes no mesmo instante — e o código não resolve isso por ordem de chegada, por recência, nem por "ele pediu primeiro". Existe uma regra de prioridade fixa: quem decide qual oferta o lead recebe é o eixo de intenção de execução — o tamanho real do problema, lido pelos sinais de dor — não o nome da oferta que o próprio lead citou. Pedir o caminho barato nunca rebaixa a oferta certa; no máximo, ajusta o escopo dentro dela.
Esse conflito é a mesma coisa que "o cliente mudou de ideia" ou "não sabe o que quer"?
Não, e a diferença importa pra entender por que precisa de uma regra separada. Quando a IA de atendimento muda de ideia no meio da conversa, o problema é no tempo: a mesma decisão é tomada diferente em turnos diferentes. Quando o cliente não sabe o que quer, o problema é a falta de sinal: a intenção está vazia ou cinzenta, e a saída é uma pergunta de escolha.
Aqui é outra coisa: o lead dá dois sinais fortes ao mesmo tempo, e eles brigam. Ele nomeia a oferta de entrada — "quero o pacote mais simples", "tem algo mais barato?" — e, na mesma mensagem ou duas linhas depois, descreve uma operação grande, com gente envolvida, processo manual, custo que já incomoda. Não falta sinal, nem muda com o tempo: tem sinal de menos (o pedido) competindo com sinal de mais (a dor) no mesmo turno. Resolver isso exige uma regra de prioridade, não uma trava de tempo nem uma pergunta de desambiguação.
Por que não dá pra simplesmente seguir o que o cliente pediu?
Porque "seguir o pedido" parece respeito ao cliente, mas na prática é deixar a ordem de avaliação decidir por você. Se o sistema desse peso de decisão pra oferta que o lead nomeou, o lead de maior valor do funil cairia no caminho mais barato só porque foi a primeira palavra que ele usou pra descrever o que queria — antes mesmo de explicar o tamanho real do problema.
É o inverso do erro mais discutido sobre atendimento automático, que é o robô travando numa pergunta sem fim. Aqui o risco é o oposto: colar na primeira coisa que o lead falou e empurrar ele pro caminho errado — barato demais pra resolver o problema que ele descreveu, que depois volta como reclamação ou frustração alguns meses adiante. Nome em código pra esse sinal: oferta_declarada. Ele prova que o lead está engajado e nomeou algo — isso tem valor, evita que esse lead seja tratado como frio. Mas ele não escolhe a rota. Se escolhesse, o pedido do primeiro turno trancaria a oferta antes mesmo de o agente entender a dor.
Então quem decide, e com que critério?
O eixo de intenção de execução — construído a partir dos sinais de dor concreta, custo já quantificado e quem está envolvido na operação, não do nome que o lead deu à oferta. A prioridade entre os dois eixos que entram em jogo é explícita e fica fora do texto gerado: a temperatura do lead (o quanto ele está pronto a agir agora) decide se o agente avança a proposta agora; o eixo de intenção decide qual oferta faz sentido pra aquele problema. São duas perguntas diferentes, respondidas por duas regras diferentes — nunca a mesma régua.
E existe uma regra extra, pensada exatamente pra esse conflito: pedir o caminho mais barato nunca rebaixa a oferta certa. Se o eixo de intenção aponta pra uma solução mais completa, o pedido de "algo mais simples" não vira um desconto de rota — ele só modula o escopo dentro da oferta que já foi decidida como correta. O lead não é ignorado; ele só não tem o poder de travar o sistema na opção errada só porque foi a palavra que usou primeiro.
Isso não é o agente simplesmente "achando" que a dor é grande e decidindo por conta própria?
Não, e essa é a parte que separa regra de código de intuição de modelo de linguagem. Quais sinais contam como dor concreta, qual peso cada um tem, e o que define o eixo de intenção são critérios escritos antes da conversa acontecer, em configuração — o mesmo tipo de regra determinística que decide se um lead é digno da atenção de um humano. O modelo de linguagem não pesa os dois sinais "na hora" e decide qual pesa mais; ele extrai o que o lead disse, o código aplica a regra de prioridade já definida, e só depois o modelo escreve a resposta dentro da decisão que já saiu pronta.
Uma vez resolvido o conflito, a decisão vira fato fixo da conversa — não é reaberta a cada mensagem nova por capricho. Ela só é revista se aparecer um sinal novo e concreto, avaliado pelo mesmo tipo de regra de código, nunca por um "parece que agora é diferente" do modelo.
Esse invariante — oferta nomeada pelo lead não decide a rota, quem decide é o eixo de intenção — entrou na calibração que reescreveu a configuração do agente da Estefani & Co em 2026-07-10, a mesma rodada que passou por QA de roleplay com cinco personas simuladas e reteste antes de o agente ir pro tráfego pago de verdade. A documentação de desenho do agente registra o risco de forma direta: se a oferta que o lead nomeia no primeiro contato tivesse peso pra escolher a rota, um lead que cita o caminho mais barato mas descreve uma dor grande seria roteado pro caminho errado só por ordem de avaliação — o problema maior tratado com a oferta menor, e o próprio negócio perdendo a chance de vender a solução que realmente resolveria aquele caso. A correção ficou registrada como regra de precedência explícita na configuração: a temperatura do lead decide se o agente avança agora; o eixo de intenção decide qual caminho é o certo; e pedir "algo mais simples" nunca rebaixa esse caminho, só ajusta o tamanho do projeto dentro dele. É regra de config, testável, a mesma que qualquer cliente novo recebe como ponto de partida.
Perguntas frequentes
Se o lead insiste várias vezes que quer o mais barato, em algum momento o agente cede e muda a rota?
Insistir no pedido não é o mesmo que trazer um sinal novo de dor. O que reabre a decisão é um fato novo e concreto sobre o problema — não a repetição do mesmo pedido pela oferta de entrada.
Esse tipo de conflito é raro, ou aparece direto no atendimento comum?
Aparece com frequência, principalmente com quem veio de anúncio: o lead nomeia a oferta que viu no anúncio porque é o que ele sabe pedir, mas descreve, nas mensagens seguintes, uma operação que pede mais do que aquilo.
O lead percebe que o agente "discordou" do pedido dele?
Não da forma de um robô contrariando o cliente. O agente responde com a oferta certa pro problema descrito, explicando por que ela resolve — não ignora o pedido, mostra o caminho que de fato atende.
Isso significa que o agente empurra sempre a oferta mais cara?
Não. O eixo de intenção aponta pra qualquer direção — incluindo pra baixo, quando o problema descrito é pequeno de verdade. A regra não favorece a oferta maior; ela impede que o pedido do lead, isolado, decida a rota sem olhar pro tamanho real do problema.
Quem define o que conta como "dor grande" o suficiente pra pesar nessa decisão?
É configuração do negócio, definida antes da conversa — os sinais de dor, custo e quem está envolvido na operação que valem pra aquele cliente, não um critério inventado pelo modelo durante o atendimento.