Resposta rápida: Nove processos aparecem em toda lista de priorização e quebram quando entram: a decisão de desligamento, o processo cuja regra muda toda semana, a negociação de baixo volume e alto valor, o processo que ninguém escreveu, o relacionamento de conta chave, a exceção com cliente irritado, o processo que se apoia em dado sujo na origem, o processo que só existe porque outro está quebrado, e a aprovação final do que a marca fala em público. Em sete dos nove casos existe uma etapa vizinha que vale automatizar, e é para ela que o projeto deveria ir.
Toda empresa que me procura chega com a lista do que automatizar primeiro. Quase nenhuma chega com a lista do que deixar de fora, e é essa a que economiza dinheiro. Projeto de IA que morre raramente morre porque a tecnologia falhou. Morre porque escolheu o processo errado, e a escolha errada foi feita numa reunião de noventa minutos em que ninguém tinha o critério para dizer não.
A lista abaixo saiu de projetos que eu vi quebrar, incluindo alguns em que eu estava dentro. Ela tem um viés que vale declarar: eu trabalho vendendo implementação de IA, e escrever sobre o que não automatizar reduz o meu próprio escopo. Faço assim mesmo porque o projeto que quebra custa mais caro para mim do que o projeto que não aconteceu, e porque a pergunta chega toda semana.
O critério: o que a automação destrói além do tempo que economiza
O cálculo padrão de priorização olha frequência e tempo gasto. Ele funciona bem e é cego para duas variáveis que derrubam projeto.
A primeira é a estabilidade da regra. Automatizar significa congelar uma decisão em instrução escrita. Onde a regra muda toda semana, o congelamento vira dívida: alguém precisa manter, ninguém foi designado, e em dois meses o agente opera com a política do trimestre passado.
A segunda é o custo do erro para a relação, que é diferente do custo financeiro do erro. Uma cobrança enviada com o valor errado custa um pedido de desculpas. Um aviso de desligamento com o tom errado custa uma pessoa, um processo trabalhista e a confiança de todo mundo que ficou. As duas falhas podem ter a mesma probabilidade, e o dano não se compara.
A régua que eu uso junta as duas: se a regra é instável ou se o erro cobra na relação, o processo sai da lista de automação e entra na lista de apoio. Apoio significa a IA preparando o material e uma pessoa decidindo e assinando, que é um trabalho diferente e frequentemente mais valioso.
1. A decisão de desligamento e a conversa que vem com ela
Parece candidato porque existe muito dado estruturado em volta: desempenho, presença, entrega, custo. A tentação de deixar o modelo ordenar a lista é grande, principalmente em corte grande com prazo curto.
O que quebra: decisão sobre vínculo de trabalho apoiada em ordenação automática carrega risco jurídico direto e risco reputacional maior ainda. Os dados de desempenho de quase toda empresa carregam viés de gestor, de área e de período, e o modelo aprende esse viés e o apresenta com aparência de objetividade. Quando a decisão é questionada, e ela é, a empresa precisa explicar o critério, e explicar um ranking gerado é território ruim. O detalhe que pega as empresas de surpresa é que a explicação exigida não é sobre o modelo, e sim sobre aquela pessoa: por que ela e não o colega da mesma função com números parecidos. Nenhuma saída de modelo responde isso de um jeito que sustente audiência.
O que fazer: mantenha a decisão inteiramente humana e use IA na preparação do gestor. Consolidar o histórico de feedback de uma pessoa em duas páginas antes de uma conversa difícil é ganho real e não decide nada. Vale ler o erro dos CHROs em demissões guiadas por IA.
2. O processo cuja regra muda toda semana
Parece candidato porque é justamente o que mais consome tempo do time. Regra que muda gera retrabalho, e retrabalho aparece grande em qualquer levantamento de horas.
O que quebra: automatizar regra instável transfere o retrabalho de lugar. Antes o analista ajustava na hora, agora alguém precisa atualizar a instrução do agente, testar e publicar. Se esse alguém não existe com nome e tempo alocado, o agente segue rodando com a regra velha, e o pior cenário se instala: uma automação que parece funcionar e está errada, o que é mais caro que erro visível. O padrão que eu vejo é o projeto entregar com a manutenção combinada de boca, o consultor sair, e a primeira mudança de regra ficar três semanas na fila de alguém que já tinha outra prioridade. A partir daí o time perde a confiança e volta a conferir tudo na mão, o que soma o custo dos dois mundos.
O que fazer: estabilize a regra antes. Em metade dos casos a instabilidade vem de uma indefinição de negócio que ninguém resolveu, e o projeto de IA acaba servindo para expor isso. Resolver a indefinição costuma entregar mais que a automação entregaria. Quando a instabilidade é legítima, por mudança de mercado ou de norma, automatize o que existe de estável em volta.
Leia também
3. A negociação de baixo volume e alto valor unitário
Parece candidato porque cada negociação consome tempo caro de gente sênior, e o cálculo de horas economizadas fica bonito na planilha.
O que quebra: o ganho de automação vem de repetição, e aqui não existe repetição suficiente para o agente aprender o padrão nem para o investimento se pagar. Pior: em negociação grande o valor está no que não está escrito, na leitura da sala e no histórico da relação. O material gerado tende ao genérico exatamente onde o diferencial precisa aparecer, e o cliente do outro lado percebe. Em compra grande, quem está comprando lê a proposta procurando sinal de que você entendeu o problema específico dele, e frase bem construída sobre problema genérico produz o efeito contrário do pretendido. Some a isso que o ciclo dessas negociações é longo o suficiente para o agente nunca acumular casos parecidos o bastante para calibrar.
O que fazer: automatize a preparação, e nunca a condução. Levantar histórico da conta, consolidar interações anteriores, montar o cenário de concessões possíveis, listar o que a concorrência tem feito. Isso devolve horas de trabalho chato para quem negocia e deixa a negociação onde ela rende.
4. O processo que ninguém escreveu
Parece candidato porque a pessoa que executa faz aquilo rápido e bem, e a conclusão fácil é que existe um padrão claro esperando ser codificado.
O que quebra: quando o time senta para escrever, descobre que o processo tem quarenta exceções e que a pessoa decide por critério que ela mesma não consegue verbalizar. O projeto então gasta o orçamento inteiro na fase de descoberta e entrega uma automação do caminho feliz, que cobre um terço dos casos e joga o resto numa fila de exceção que ninguém dimensionou. O efeito colateral é pior que o desperdício: a pessoa que fazia tudo passa a tratar só as exceções, ou seja, só os casos difíceis, sem as tarefas simples que davam ritmo ao dia dela. A produtividade cai e a insatisfação sobe, com o painel do projeto mostrando sucesso.
O que fazer: escreva o processo primeiro, com quem executa, e trate isso como entrega própria com valor próprio. Empresa que depende de conhecimento não escrito tem um problema anterior ao de automação, e ele aparece inteiro no dia em que a pessoa sai. Vale ler IA e a memória institucional da empresa.
Leia também
5. O relacionamento com a conta chave
Parece candidato porque a interação é repetitiva na forma: acompanhamento periódico, relatório, resposta a pedido de rotina. Automatizar parece liberar o gerente para o que importa.
O que quebra: para o cliente grande, o acompanhamento periódico é justamente onde a relação se mantém. Quando o relatório mensal passa a chegar impecável e impessoal, o sinal recebido é de rebaixamento de prioridade. Já vi conta relevante pedir para voltar ao formato anterior, mais feio e escrito por gente. O ganho de eficiência foi real e o custo de relação foi maior. Existe uma assimetria aqui que vale entender: o cliente pequeno tende a receber bem o acompanhamento automatizado, porque antes ele não recebia nenhum. O cliente grande já tinha atenção humana, e o que ele registra é a subtração dela. A mesma mudança melhora uma ponta da carteira e piora a outra.
O que fazer: use IA no que o cliente não vê. Preparar o gerente antes da reunião, cruzar uso do produto com o que foi prometido no contrato, sinalizar risco de renovação com antecedência. O contato continua humano e fica mais bem informado, que é o oposto de automatizá-lo.
6. A exceção com cliente irritado
Parece candidato porque a exceção é justamente o que congestiona a fila e o que o time menos gosta de tratar.
O que quebra: cliente irritado já passou pelo fluxo padrão e ele falhou. Colocar outro fluxo automatizado na frente da pessoa é lido como muro, e o custo aparece em reclamação pública e em churn, longe do painel do projeto. A resposta gerada pode estar tecnicamente correta e ainda assim piorar a situação, porque o que a pessoa quer naquele momento é alguém com autoridade para resolver. O indicador que engana é o tempo médio de resposta, que melhora de verdade quando a exceção entra no fluxo automatizado. O que piora fica em outro relatório, às vezes em outra diretoria, e a conexão entre os dois números costuma levar dois trimestres para alguém fazer.
O que fazer: automatize a detecção e o roteamento, e deixe a resolução com gente. Identificar irritação cedo, classificar o motivo e entregar o caso montado para uma pessoa com poder de decidir corta o tempo de espera sem colocar um robô entre a empresa e alguém já insatisfeito. Vale ler quando o cliente exige atendimento humano.
7. O processo que se apoia em dado sujo na origem
Parece candidato porque a bagunça do dado é exatamente a dor, e existe a esperança de que a IA dê conta do que a planilha não deu.
O que quebra: o modelo não conserta cadastro duplicado, campo preenchido a esmo nem regra de negócio que mudou sem migração. Ele processa o que recebe e produz saída errada com forma convincente, que é o pior tipo de saída, porque passa despercebida por mais tempo. E quando o erro aparece, a conclusão do time costuma ser que IA não serve para aquilo, o que contamina os próximos projetos. Esse é o custo que ninguém coloca na planilha: a empresa não perde só o investimento daquele piloto, perde a disposição de tentar de novo por um ano. Reconquistar patrocínio depois de um fracasso atribuído à tecnologia custa mais que o projeto original, porque agora existe uma história interna para desmontar antes de começar.
O que fazer: arrumar o dado na fonte, e usar IA para acelerar essa arrumação, que é um caso de uso legítimo. Deduplicar, classificar, sugerir preenchimento com revisão humana. É menos vistoso e destrava tudo o que vem depois. Vale ler arrumar dados antes da IA, a ordem que funciona.
Leia também
8. O processo que só existe porque outro está quebrado
Parece candidato porque ele é repetitivo, consome muitas horas e todo mundo odeia executá-lo. A conciliação manual entre dois sistemas que deveriam conversar é o exemplo clássico.
O que quebra: automatizar aqui institucionaliza o defeito. A empresa investe, o processo fica rápido, e a integração que resolveria a raiz sai da pauta para sempre, porque a dor que a justificava desapareceu. Dois anos depois existe um agente crítico mantendo de pé um remendo que ninguém lembra por que existe. E ele fica mais difícil de remover do que o processo manual era, porque agora tem integração, permissão e gente que confia nele. O teste que revela esse caso na reunião é perguntar o que aconteceria se os dois sistemas conversassem direito: quando a resposta é que o processo inteiro desapareceria, ele nunca deveria ter entrado na fila de automação.
O que fazer: pergunte por que este processo existe antes de perguntar como automatizá-lo. Se a resposta for que ele compensa uma falha em outro lugar, o projeto certo é eliminar a falha. Quando a correção da raiz for cara ou lenta demais, automatize com prazo declarado e com a correção agendada, para que o remendo não vire permanente por inércia.
9. A aprovação final do que a marca fala em público
Parece candidato porque o volume de conteúdo cresceu muito e a revisão virou gargalo real, com gente sênior gastando hora em ajuste de vírgula.
O que quebra: a aprovação final carrega julgamento de contexto que o modelo não tem acesso. O que está acontecendo no mercado hoje, qual cliente está em negociação delicada, o que um concorrente acabou de publicar, qual assunto está sensível internamente. Um post tecnicamente impecável publicado na semana errada custa mais que dez posts atrasados. E o volume trabalha contra: quanto mais a produção acelera, mais itens passam pela última milha, e maior a chance de um deles cair num momento sensível. Empresa que automatizou a aprovação junto com a produção costuma descobrir isso de uma vez só, num episódio único que consome mais atenção da liderança do que todo o tempo economizado no trimestre.
O que fazer: automatize tudo até a última milha. Produção, adequação ao tom, checagem de padrão, versões por canal. A aprovação final fica com uma pessoa e leva minutos, porque o material chega pronto. O gargalo que existia era de produção, e ele é resolvido sem terceirizar a decisão de publicar.
Leia também
O mapa em uma tabela
| processo | por que parece candidato | o que quebra | o que automatizar em vez dele |
|---|---|---|---|
| Decisão de desligamento | muito dado estruturado em volta | viés herdado com cara de objetividade | consolidação de histórico para o gestor |
| Regra que muda toda semana | é o que mais consome tempo | retrabalho muda de lugar e some | o que é estável em volta da regra |
| Negociação de alto valor | hora cara de gente sênior | sem repetição não há aprendizado | preparação e histórico da conta |
| Processo não escrito | parece padrão claro | quarenta exceções aparecem depois | escrever o processo, com quem executa |
| Conta chave | interação repetitiva na forma | impessoal é lido como rebaixamento | preparo do gerente antes da reunião |
| Exceção com cliente irritado | congestiona a fila | robô vira muro para quem já reclamou | detecção e roteamento rápido |
| Dado sujo na origem | a bagunça é a dor | saída errada com forma convincente | a própria limpeza do dado |
| Processo que remenda outro | repetitivo e odiado | institucionaliza o defeito | corrigir a raiz, com prazo |
| Aprovação de conteúdo público | revisão virou gargalo | falta contexto de mercado e de casa | tudo até a última milha |
Quando nenhum destes nove critérios deve travar o projeto
A lista tem um risco de uso que eu preciso nomear: ela vira desculpa. Em empresa com cultura avessa a mudança, um texto sobre o que não automatizar chega como munição para adiar tudo, e não é para isso que ele serve. Sete dos nove itens acima carregam uma etapa vizinha que vale automatizar hoje, e o teste de honestidade é simples: se a conversa terminar sem nenhum processo escolhido, a lista foi usada errado.
Existe também o caso em que a exceção se justifica. Empresa com volume muito alto pode ter economia suficiente para bancar a estrutura de manutenção que a regra instável exige, e aí o item dois deixa de valer. Operação madura, com trilha de auditoria e monitoria por amostra rodando, consegue tratar exceção de cliente com apoio automatizado sem virar muro, porque o caminho para o humano é curto e funciona.
O que não muda em nenhum tamanho de empresa são os itens um e nove, decisão sobre pessoas e o que a marca fala em público. Ali a assinatura humana é o produto, e economizar nela é economizar na coisa errada.
A régua que eu deixo com o líder
Na próxima reunião de priorização, faça duas perguntas antes de escolher o processo: esta regra vai ser a mesma daqui a três meses, e se isto errar, o que custa além de dinheiro. Processo que falha nas duas sai da lista sem discussão.
Depois, para cada processo que saiu, procure a etapa vizinha. Quase sempre existe uma preparação, uma consolidação ou uma triagem que devolve boa parte do ganho sem carregar o risco. Esse movimento, de descer do processo inteiro para a etapa certa, é o que separa a lista de projetos que entrega da lista que vira post-mortem. Se você ainda está montando a primeira lista, como escolher o primeiro processo para aplicar IA traz o lado positivo do mesmo critério.