
IA para indústria têxtil: pedidos, grade e prazos com dados reais
Como estruturar pedidos, grade de produção e prazos para que agentes de IA respondam clientes B2B e sinalizem atrasos da indústria têxtil com dados reais.
Quer aplicar isso na sua empresa?
Agendar conversa com o Juan →Para usar IA na indústria têxtil, o caminho mais seguro é dar ao agente dados estruturados de pedido, grade e etapas de produção, e permitir que ele responda apenas o que está registrado. Assim, o agente informa status e prazo ao cliente B2B no WhatsApp e avisa a equipe quando uma etapa foge do combinado. Sem essa base, a IA só escreve respostas bem redigidas sobre informações que ninguém confirmou.
Principais pontos
- O agente deve consultar pedido, grade e etapas em fontes estruturadas, nunca inferir prazo a partir de conversas antigas.
- Grade é um dado com regras (referência, cor, tamanho, quantidade), e precisa estar separada em grade pedida, grade de corte e grade produzida.
- Prazo prometido, prazo previsto e prazo realizado são três campos diferentes, e o agente só pode citar o que o PCP validou.
- Atraso se sinaliza por gatilhos objetivos, com encaminhamento a uma pessoa, e não por impressão do modelo.
- O começo ideal é um único fluxo, como consulta de status do pedido, com registro de cada resposta e uma métrica de sucesso combinada.
Por que pedido têxtil é mais difícil para um agente do que parece?
Um pedido têxtil raramente é uma linha com produto e quantidade. Ele carrega referência, cor, estampa, tecido, tamanhos, lavagem, aviamentos e, muitas vezes, uma aprovação de peça piloto. Cada um desses itens pode atrasar a entrega sem que o comercial perceba.
O cliente B2B (lojista, atacadista, confecção que compra de uma malharia, por exemplo) faz uma pergunta simples: quando meu pedido sai? A resposta correta depende de o tecido ter chegado, de o corte estar liberado, de a facção ter capacidade, de a lavanderia ter devolvido o lote e de a expedição ter agenda. Em muitas empresas, essas informações vivem em ERP, planilhas do PCP, grupos de WhatsApp e na memória de quem acompanha o chão de fábrica.
Se um agente de IA é conectado a esse conjunto desorganizado, ele tende a repetir informação velha ou a preencher lacunas com algo plausível. Em atendimento B2B, uma data plausível e errada é pior do que um "vou confirmar com a produção". Por isso o trabalho começa nos dados e nas regras, e só depois no modelo de linguagem. A mesma lógica vale para outras frentes da fábrica, como descrito em IA na indústria: como começar por manutenção e qualidade.
A recomendação da própria Anthropic para agentes segue esse espírito: preferir fluxos simples e previsíveis, e adicionar autonomia só quando ela for necessária e verificável. Aqui, a autonomia é pequena de propósito: ler, explicar e alertar.
Como estruturar o pedido e a grade para o agente ler?
O primeiro passo é separar o que é fato registrado do que é texto livre. O agente precisa de campos claros, e o texto livre (observações do vendedor, áudios, e-mails) entra apenas como contexto secundário, marcado como não confirmado.
Um pedido legível para um agente costuma ter estes campos:
- Identificador do pedido e do cliente, com o contato autorizado a receber informações.
- Referências incluídas, cada uma com descrição, tecido e cor.
- Grade por referência e cor, com quantidade por tamanho.
- Data de entrada, data prometida ao cliente e condições da promessa (por exemplo, aprovação de cor).
- Etapa atual, com status, responsável e data prevista de término.
- Pendências abertas, como aprovação de piloto, falta de aviamento ou pagamento de entrada, quando for condição de produção.
- Regras comerciais que afetam resposta, como entrega parcial permitida ou não.
Sobre a grade: ela é a distribuição de quantidades por tamanho (e por cor) dentro de uma referência. O erro mais comum é tratar a grade como um único número. Na prática existem pelo menos três versões: a grade pedida pelo cliente, a grade de corte (que pode mudar por aproveitamento de tecido e por encaixe) e a grade produzida e conferida. Se o agente não sabe qual delas está citando, ele passa informação ambígua, como dizer que o pedido está completo quando só o tamanho médio foi finalizado.
Também vale registrar as regras da grade como dados: múltiplos mínimos por cor, se o cliente aceita substituição de cor, se aceita variação de quantidade na entrega e quem tem autoridade para aprovar exceções. Essas regras impedem que o agente prometa algo que a empresa não faria.
Como definir prazos que o agente possa informar com segurança?
Prazo, para o agente, deve ser um conjunto de campos e não uma frase. Recomendamos separar três conceitos:
- Prazo prometido: o que foi acordado com o cliente e está no pedido.
- Prazo previsto: a estimativa atual do PCP, com base nas etapas restantes.
- Prazo realizado: o que de fato aconteceu em cada etapa, usado para auditoria e aprendizado.
Cada etapa (compra ou chegada de tecido, aprovação, corte, costura interna ou em facção, lavanderia ou beneficiamento, acabamento, conferência, expedição) deve ter data planejada, data real, responsável e status. O cálculo de datas, com capacidade, feriados e dependências, deve ficar em regras determinísticas do sistema ou do PCP. O modelo de linguagem não recalcula prazo: ele lê o resultado e o explica com clareza.
Na prática, isso significa criar ferramentas de consulta com retorno fechado. Em vez de dar ao agente acesso livre a uma planilha, oferecemos uma função como consultar_status_pedido que devolve etapa atual, previsão, pendências e a data da última atualização. A Anthropic tem um bom material sobre como desenhar ferramentas para agentes, com ênfase em retornos claros e nomes que não confundam o modelo.
Dois cuidados fazem diferença. O primeiro é informar a idade do dado: se a última atualização da facção foi há muitos dias, o agente deve dizer isso e não tratar a previsão como atual. O segundo é registrar condições: se o prazo depende da aprovação da cor pelo cliente, o agente menciona essa dependência na resposta, o que evita atrito mais tarde.
Quando e como o agente deve sinalizar atrasos?
Sinalizar atraso não é pedir ao modelo que "perceba" problemas. É definir gatilhos objetivos que o sistema verifica e que acionam o agente ou uma pessoa. Alguns exemplos de gatilhos comuns:
- A previsão de uma etapa passou da data prometida ao cliente.
- Uma etapa está sem atualização além do intervalo aceito pelo PCP.
- Uma dependência (tecido, aviamento, aprovação) segue pendente perto da data de início da etapa seguinte.
- A grade conferida ficou diferente da grade pedida, com falta por tamanho ou cor.
- Uma facção ou lavanderia informou problema de qualidade e pediu retrabalho.
Quando um gatilho dispara, o fluxo recomendado tem quatro passos. O agente registra o alerta com os dados que o motivaram. Encaminha ao responsável (PCP ou comercial), com resumo curto. Aguarda a decisão humana sobre a nova data ou a solução, como entrega parcial. Só então comunica o cliente, com a data validada e a causa em linguagem simples. O agente não inventa nova data nem oferece compensação.
Se a comunicação ao cliente for ativa, pelo WhatsApp, existem regras de canal que o agente precisa respeitar: janela de atendimento, templates aprovados e permissão do contato. Detalhamos isso em Janela de 24 horas no WhatsApp API: como o agente de IA deve agir. Sem esse cuidado, o aviso de atraso pode simplesmente não ser entregue, ou pior, gerar problema com o número.
Há ainda um ponto de governança. Se o agente passar a influenciar quem recebe prioridade de produção ou de entrega, a decisão deixa de ser só informativa e entra em terreno sensível. Mesmo em relações B2B, convém manter revisão humana e registro do critério, em linha com a discussão sobre decisões automatizadas na LGPD e o direito de revisão. Os contatos dos clientes são dados pessoais, então o agente também deve ver apenas os pedidos do cliente que está conversando.
Cenário ilustrativo: status de pedido de uma confecção
Imagine uma confecção de moda feminina que vende para lojistas e produz parte das peças em facções. Este é um cenário ilustrativo, sem relação com cliente real.
Uma compradora escreve no WhatsApp perguntando sobre o pedido de uma coleção de vestidos. O agente identifica o contato, confirma que ele está autorizado no cadastro do cliente e chama a ferramenta de consulta. O retorno indica que o corte foi concluído, a costura está em facção com término previsto para a semana seguinte, e a etapa de acabamento ainda não começou. A data prometida está mantida, com a observação de que a previsão da facção foi atualizada recentemente.
O agente responde com a etapa atual, a previsão e a data da última atualização, e pergunta se ela quer ser avisada quando o pedido for conferido. Ele não cita valores nem promete nada além do que está registrado.
Dias depois, o PCP registra que um aviamento (zíper de uma das cores) não chegou. O gatilho de dependência pendente dispara. O agente cria um alerta para o PCP com referência, cor e etapa afetada. O PCP decide por entregar as outras cores primeiro e informa a nova data. Só então o agente comunica a compradora, explicando a causa e oferecendo a entrega parcial, se a regra comercial permitir. Se ela quiser negociar algo diferente, a conversa vai para o vendedor responsável, com o histórico já resumido.
Como aplicar isso na prática, sem arriscar a operação?
O método que usamos com empresas segue quatro movimentos: mapear, limitar, pilotar e transferir. Aplicado à indústria têxtil, fica assim:
- Mapear: documentar como o pedido nasce, onde cada etapa é registrada, quem atualiza o quê e como o cliente pergunta hoje. Medir o ponto de partida, como o tempo gasto respondendo status e a frequência de informação desencontrada.
- Limitar: definir quais dados o agente lê (apenas o pedido do cliente em conversa), quais ações ele pode fazer (consultar, resumir, abrir alerta) e o que fica sempre com humanos (nova data, desconto, exceção de grade, reclamação de qualidade).
- Pilotar: escolher um fluxo real, como consulta de status de pedido, com log de cada resposta, as fontes consultadas e uma métrica de sucesso combinada com a operação. Antes de falar com clientes, testar com cenários simulados, usando técnicas como as de mocks e sandbox para testar agentes de IA.
- Transferir: entregar à equipe a documentação, as regras, o painel de acompanhamento e o critério para decidir se o projeto expande, se ajusta ou se para.
Vale observar riscos de forma explícita. O NIST AI Risk Management Framework oferece um vocabulário útil para mapear e gerir riscos de sistemas de IA, e a ANPD é a referência para orientações sobre proteção de dados no Brasil. Nenhum dos dois substitui o desenho concreto das regras do seu processo, mas ajudam a organizar a conversa interna.
Perguntas frequentes
A IA pode calcular o prazo de entrega de um pedido têxtil? Pode apoiar, mas o cálculo deve seguir regras do PCP e do sistema, com capacidade, dependências e calendário. O agente lê o resultado e o explica ao cliente. Se ele recalcular por conta própria com base em texto solto, o risco de prometer uma data errada aumenta.
Precisamos de um ERP novo para colocar um agente de IA nesse fluxo? Não necessariamente. O que importa é que pedido, grade e etapas estejam em fontes consistentes e acessíveis por uma consulta controlada, seja ERP, banco de dados ou até planilha bem mantida no início. Se hoje cada setor registra de um jeito, o primeiro projeto é padronizar os campos, e isso já traz valor mesmo sem IA.
O agente deve avisar o cliente sobre atrasos automaticamente? Pode avisar depois que uma pessoa validar a nova data e a mensagem, principalmente nos casos com impacto comercial. Para a comunicação ativa no WhatsApp, é preciso usar templates aprovados e ter permissão do contato. Avisos de rotina, sem mudança de promessa, podem ser automatizados com mais liberdade, desde que registrados.
Como evitar que o agente responda sobre pedido de outro cliente? Com controle de acesso na ferramenta de consulta, e não apenas nas instruções do modelo. A função só deve devolver pedidos associados ao contato autenticado naquela conversa, e tentativas fora desse escopo devem ser bloqueadas e registradas. Isso protege dados do cliente e reduz o risco de vazamento por erro ou por manipulação da conversa.