O processo que quebra na primeira exceção

Toda empresa tem dois processos: o que está no papel e o que acontece de fato. O primeiro é limpo, linear, fácil de desenhar num fluxograma. O segundo tem atalhos, gambiarras, decisões tomadas no WhatsApp e exceções que ninguém documentou porque «sempre foi assim».

Quando uma equipe decide automatizar algo com IA, ela quase invariavelmente documenta o primeiro. E aí a implementação vai ao ar, funciona bem nos casos simples e quebra silenciosamente em tudo que foge do roteiro. O resultado prático: o time abandona a ferramenta, volta ao processo manual e conclui que «a IA não estava pronta».

A IA estava pronta. O mapeamento é que falhou.

Por que o fluxo ideal não existe na prática

Pense num processo de qualificação de leads. No papel, o lead entra pelo formulário, passa pelo SDR, recebe uma proposta em 24 horas e vai para o CRM com status atualizado. Bonito.

Na prática: metade dos leads qualificados chega por indicação direta ao vendedor, que registra no CRM dois dias depois, se registrar. Alguns chegam com CNPJ de empresa diferente do decisor real. Outros pedem proposta antes de qualquer conversa. E o SDR de plantão na sexta à tarde costuma marcar tudo como «em andamento» para limpar a fila.

Nenhuma dessas exceções aparece no fluxograma. Mas todas elas aparecem nos dados reais, e uma automação que ignora qualquer uma delas vai produzir resultados errados ou incompletos.

Três formas de mapear o que realmente acontece

1. Entrevistas com quem executa, não com quem aprova

A primeira fonte de informação deve ser a pessoa que faz o trabalho todos os dias, não o gestor que desenhou o processo. A pergunta certa não é «como funciona esse processo?», mas sim «me conta um caso que saiu do roteiro essa semana». Esse tipo de pergunta abre espaço para o relato de exceções reais, que é exatamente o que você precisa capturar.

Em um projeto recente de automação de atendimento, a equipe descobriu que cerca de 30% dos chamados tinham um campo de «motivo» preenchido incorretamente, porque o sistema legado obrigava a escolher uma categoria antes de entender o problema. Os atendentes sabiam disso e corrigiam mentalmente. A automação não sabia.

2. Análise de logs e dados históricos

Logs de sistema, histórico de tickets, registros de CRM e até planilhas paralelas que o time mantém por conta própria são fontes ricas de comportamento real. O que você procura são padrões de desvio: etapas que pulam com frequência, campos que ficam vazios, registros que voltam para estágios anteriores, tempos de execução muito acima da média.

Se 15% dos pedidos de compra voltam para aprovação mais de uma vez, existe um motivo. Pode ser uma regra de alçada mal calibrada, um tipo de fornecedor que sempre gera dúvida ou um campo do formulário que induz erro. Automatizar esse processo sem entender o padrão vai replicar o problema em escala.

3. Mapeamento de exceções antes do fluxo principal

A técnica que mais uso é simples: antes de mapear o fluxo ideal, peço para a equipe listar tudo que pode dar errado ou sair do roteiro. Chamamos isso de mapeamento de exceções. A lista costuma ser longa e desconfortável, especialmente para quem está habituado a apresentar processos de forma otimista.

Cada exceção da lista vira uma pergunta: isso acontece com que frequência? Quem decide o que fazer quando ocorre? Existe alguma regra, ou é julgamento caso a caso? Esse exercício revela onde o processo real depende de conhecimento tácito que nenhum sistema vai ter automaticamente.

O custo de pular essa etapa

Implementações que vão direto para a automação sem esse trabalho prévio costumam ter um padrão de falha específico: funcionam bem nos primeiros dias, quando os casos são simples e o time está animado para usar. Com o tempo, as exceções aparecem, o sistema não sabe lidar, o time começa a contornar a ferramenta e a taxa de adoção cai.

O problema não é técnico. É de escopo. A automação foi construída para um processo que não existe integralmente no mundo real.

Já vi isso acontecer com chatbots de atendimento que não sabiam o que fazer com reclamações fora da árvore de categorias, com automações de e-mail que enviavam mensagens de renovação para clientes que já tinham cancelado (porque o cancelamento acontecia fora do sistema integrado) e com fluxos de aprovação que travavam toda vez que o aprovador principal estava de férias.

Quando a automação pode começar

O sinal de que o mapeamento está pronto não é quando o fluxo principal está documentado. É quando a equipe consegue responder com clareza: o que acontece quando esse dado chega errado? O que o sistema faz quando o responsável não está disponível? Como tratamos o caso que não se encaixa em nenhuma categoria?

Se essas perguntas ainda geram hesitação ou respostas do tipo «aí alguém resolve na mão», o processo não está pronto para ser automatizado. Não porque a tecnologia seja insuficiente, mas porque as regras de negócio ainda estão na cabeça das pessoas, e não em lugar nenhum que um sistema possa consultar.

Esse trabalho de extração e formalização do conhecimento tácito é chato, lento e pouco glamouroso. É também o que separa implementações que funcionam de implementações que viram case do que não fazer.

O processo no papel serve para comunicar. O processo real serve para automatizar. Confundir os dois é o erro mais comum e mais caro nas implementações de IA que acompanho.