Contexto
Reunião de 16/04 e grupo de testes do BORDER
Na reunião de alinhamento do dia 16 de abril de 2026, a equipe comercial da Baerlocher compartilhou observações sobre o comportamento do BORDER durante os testes. Para agilizar a comunicação, foi criado o grupo "Projeto Border" no WhatsApp, onde, nos dias 16, 17 e 20 de abril, foram registrados pontos adicionais — incluindo prints de conversas reais com o assistente.
Agradecemos o cuidado e o nível de detalhe nos testes. Ao revisar cada ponto levantado, identificamos que nem tudo é bug: parte dos sintomas observados decorre de decisões de configuração, escopo da sincronização ou definições de regra de negócio que ainda não foram formalmente alinhadas. Este relatório tem como objetivo classificar cada ponto e posicionar claramente como será tratado.
Como classificamos cada ponto
Cinco categorias de tratamento
Bug
Comportamento incorreto do BORDER frente a um cenário esperado. Requer correção no código.
Gap técnico
Funcionalidade parcialmente implementada ou com integração incompleta. Requer fechamento da implementação.
Nova demanda
Requisito que não estava no escopo inicial e surgiu durante o uso. Requer desenvolvimento novo.
Regra de negócio
Política da Baerlocher a ser aplicada no BORDER. Requer definição formal e configuração.
Cadastro SAP
Questão que decorre da qualidade do cadastro no ERP. Tratada no relatório #19.
Resumo dos pontos analisados
21 pontos analisados — 12 levantados pela equipe + 9 identificados na análise interna
A coluna Complexidade indica a dificuldade técnica de implementação (baixa/média/alta) ou N/A quando o item não é desenvolvimento. A coluna Tempo estimado traz a previsão de entrega considerando desenvolvimento assistido por IA, com uma margem adicional de 25% para imprevistos — os itens mais simples tendem a consumir menos tempo que o estimado, e essa folga é reaproveitada para absorver desvios dos mais complexos. Itens que exigem definição prévia do negócio são marcados com Precisa de definição do negócio — o tempo começa a contar após o alinhamento.
| # | Ponto levantado pela equipe | Classificação | Origem | Complexidade | Tempo estimado | Status |
|---|---|---|---|---|---|---|
| 1 | Campos adicionais no pedido: Nº do pedido do cliente + Nº do pedido Baerlocher, Nº do catálogo PN | Nova demanda | Reunião 16/04 | Média | 5–8h Precisa de definição do negócio | Aguarda alinhamento |
| 2 | Dois pedidos no mesmo PDF devem gerar duas linhas separadas no SAP | Regra de negócio | Reunião 16/04 | Alta | 10–15h Precisa de definição do negócio | Aguarda alinhamento |
| 3 | Verificar o grupo do item — exemplo: Lestarflex classificado como revenda e "outros" | Cadastro SAP | Reunião 16/04 | N/A | Sem desenvolvimento — parametrização no BORDER para sincronizar com o SAP Precisa de definição do negócio | Em andamentoVer relatório #19 |
| 4 | Item L1A não foi encontrado apesar de haver histórico (baerolub L 1 A); em outro teste o R531 foi encontrado | Bug | Reunião 16/04 | Média | 2–3h | CorrigidoVer relatório #25 |
| 5 | Informação de redespacho no pedido | Nova demanda | Reunião 16/04 | Média | 5–8h Precisa de definição do negócio | Aguarda alinhamento |
| 6 | Entregas programadas (datas múltiplas) | Nova demanda | Reunião 16/04 | Alta | 10–15h Precisa de definição do negócio | Aguarda alinhamento |
| 7 | Item de revenda deve ser pedido único — não pode ser misturado com itens de outros grupos | Regra de negócio | WhatsApp 16/04 | Média | 4–7h (após #2) Precisa de definição do negócio | Aguarda alinhamento |
| 8 | Cliente com razão social diferente do nome fantasia (LUIS GUSTAVO / ULTRAOIL) não é reconhecido pelo nome fantasia | Gap técnico | WhatsApp 16/04 | Baixa | 1–2h | CorrigidoVer relatório #23 |
| 9 | Quando item está indisponível, o assistente oferece substitutos — "isso não deve acontecer" | Regra de negócio | WhatsApp 17/04 | Baixa | 2–3h Precisa de definição do negócio | Aguarda alinhamento |
| 10A | Matching por fragmento numérico retorna itens não relacionados (pedido CORR PLASTIK — pallet, bisfenol, luminária) | Bug | WhatsApp 20/04 | Média | 2–3h | CorrigidoVer relatório #26 |
| 10B | Reconhecer códigos internos do ERP do cliente e traduzir para os códigos da Baerlocher (pedido CORR PLASTIK — códigos 0141XXXXXX) | Nova demanda | WhatsApp 20/04 | Alta | 8–15h Precisa de definição do negócio | Aguarda alinhamento |
| 11 | Respostas por e-mail não preservam o histórico da thread — cada resposta chega como e-mail novo ao invés de encadear com a mensagem original | Bug | Reunião 16/04 | Baixa | 2–3h | CorrigidoVer relatório #24 |
| 12 | Assistente expunha identificador interno do SAP ao cliente (ex.: "código C20278499000100") ao confirmar a empresa | Bug | Análise interna 23/04 | Baixa | 1–2h | CorrigidoVer relatório #27 |
| 13 | Observações recorrentes do cliente (requisitos de pedidos anteriores) não eram sugeridas proativamente — quando o cliente perguntava, o assistente respondia "não há registros" mesmo existindo | Bug | Análise interna 23/04 | Média | 2–3h | CorrigidoVer relatório #27 |
| 14 | Pergunta de prazo de entrega sempre retornava "sem histórico suficiente" mesmo para itens com centenas de notas fiscais — rotina diária de consolidação estava parada por ciclo de reinício do worker | Bug | Análise interna 23/04 | Média | 3–4h | CorrigidoVer relatório #28 |
| 15 | Empresa extraída de PDF (ex.: "CORR PLASTIK INDUSTRIAL LTDA") não era cruzada com a lista de vínculos do contato; assistente seguia sem validar e só falhava ao criar o pedido, despejando 15 códigos internos ao cliente | Bug | Análise interna 23/04 | Média | 3–4h | CorrigidoVer relatório #29 |
| 16 | Após escalação para atendente, cliente continuava enviando mensagens e ficava sem resposta; assistente silenciava sem sinalizar que a solicitação já tinha sido encaminhada | Bug | Análise interna 23/04 | Baixa | 2–3h | CorrigidoVer relatório #30 |
| 17 | Contato com 15 empresas: assistente cruzou o nome de uma empresa com o identificador técnico de outra, trazendo observações de cliente diferente e quase gravando no pedido errado; também alucinou 3 variantes AVIENT inexistentes | Bug | Análise interna 23/04 | Média | 4–6h | CorrigidoVer relatório #31 |
| 18 | Conversa era fechada automaticamente ao criar pedido; cliente que continuava (segundo pedido, dúvida, agradecimento) caía em conversas novas sem contexto — observado caso real com 3 conversas fragmentadas. Assistente também inventou regra técnica do SAP que não existe | Bug | Análise interna 23/04 | Média | 3–4h | CorrigidoVer relatório #32 |
| 19 | Assistente prometia aplicar alteração parcial nas observações do pedido ("altere só o número") mas não tinha mecanismo — pedido ia para o SAP com o texto antigo. Também: leitura de datas em PDF errada em dois testes do dia | Bug | Análise interna 23/04 | Média | 4–6h | CorrigidoVer relatório #33 |
| 20 | Ao cliente pedir alteração/cancelamento de pedido já criado, assistente pedia o número do pedido antes de informar que a operação não estava disponível — dado coletado em vão | Bug | Análise interna 23/04 | Baixa | 1–2h | CorrigidoVer relatório #34 |
Legenda da coluna Status: Corrigido correção aplicada, com relatório individual detalhando o tratamento — Em andamento tratamento iniciado em paralelo (ver relatório referenciado) — Aguarda alinhamento depende de definição da Baerlocher antes do desenvolvimento.
Análise detalhada
Ponto a ponto — o que foi observado, nosso diagnóstico e próximo passo
1 Campos adicionais no pedido Nova demanda
- O que foi observado
- A equipe solicitou que o pedido passe a registrar: (a) Nº do pedido do cliente + Nº do pedido Baerlocher no campo "Nº de referência" do SAP; (b) Nº do Item no campo "Nº do catálogo do PN" do SAP.
- Nosso diagnóstico
- Hoje o BORDER envia ao SAP apenas os campos mínimos necessários para criar o pedido: cliente, data do documento, data de entrega, itens com código/quantidade/preço, forma de pagamento e observações gerais. Nenhum dos campos solicitados é gravado atualmente — nem o Nº de referência do cliente, nem o Nº de catálogo do PN por item. Para atender, é preciso: (i) o assistente extrair esses dados da conversa ou PDF; (ii) armazenar internamente; (iii) incluir no envio ao SAP. Essa demanda está agrupada com os pontos 5 e 6, que têm a mesma natureza.
- Pontos a alinhar
-
- Os dois números (Nº do pedido do cliente + Nº do pedido Baerlocher) ocupam o mesmo campo "Nº de referência", concatenados? Ou um vai em campo customizado separado?
- Quando o cliente não envia o Nº do pedido dele, o assistente deve perguntar ativamente ou seguir em branco?
- O Nº do catálogo do PN é sempre o código que o cliente usa internamente? Conecta com o ponto 10B (códigos internos do cliente).
- Próximo passo
- Alinhar com a Baerlocher os pontos abertos acima e incluir no backlog como bloco junto com os pontos 5 e 6. O esforço combinado dos três é significativamente menor que tratar isoladamente, pois compartilham o mesmo fluxo (extrair → armazenar → enviar ao SAP).
2 Dois pedidos no mesmo PDF = duas linhas separadas no SAP Regra de negócio
- O que foi observado
- Quando o cliente envia um PDF contendo dois pedidos distintos, a Baerlocher exige que sejam criados dois documentos separados no SAP — e não um pedido único agregando os dois.
- Nosso diagnóstico
- Hoje toda a pilha do BORDER assume "um documento enviado pelo cliente = um pedido". Nenhuma parte do sistema está preparada para processar múltiplos pedidos dentro do mesmo PDF: a leitura do documento, a organização dos itens coletados e a criação do pedido no SAP tratam tudo como um único fluxo. Portanto, além de formalizar a regra, essa demanda requer desenvolvimento.
- O que precisa mudar
- Para atender a regra, três camadas do sistema precisam ser ajustadas:
- Leitura do documento: o assistente precisa reconhecer que um PDF pode conter mais de um pedido e separar os blocos já na extração.
- Organização interna: hoje os itens são acumulados numa única lista; passará a ser uma lista de pedidos, cada um com seus itens, datas, endereços e observações.
- Criação no SAP: em vez de uma chamada única para registrar o pedido, o BORDER fará uma chamada para cada pedido identificado no documento.
- Critério de separação — ponto aberto
- Não é óbvio como o BORDER deve identificar que há dois pedidos em um mesmo PDF. Alguns sinais possíveis: cabeçalhos repetidos ("Pedido 1… / Pedido 2…"), dois números de pedido do cliente, datas de entrega diferentes, endereços de entrega distintos, separadores visuais explícitos. Sem pelo menos um ou dois exemplos reais de documentos da Baerlocher com esse cenário, é impossível definir o critério com segurança.
- Próximo passo
- Solicitar à Baerlocher 2 ou 3 PDFs reais que representem esse caso (com dois pedidos no mesmo documento). A partir dos exemplos definimos: (a) o critério de separação a ser aplicado pelo assistente; (b) o escopo de desenvolvimento das três camadas acima; (c) a estimativa de esforço. Até termos os exemplos, mantemos a demanda como "a definir escopo".
3 Grupo do item no SAP (família Lestar*) Cadastro SAP
- O que foi observado
- A equipe mencionou que o Lestarflex aparece classificado em "revenda e outros", gerando confusão sobre o tratamento correto.
- Nosso diagnóstico
- Fomos investigar e o caso é mais sério do que a fala sugeria. A família Lestar (Lestarflex, Lestarlube, Lestarex) está distribuída em cinco grupos diferentes do SAP:
Além disso, o produto "Lestarflex MED" existe em dois códigos em dois grupos diferentes:Código Nome Grupo atual 120MED ADITIVO P/ PLASTICO LESTARFLEX MED 109 — Produto acabado 130M6 ADITIVO P/ PLASTICO LESTARLUBE M 6 109 — Produto acabado 130M9 ADITIVO P/ PLASTICO LESTARLUBE M 9 109 — Produto acabado 210028 LESTAREX 12 110 — Matéria Prima 160037 ADITIVO PARA PLÁSTICOS LESTARLUBE M11 114 — Revenda 5050/018 LESTARFLEX NEQ 115 — Outros 5050/088 LESTARFLEX MED 115 — Outros 5050/099 LESTARLUBE 280 115 — Outros 5050/081 LESTARLUBE M - 10 115 — Outros 120MEDno grupo 109 e5050/088no grupo 115 — mesmo produto, dois registros, dois grupos. - Por que isso importa
- Nossa hipótese inicial (detalhada no relatório #19) de sincronizar apenas os grupos 104 (Industrialização) e 109 (Produto acabado) deixaria de fora 6 produtos Lestar ativos — produtos que a Baerlocher vende, mas que ficariam invisíveis para o assistente. Isso não é bug do BORDER: é reflexo direto da fragmentação do cadastro no SAP.
- Próximo passo
- Duas frentes: (a) a equipe de cadastro revisa a família Lestar e consolida em um grupo único (provavelmente 109), inativando os duplicados; (b) enquanto isso, o escopo da sincronização do BORDER pode ser ampliado para incluir seletivamente itens específicos dos grupos 114 e 115 que sejam comerciais. Esse trabalho está detalhado no relatório #19, que agora inclui o caso Lestar como evidência da fragmentação.
4 Item L1A não encontrado apesar de histórico Bug
- O que foi observado
- O assistente não encontrou o item "baerolub L 1 A" (escrito também como "L1A"). No mesmo cenário, em outro momento, o item R531 foi encontrado corretamente. A equipe destacou que o cliente tinha histórico de compra do item que não foi reconhecido.
- Nosso diagnóstico
- Investigamos no SAP e identificamos que existem quatro variantes ativas do item "BAEROLUB L 1 A":
O item existe, está ativo e duas variantes estão no grupo Produto acabado (candidato natural a venda). Não é problema de cadastro ausente — é um bug no comportamento da busca do BORDER frente a múltiplas variantes do mesmo item.Código Nome Grupo 720002 BAEROLUB L 1 A 109 — Produto acabado 720006 BAEROLUB L 1 A - VG 109 — Produto acabado 720001 BAEROLUB L 1 A - LIQUIDO 112 — Produto em Processo 720005 BAEROLUB L 1 A - LIQUIDO - VG 112 — Produto em Processo - Regra de negócio a formalizar
- A partir desse caso, fica clara uma regra importante: o histórico de compras do cliente deve ter peso forte e decisivo na busca de itens. Quando o cliente menciona algo ambíguo e há uma variante que ele já comprou antes, a resposta correta é a variante do histórico — não outras similares.
- Como está hoje
- O BORDER já considera o histórico de compras do cliente: ele consulta as notas fiscais anteriores e inclui esses itens no contexto enviado ao assistente. Mas isso entra apenas como "informação para o assistente decidir" — e, quando há várias variantes parecidas, o assistente pode acabar escolhendo outra. Falta uma regra firme para que o histórico seja determinante.
- Próximo passo
- Implementar dois ajustes combinados:
- (A) Reforçar a instrução ao assistente para que, sempre que houver ambiguidade e o cliente tiver histórico, a escolha recaia sobre o item do histórico.
- (B) Verificação pós-resposta: antes de confirmar o item escolhido, validar se existe no histórico do cliente um item mais compatível com a menção original; se existir, substituir pelo do histórico.
5 Informação de redespacho Nova demanda
- O que foi observado
- A equipe solicitou que o pedido registre informações de redespacho — transportadora e/ou endereço alternativo de entrega.
- Nosso diagnóstico
- Funcionalidade não prevista no escopo inicial do BORDER. Atualmente o pedido é criado com o endereço padrão do cadastro do cliente no SAP, sem possibilidade de substituição por endereço alternativo ou de registrar uma transportadora específica. Mesma natureza dos pontos 1 e 6: extrair da conversa/PDF, armazenar, enviar ao SAP.
- Pontos a alinhar
-
- Quais campos do SAP B1 devem receber essas informações? (endereço alternativo pode usar "Address Extension", transportadora pode ser cadastro separado)
- O redespacho é eventual (pedido a pedido) ou pode estar amarrado ao cadastro do cliente como regra fixa?
- O assistente deve confirmar o endereço alternativo antes de criar o pedido, ou usa o que está escrito sem confirmação?
- Próximo passo
- Alinhar os pontos abertos com a equipe comercial/logística e incluir no bloco de desenvolvimento dos pontos 1, 5 e 6.
6 Entregas programadas Nova demanda
- O que foi observado
- Pedidos podem ter datas de entrega programadas — múltiplas datas ou escalonamento de quantidades ao longo do tempo.
- Nosso diagnóstico
- Hoje o BORDER trabalha com uma única data de entrega por pedido (o campo "Data prevista" do SAP). Não há suporte para datas diferentes por item, nem para dividir a entrega de um mesmo item em partes escalonadas no tempo. Essa é uma limitação tanto da extração quanto do modelo interno e da gravação no SAP. Este ponto, diferente dos 1 e 5, pode exigir mudança estrutural maior (no modelo de dados do pedido e na comunicação com o SAP).
- Pontos a alinhar
-
- O cenário mais comum é "datas diferentes por item" (cada item tem sua data) ou "escalonamento do mesmo item" (100 kg em 01/05, 100 kg em 15/05, 100 kg em 01/06)?
- Se for escalonamento, o SAP recebe múltiplas linhas do mesmo item com datas distintas ou usa outro mecanismo?
- Qual a frequência e o perfil dos clientes que usam entrega programada? (isso ajuda a dimensionar prioridade)
- Próximo passo
- Solicitar à Baerlocher 2-3 exemplos reais de pedidos com entregas programadas — precisamos ver na prática como aparecem nos documentos dos clientes e como são registrados hoje no SAP. A partir disso, definimos escopo e estimativa. Incluir no bloco dos pontos 1, 5 e 6, mas com esforço provavelmente maior que os outros dois.
7 Item de revenda = pedido único (sem mistura com outros grupos) Regra de negócio
- O que foi observado
- Quando o pedido contém itens do grupo "Revenda", ele não pode ser consolidado com itens de outros grupos — deve virar um pedido separado.
- Nosso diagnóstico
- Regra fiscal/operacional específica da Baerlocher, ainda não implementada no BORDER. O assistente hoje conhece o grupo de cada item (a informação vem sincronizada do SAP), mas não há nenhuma validação sobre mistura de grupos ao montar o pedido — todos os itens acumulados viram um único documento no SAP, independente do grupo.
- O que precisa mudar
- Antes de criar o pedido no SAP, o BORDER precisará inspecionar os grupos dos itens acumulados. Quando houver mistura de grupos que violem a regra, separar os itens em pedidos distintos e fazer uma chamada de criação por pedido. Vale destacar: essa mudança usa a mesma infraestrutura prevista no ponto 2 (dois pedidos no mesmo PDF) — um documento de origem pode gerar múltiplos pedidos no SAP, seja pela divisão do próprio PDF, seja pela regra de grupos. Implementar os dois pontos em conjunto evita retrabalho.
- Ponto aberto — a regra vale só para revenda?
- A fala da equipe ("quando for item de revenda tem que ser um único pedido, não pode ter outro grupo junto") deixa claro o caso da revenda. Mas precisamos da confirmação da Baerlocher sobre o escopo completo da regra:
- A proibição é apenas "revenda não pode misturar com nada", ou existem outras combinações vetadas (ex: Industrialização e Produto acabado precisam ser separados)?
- Se um pedido tem Revenda + Industrialização + Produto acabado, o BORDER cria 2 ou 3 pedidos no SAP?
- A regra se aplica também quando o pedido tem apenas 1 item de revenda entre vários de outro grupo?
- Próximo passo
- Alinhar com a equipe comercial/fiscal da Baerlocher a definição completa da regra de separação por grupo. Com a matriz definida, implementar em conjunto com o ponto 2 — as duas demandas compartilham a infraestrutura de "múltiplos pedidos gerados a partir de uma mesma conversa".
8 Cliente com razão social diferente do nome fantasia Gap técnico
- O que foi observado
- O cliente LUIS GUSTAVO (razão social) usa o nome fantasia ULTRAOIL. Ao tentar fazer um pedido para "ULTRAOIL", o assistente não reconheceu o cliente — só encontrou após informar a razão social.
- Nosso diagnóstico
- A busca de clientes considera apenas a razão social (campo "Nome do PN"). O SAP armazena o nome fantasia no campo "Nome estrangeiro", que não está sendo incluído nem na sincronização nem na busca. Investigamos o código e confirmamos: o campo existe no banco de dados do BORDER, mas nunca foi efetivamente integrado — ficou uma implementação pela metade. Não é bug no sentido de comportamento errado, é um gap de integração que precisa ser fechado.
- Próximo passo
- Fechar a integração: (1) passar a trazer o "Nome estrangeiro" na sincronização diária; (2) incluir esse campo na busca de clientes; (3) re-sincronizar os parceiros para popular o histórico. Correção pequena e de baixo risco, pode ser priorizada rapidamente.
9 Sugestão automática de substitutos Regra de negócio
- O que foi observado
- No pedido da VALGROUP (item 140ZINCUMSW), quando o assistente detectou que o item estava indisponível em estoque, sugeriu automaticamente dois substitutos (140ZINCUSW/VG e 140ZINCUSW400). A equipe sinalizou: "isso não deve acontecer".
- Nosso diagnóstico
- Fomos investigar o código do BORDER e chegamos a uma conclusão importante: não existe nenhuma regra explícita no assistente que o mande sugerir substitutos. As instruções que o BORDER recebe hoje apenas dizem "se o item está indisponível, informe o cliente e peça aprovação da equipe comercial" — nada sobre oferecer alternativas. O comportamento observado é iniciativa do próprio modelo de linguagem: ao ver no contexto do catálogo vários produtos similares ao solicitado (trazidos automaticamente a partir do histórico de compras e da busca por similaridade), o modelo "decide" ser prestativo e oferecer opções. Trata-se portanto de uma regra de negócio que precisa ser codificada como proibição explícita — e não de uma funcionalidade a ser removida (ela não foi programada).
- Distinção importante
- É essencial separar dois cenários que parecem iguais mas não são:
- Proibido (a formalizar): oferecer produto B quando o cliente pediu A e A está indisponível em estoque.
- Permitido (deve continuar): apresentar candidatos quando a referência do cliente é ambígua (ex: cliente digita "SP30" e há mais de um código que bate — o assistente precisa apresentar as opções para escolha). Isso é desambiguação, não sugestão de substituto.
- Próximo passo
- Três ações combinadas:
- (A) Instruir explicitamente o assistente a nunca oferecer produtos alternativos por conta própria quando um item solicitado estiver indisponível — apenas informar a indisponibilidade e acionar a equipe comercial.
- (B) Ajustar o contexto enviado ao assistente: quando o item pedido foi identificado mas está indisponível, evitar carregar outros produtos similares no mesmo contexto, reduzindo a "tentação" do modelo de oferecê-los.
- (C) Confirmar a regra com a equipe comercial da Baerlocher: a proibição é absoluta, ou existe exceção (por exemplo, quando o cliente explicitamente pergunta "tem algo parecido?")? A resposta define o nível de rigidez da instrução.
10A Matching por fragmento numérico retorna itens não relacionados Bug
- O que foi observado
- No pedido da CORR PLASTIK, quando os códigos enviados não foram encontrados no catálogo, o assistente sugeriu substituições sem sentido. Por exemplo, para o item descrito como LUBRIFICANTES (EXTRUSÃO), foram oferecidos 210085 PEBEFOS FP, 310085 PALLET DE MAD. 135X110 CM e outros itens totalmente não relacionados (bisfenol, luminária, saco para plástico).
- Nosso diagnóstico
- Quando a busca pelo código enviado não encontra match exato, o BORDER cai em uma busca por similaridade (fuzzy) que, em alguns casos, casa os itens por fragmentos numéricos — qualquer código do catálogo que contenha sequências como "085" ou "0041" vira candidato, mesmo sem relação com o produto buscado. O problema é amplificado pelo tamanho do catálogo sincronizado hoje: são 11.088 itens do SAP sem filtro por grupo, misturando insumos, embalagens e materiais de manutenção com produtos comerciais. A redução do catálogo (relatório #19) por si só elimina boa parte desses falsos positivos. Há também um ajuste no algoritmo de busca: quando o código não casa e há descrição disponível, o correto é priorizar a busca pelo nome do produto em vez de retornar candidatos fracos por fragmento numérico.
- Próximo passo
- Duas frentes em paralelo: (a) aplicar o filtro de grupos do relatório #19, reduzindo de 11.088 para cerca de 1.000 itens e eliminando a maior parte do ruído; (b) ajustar o pipeline de busca para preferir a similaridade pelo nome do produto quando o código não tem match forte, em vez de retornar candidatos fracos pelo código.
10B Códigos internos do ERP do cliente Nova demanda
- O que foi observado
- O PDF de pedido da CORR PLASTIK continha códigos no formato 0141000085, 0141000200, 0141000041, 0141000204. Após análise, identificamos que esses são códigos internos do ERP da própria CORR PLASTIK — não são códigos da Baerlocher. Cada cliente do mercado pode ter seu sistema interno de numeração de SKUs e usar esses códigos nos pedidos.
- Nosso diagnóstico
- O escopo original de desenvolvimento do BORDER previu que os pedidos seriam enviados com códigos ou nomes de produto da Baerlocher — não foi combinado que o assistente reconheceria e traduziria códigos internos de cada cliente. Este é um requisito novo, surgido do uso real. Tecnicamente não é um bug: é uma funcionalidade que precisa ser adicionada.
- Próximo passo — alinhamento com a Baerlocher
- A decisão aqui é antes de implementação — é de política comercial. Há três caminhos possíveis:
- Caminho A — Orientar o cliente. Pedir que os clientes sempre enviem pedidos com o código ou nome comercial da Baerlocher. Simples, sem custo de desenvolvimento, mas exige disciplina do cliente.
- Caminho B — Tabela de-para por cliente. Manter uma tabela de correspondência entre o código do cliente e o código da Baerlocher (cadastrada pela equipe comercial ou pelo próprio BORDER ao longo do tempo). Mais flexível, mas exige manutenção contínua.
- Caminho C — Derivação por histórico. Quando um código desconhecido vem em um pedido, o BORDER sugere o equivalente mais provável com base no histórico de compras do cliente e confirma com ele. Automatiza o Caminho B, mas depende de histórico suficiente.
11 Respostas por e-mail não preservam a thread da conversa Bug
- O que foi observado
- Na reunião, a equipe comentou que, quando o BORDER responde a um e-mail, cada resposta chega ao destinatário como se fosse uma mensagem nova — sem referenciar o e-mail original. Isso quebra a visualização em thread nos clientes de e-mail (Gmail, Outlook etc.), dificultando acompanhar o histórico da conversa. Uma das conversas afetadas é o atendimento
a16d7fb4-c474-44b4-9c77-1a3a101def09. - Nosso diagnóstico
- Ao enviar uma resposta pelo Chatwoot, o BORDER informa apenas o texto da mensagem e o tipo (entrada ou saída). Não passa adiante o assunto original do e-mail nem a referência da mensagem à qual está respondendo. Sem esses dois dados, o Chatwoot compõe o e-mail de saída sem os cabeçalhos que os clientes de e-mail usam para agrupar mensagens na mesma thread. Daí o sintoma: o destinatário recebe a resposta como um e-mail isolado, sem continuidade visual do que veio antes.
- O que precisa mudar
- Quando o canal da conversa for e-mail, o BORDER precisa:
- Recuperar o assunto original do primeiro e-mail recebido e prefixar com "Re:" nas respostas subsequentes.
- Recuperar o identificador técnico da última mensagem recebida do cliente (Message-ID do e-mail) e incluir na resposta como referência de encadeamento.
- Passar esses dois campos ao Chatwoot no momento do envio. O Chatwoot já suporta esse mecanismo nativamente — é questão de repassar os dados corretos.
- Próximo passo
- Implementação direta, sem depender de alinhamento com a Baerlocher. Faz parte do bloco de ajustes técnicos que podem ser liberados no próximo ciclo junto com os pontos 4 (busca por histórico), 8 (nome fantasia) e 10A (matching por nome).
O que propomos
Próximos passos organizados por categoria
Correções imediatas (pontos 4, 8, 10A, 11) — Corrigido: os quatro pontos de natureza técnica (3 bugs + 1 gap) foram tratados e publicados. Cada um tem agora um relatório individual detalhando a correção: #23 (Nome Fantasia), #24 (Thread de e-mail), #25 (Prioridade do histórico), #26 (Busca sem falsos positivos).
Regras de negócio (pontos 2, 7, 9) — Aguarda alinhamento: precisam de alinhamento formal antes da implementação. Sugerimos uma reunião curta (30–40 min) com a equipe comercial e fiscal para confirmar: quando dois pedidos em um PDF devem ser separados, quais grupos não podem ser misturados, e se substitutos devem ser desligados ou apenas restringidos.
Novas demandas (pontos 1, 5, 6, 10B) — Aguarda alinhamento: estimar e priorizar junto à Baerlocher. Cada uma envolve tanto a extração da informação da conversa/PDF quanto o mapeamento para campos específicos do SAP (ou, no caso do 10B, a definição do caminho de tradução). Sugerimos tratá-las como um bloco de evolução dedicado, posterior às correções.
Cadastro SAP (ponto 3) — Em andamento: tratado no relatório #19. Aguardamos a revisão da equipe de cadastro da Baerlocher.
Resumo
Situação: A equipe de testes da Baerlocher levantou 12 pontos sobre o comportamento do BORDER em reunião e no grupo do WhatsApp; a análise interna das conversas de teste de 23/04 identificou outros 9 pontos complementares (4 na manhã e 4 na tarde, após os deploys das correções iniciais). Ao analisar cada um, identificamos que 12 são bugs reais, 1 é gap técnico (integração pela metade), 4 são novas demandas que não estavam no escopo inicial, 3 são regras de negócio da Baerlocher a serem formalizadas, e 1 decorre da qualidade do cadastro no SAP (tratado no relatório #19).
Recomendação: Corrigir os bugs e o gap técnico no próximo ciclo de desenvolvimento (prioridade para o ponto 8, de baixo esforço). Agendar alinhamento curto para fechar as regras de negócio (pontos 2, 7 e 9) e o caminho a seguir para códigos internos do cliente (ponto 10B). Priorizar em conjunto com a Baerlocher as novas demandas (campos adicionais, redespacho, entregas programadas, tradução de códigos do cliente). Aguardar o retorno do cadastro para endereçar o ponto 3.
Impacto: Com essa separação clara entre bugs, demandas e regras, a equipe comercial ganha visibilidade sobre o que o BORDER já cobre, o que é evolução e o que nunca esteve no escopo original. A correção dos pontos 10A e 11, em conjunto com o ajuste de escopo da sincronização (relatório #19), deve eliminar a maior parte dos sintomas observados nos testes — os casos remanescentes com códigos do cliente dependem da definição do ponto 10B.