Catálogo e busca de produtos para agentes

Quando um agente de vendas dá resultado ruim, a primeira hipótese levantada é sempre o modelo — trocar por um mais caro, mexer no prompt, ajustar a temperatura. Na maioria das vezes o problema não está lá. Está no catálogo: o agente não encontra o produto, encontra o errado, ou encontra o certo e não tem o atributo que responderia à pergunta do cliente.

Um agente não navega pela sua loja. Ele não vê a foto, não lê o banner, não entende a árvore de categorias que faz sentido para um humano. Ele consulta dados. O que não estiver em campo estruturado, para ele, não existe.

O cliente não usa as suas palavras

Este é o ponto de partida, e ele é constrangedoramente simples.

O cadastro diz “moletom canguru flanelado”. O cliente escreve “blusa de frio com bolso”. A busca por palavra-chave não cruza os dois, o agente recebe zero resultados e responde, com toda a honestidade, que não tem. A venda morre ali, e ninguém fica sabendo — não existe relatório de “pergunta que o agente não soube responder” ligado por padrão em lugar nenhum.

Em conversa esse descasamento é muito pior que na barra de busca do site, por dois motivos. Primeiro, porque conversando as pessoas escrevem por finalidade, não por categoria: “algo pra correr na chuva”, “presente pra minha mãe que cozinha muito”, “um que caiba embaixo da pia”. Segundo, porque na barra de busca o cliente tenta de novo com outra palavra; na conversa, ele aceita o “não temos” e vai embora.

Busca semântica resolve boa parte disso. Em vez de comparar texto literal, ela compara significado: produto e pergunta viram vetores, e a proximidade entre eles é o que ordena o resultado. É o que aproxima “blusa de frio” de “moletom” sem ninguém ter cadastrado esse sinônimo à mão.

Ela não é mágica, e vale saber onde falha: busca semântica erra em números, códigos e referências exatas. “Filtro 30015-A” ou “iPhone 14 Pro Max, não o 14 Pro” precisam de correspondência literal. Operação boa usa as duas, com a busca literal tendo prioridade quando há código no meio da frase.

O que precisa estar em campo, não em texto corrido

A descrição do produto em HTML colado do fornecedor é o pior formato possível para um agente. A informação até está lá, misturada com tabela de layout, aviso de garantia e três parágrafos de marketing. Extrair medida de dentro disso é possível e é caro, e o resultado é instável.

O que muda o jogo é ter os atributos em campo próprio:

• Variação como entidade real. Tamanho, cor e voltagem com estoque, preço e código próprios. Se a variação não existe como dado, o agente não consegue dizer “tem no M, esgotou no G” — que é exatamente a resposta que fecha a compra.
• Medidas e tabela de tamanho. É a pergunta número um de moda e calçado, e ela some do cadastro na maioria das lojas.
• Compatibilidade. Serve neste modelo, encaixa nesta máquina, funciona com esta versão. Em autopeças, informática e acessórios, é a informação que decide.
• Especificação física. Material, composição, voltagem, peso, dimensão. Essa lista é o que responde metade das dúvidas antes da compra.
• Peso e dimensões de envio. Sem isso o agente não calcula frete, e frete é objeção de carrinho abandonado.
• Prazo de reposição do que está esgotado. “Volta em duas semanas” segura o cliente; “não temos” o entrega para o concorrente.

Uma pista útil de onde começar: a lista acima deveria sair do histórico de atendimento, não de um padrão genérico. As perguntas que a sua equipe mais responde à mão são, literalmente, a lista de atributos que faltam no seu catálogo. Essa é a mesma lógica que vale para dados de produto que agentes conseguem ler.

Preço e estoque: índice encontra, fonte confirma

Aqui mora o erro mais caro desse tipo de projeto, e ele é de arquitetura.

O agente precisa de um índice para encontrar candidatos rápido — consultar a plataforma a cada termo digitado não escala e derruba a API. Mas índice é cópia, e cópia envelhece. Entre a última sincronização e a conversa de agora cabe uma promoção que acabou, um lote que esgotou e um preço que mudou.

A regra que evita o problema é simples de enunciar e é esquecida com frequência: o índice serve para encontrar; a fonte oficial serve para afirmar. Antes de dizer ao cliente que tem estoque, que custa tanto ou que chega em tanto tempo, o agente consulta a variação na plataforma. É uma chamada a mais por conversa, e ela compra a diferença entre uma venda e um ticket de reclamação.

Para manter o índice razoavelmente fresco, webhook de produto e de estoque vale mais que sincronização periódica. A Multiagents integra com iSET, Shopify, Nuvem Shop, Tray, WBUY, Loja Integrada e Bagy justamente por esse caminho — evento de mudança em vez de varredura de catálogo inteiro, que é o que sobrecarrega a loja em horário de pico.

O agente não pode inventar produto

Modelo de linguagem preenche lacuna. É o que ele faz de melhor e é exatamente o comportamento que você não quer num catálogo.

Sem restrição explícita, o agente descreve um produto que “deveria existir”, inventa um código plausível, estima uma medida. Em conversa isso soa perfeito — e termina em pedido de item inexistente ou em cliente que recebe o que não comprou.

Os portões que resolvem são chatos e funcionam:

• O agente só cita produto que voltou de uma consulta ao catálogo, com código real.
• Especificação não encontrada é declarada como não encontrada. “Não tenho a medida exata aqui, posso verificar com a equipe” é uma resposta melhor que um número inventado.
• Link de produto sempre montado a partir do dado retornado, nunca escrito pelo modelo.
• Quando a busca volta vazia, o comportamento certo é oferecer alternativa próxima e registrar a pergunta — esse log é a matéria-prima para corrigir o catálogo.

Esse último item costuma ser o mais subestimado. O relatório de buscas sem resultado é o mapa do que a sua loja perde por não ter cadastrado.

O teste que vale mais que qualquer relatório

Antes de ligar qualquer coisa para o cliente final, faça o seguinte: pegue vinte perguntas reais do histórico de atendimento, com as palavras que o cliente usou, e rode contra a busca do agente.

Não são vinte perguntas bonitas escritas por você. São as mal escritas, com erro de digitação, sem acento, com o nome popular do produto, com “aquele que vocês postaram no Instagram ontem”. É assim que o cliente escreve.

O resultado costuma ser desconfortável e é extremamente útil: cada erro aponta para um atributo que falta, um sinônimo que não existe ou uma variação mal cadastrada. Corrigir esses vinte casos rende mais do que qualquer ajuste de prompt.

E vale priorizar: não é preciso limpar dez mil itens antes de começar. Os produtos que concentram a maior parte das vendas e das perguntas são poucos, e são eles que aparecem nas conversas. A cauda longa pode esperar.

Por que isso é pré-requisito, e não polimento

Todo o resto da operação agêntica se apoia no catálogo. O agente que atende dúvida de produto no WhatsApp consulta o mesmo índice. A recuperação de carrinho abandonado precisa saber se a variação abandonada ainda existe antes de mandar mensagem. E, quando agentes compradores passarem a consultar lojas em nome de consumidores, quem vai ser encontrado é quem tem dado estruturado — não quem tem a página mais bonita.

Catálogo legível não é uma tarefa de SEO nem um capricho de quem gosta de planilha. É a condição para o agente vender. Sem isso, o que você tem é um modelo caro escrevendo bem sobre coisas que ele não conhece — e isso, em e-commerce agêntico, é o jeito mais rápido de concluir que a tecnologia não funciona.