Automação de Processos

A automação que dá errado começa pela pressa. Alguém descreve o processo como ele deveria ser, o fluxo é construído sobre essa descrição e no primeiro mês aparecem os casos que ninguém contou: o cliente que paga metade, o pedido que volta para revisão, o arquivo que chega em outro formato. Esses casos são o motivo de a tarefa ainda ser manual.

Por isso o diagnóstico observa a execução real. Acompanhamos a pessoa fazendo a tarefa, perguntamos por que cada passo existe e anotamos quando ela precisa decidir algo. O que exige decisão fica com a pessoa, o que é mecânico vira fluxo.

A maior parte das automações administrativas é um problema de integração. O dado nasce em um sistema e precisa chegar a outro; enquanto isso não acontece sozinho, alguém faz o transporte na mão. A primeira decisão é definir a fonte de verdade de cada dado, por campo: se o cadastro pode ser editado nos dois lados, eles vão divergir e a integração vai espalhar o erro.

A segunda decisão é como o dado viaja. Webhook quando existe, porque o sistema de origem avisa no momento do evento. Leitura periódica com marcação do que já foi processado quando não existe. Troca de arquivo quando não há API.

Nenhum envio é chamada direta e única, porque todo sistema de terceiro sai do ar, muda de versão ou impõe limite de chamadas. Os eventos entram em fila, com retentativa em intervalo crescente e idempotência, para que reprocessar não duplique efeito. O que falha em definitivo vai para uma fila de exceção com a mensagem original e opção de reprocessar, e falha persistente gera alerta para um canal com responsável.

Boa parte do tempo perdido em processo administrativo não está na execução, e sim no acompanhamento: conferir se algo aconteceu, avisar alguém, montar o número para a reunião. São as primeiras coisas a entrar em produção, porque devolvem tempo rápido e não mexem em dado crítico. Notificação é o aviso disparado por um evento; alerta é o aviso disparado pela ausência de um evento, que é o caso mais esquecido. O relatório automático fecha o ciclo: o painel lê de uma base consolidada, sem depender de fechamento manual.

Cobrar e dar baixa é o processo que mais aparece nos nossos diagnósticos: repetitivo, presente em todo negócio e com erro que custa dinheiro direto. O pedido é fechado no sistema de gestão, a cobrança é gerada no gateway a partir dele e, quando o pagamento entra, a baixa é registrada por webhook, sem ninguém conferir extrato.

Foi isso que construímos para a Alastra Uniformes. O vendedor consulta o pedido em um painel em Python e Streamlit e gera a cobrança em PIX ou boleto sem sair da tela. Por trás, fluxos em n8n buscam os dados no Bling e criam a cobrança no Asaas, que devolve a notificação de pagamento para o fluxo que registra a baixa. A conciliação é a outra metade: casar cada recebimento com a cobrança de origem por identificador e deixar em fila de exceção apenas o que não casou.

Automação custa para construir e custa para manter: toda vez que um fornecedor muda uma API ou que uma regra muda, alguém precisa mexer no fluxo. Por isso, parte do nosso trabalho é dizer o que deixar como está. E existe o caso mais comum de todos: o passo que não deveria ser automatizado porque não deveria existir.