Em um dos testes, o cliente enviou um pedido da AVIENT com duas entregas em datas diferentes. O assistente identificou corretamente que precisava criar dois pedidos separados e avisou: "vou criar o primeiro agora, depois o segundo".
Logo após criar o primeiro, o cliente enviou o anexo com os itens do segundo pedido. Mas, nesse mesmo instante, o sistema fechou a conversa automaticamente — como parte do fluxo padrão de "pedido criado com sucesso". O resultado foi que a conversa se fragmentou:
- A primeira conversa teve o primeiro pedido criado e foi fechada.
- O anexo do segundo pedido e a resposta do assistente caíram em uma nova conversa paralela, sem contexto da anterior.
- O cliente ainda tentou dizer "Ok, obrigado" e isso abriu uma terceira conversa, também sem contexto.
Do ponto de vista operacional, o que era para ser uma única interação virou três conversas distintas — dificultando o acompanhamento pela equipe comercial e fazendo o cliente ter que reenviar o PDF.
Quando o assistente criava um pedido, ele marcava a conversa como "resolvida" imediatamente no sistema de atendimento (Chatwoot). A ideia era prática: "pedido feito, fluxo encerrado". Mas na vida real o cliente frequentemente quer continuar:
- Enviar um segundo pedido logo na sequência;
- Fazer uma pergunta sobre prazo/valor do pedido que acabou de criar;
- Pedir uma alteração enquanto o atendente comercial não assumiu;
- Simplesmente agradecer.
Quando o cliente envia qualquer coisa depois de uma conversa "resolvida", o Chatwoot reabre como uma conversa diferente. Isso criou a cadeia de três conversas observada no teste, e também fez com que o assistente perdesse o contexto do que havia sido discutido antes.
Um efeito colateral relacionado: ao anunciar a separação em dois pedidos, o assistente justificou com uma regra técnica do SAP que não existe ("o SAP não permite duas datas de entrega no mesmo item"). O SAP aceita — a separação é uma regra de negócio da Baerlocher, não uma limitação técnica. Invenção do assistente na hora de explicar ao cliente.
1. Fim do fechamento automático ao criar pedido. A conversa só é encerrada automaticamente em situações onde faz sentido — pedido recusado pelo cliente, comando de reset, erro crítico do sistema. Criação de pedido não encerra mais: o cliente tem espaço para enviar outro pedido, tirar dúvida, pedir alteração. Para não deixar conversas abertas indefinidamente, o encerramento por inatividade continua funcionando — se o cliente ficar em silêncio pelo tempo configurado, o sistema fecha a conversa preservando o registro do pedido criado.
2. Proibição de inventar limitações do SAP. O assistente foi instruído a nunca apresentar regras técnicas ou limitações do sistema que ele não tenha certeza que existem. Quando precisar justificar um procedimento operacional (como separar um pedido em dois), usa linguagem correta: "por padrão da Baerlocher" ou "por regra interna" — e não inventa justificativa técnica.
- Pedido criado (order_pending, order_confirmed, order_pending_new_items) não resolve a conversa automaticamente;
- Situações realmente terminais (pedido negado pelo cliente, comando de reset, erro crítico) continuam resolvendo;
- Escalação para atendente humano continua passando pelo fluxo próprio (status=open, labels e nota privada);
- O sistema de limpeza por inatividade agora também encerra conversas com pedido criado que ficaram ociosas por tempo suficiente — preservando o status correto (não invalida o pedido);
- Regra anti-invenção de limitações técnicas presente no prompt e validada em teste.
Situacao: O assistente fechava a conversa no
sistema de atendimento assim que criava um pedido. Isso cortava
a interação ao meio quando o cliente queria continuar: enviar
outro pedido, tirar dúvida, pedir alteração ou simplesmente
agradecer. Cada continuação caía em uma conversa nova, sem
contexto — observado em um caso concreto que virou três
conversas fragmentadas a partir de uma única intenção do cliente.
Em paralelo, o assistente justificava o split do pedido com uma
regra técnica do SAP que não existe.
Correcao: Criação de pedido não encerra mais
a conversa. O encerramento passa a ser feito só em situações
efetivamente finais (pedido recusado, reset, erro crítico) ou
pela limpeza automática de conversas inativas (que continua
funcionando, preservando o pedido que foi criado). Uma regra
explícita no prompt proíbe o assistente de inventar regras
técnicas do SAP — operações como "separar em dois pedidos"
devem ser apresentadas como "regra interna" ou "padrão da
Baerlocher", não como limitação do ERP.
Impacto: Cenários naturais — cliente com dois
pedidos em sequência, pedido com dúvida de prazo, ou simples
agradecimento — deixam de fragmentar o atendimento em várias
conversas. A equipe comercial acompanha tudo num fio só. O
cliente não precisa mais reenviar PDFs quando a conversa é
reaberta, e as mensagens mantêm o contexto do que já foi
tratado. Conversas efetivamente ociosas continuam sendo
encerradas — só que por inatividade, não por ação precipitada.