O critério que determina se um processo pode ser automatizado não é o nome da ferramenta nem o orçamento disponível. É uma pergunta mais simples: o processo tem instrução escrita suficiente para que alguém novo execute sem perguntar nada a quem faz hoje?

Se a resposta for não, a automação não vai funcionar, independentemente do fornecedor escolhido.

Esse é o filtro de partida antes de qualquer decisão de automação: separar processos com regra explícita de processos que dependem do julgamento de quem os executa. É o que evita o investimento num piloto que funciona na demonstração e trava na operação real.

O que é um processo com regra explícita

Um processo tem regra explícita quando alguém consegue escrevê-la em poucas linhas e outra pessoa consegue executá-la sem tirar dúvida.

Exemplos do tipo certo:

  • Quando o cliente paga em boleto com vencimento passado, o sistema bloqueia o pedido até a confirmação do crédito.
  • A nota fiscal é emitida assim que o faturamento aprova o pedido no sistema, com os dados que já estão no cadastro.
  • O extrato bancário do mês é conferido contra o relatório do caixa toda sexta-feira, às 17h, pelo responsável financeiro.

Esses processos têm um critério claro de entrada, um passo a passo que não muda dependendo de quem executa e uma condição de saída verificável. São candidatos reais à automação.

O que é um processo que depende de julgamento

Um processo depende de julgamento quando a execução muda conforme quem está fazendo, conforme o dia ou conforme o contexto.

Exemplos do tipo que ainda não está pronto:

  • "O desconto a gente analisa caso a caso."
  • "Depende de como o cliente chegou."
  • "A Márcia sabe quando pode soltar e quando tem que segurar."

Não há erro nessa forma de operar. Ela existe por boas razões, inclusive porque há situações em que o julgamento humano é o certo. O problema surge quando se tenta automatizar um processo assim sem ter mapeado a lógica por trás das decisões. A inteligência artificial (IA) vai executar alguma coisa, mas não vai executar o que a empresa precisa. A diferença só aparece quando o erro já chegou ao cliente.

Por que esse filtro vem antes de qualquer decisão de ferramenta

Entre as causas mais frequentes e menos reconhecidas nos pilotos que funcionam na demonstração e travam na operação real está esta: o processo escolhido para o piloto dependia de julgamento, e isso não foi identificado antes.

Na demonstração, os exemplos são os casos simples: o processo padrão, sem exceção. Na operação real, são as exceções que aparecem todo dia. E quem estava resolvendo essas exceções era uma pessoa, com anos de prática e critério acumulado que nunca foi escrito.

A ferramenta não tem como adivinhar esse critério. A IA não deduz a lógica de contexto que a Márcia carrega na cabeça. Ela executa o que foi parametrizado. Se o parâmetro não existe, ela ou trava, ou comete o erro, ou transfere a decisão para alguém que vai ter que resolver na mão de qualquer jeito.

O problema não é a ferramenta. O problema é que o processo não estava pronto para receber ferramenta nenhuma.

Como aplicar o filtro na prática

Para cada processo que a empresa considera automatizar, faça estas perguntas:

  1. Existe uma instrução escrita desse processo? Se não existe, ela pode ser escrita hoje, em uma hora, sem consultar mais de uma pessoa?
  2. Se uma pessoa nova assumisse esse processo amanhã, ela conseguiria executá-lo sem perguntar nada a quem faz hoje?
  3. Os casos excepcionais têm critério claro de reconhecimento e de encaminhamento, ou ficam a critério de quem está operando?

Se a resposta às três for sim, o processo tem regra explícita e está pronto para a próxima etapa do diagnóstico. Se houver um não, o trabalho antes da automação é documentar a lógica, não contratar a ferramenta.

Essa documentação não é um entrave burocrático. Ela é o próprio ativo que vai dentro da automação. Sem ela, o piloto vai repetir o mesmo ciclo: funciona na demo, trava na vida real.

O que o filtro não resolve

Passar no filtro não significa que o processo vai ser automatizado. Significa que está pronto para ser avaliado. Há processos com regra explícita que não devem ser automatizados por custo, por volume insuficiente ou por risco alto de erro em caso crítico.

O filtro também não garante que a documentação está correta. A regra escrita pode estar incompleta ou desatualizada. A próxima etapa do diagnóstico é verificar isso: percorrer a regra documentada com quem executa e com os registros reais, para ver onde ela quebra.

Mas nada disso pode acontecer antes de responder a primeira pergunta: esse processo tem instrução explícita ou depende de quem está fazendo?

A resposta a essa pergunta já vale o tempo do diagnóstico, independentemente do que vem depois.