Automação de prateleira tem teto. Como saber se você já bateu no seu

Eu uso ferramenta de automação pronta todo dia e recomendo para quase todo mundo que me pergunta por onde começar. O primeiro fluxo que resolve um problema chato deveria custar uma tarde, não um projeto. Esse é o valor real da prateleira, e ele é grande.

O que eu não faço é fingir que o teto não existe. Ele existe, é bem previsível, e a parte ruim não é bater nele. A parte ruim é descobrir onde ele estava depois de já ter apoiado uma operação em cima.

Este texto é sobre onde ele fica.

O que a prateleira resolve muito bem

Vale começar por aqui, porque a resposta honesta para a maioria das perguntas que eu recebo é "usa a ferramenta pronta mesmo".

Ela é imbatível quando o trabalho é mover dado de um lugar para outro sem transformar muita coisa, quando o volume é modesto, quando o processo tem um caminho feliz claro, e quando quem vai mexer no fluxo depois não é programador. Nesses quatro casos, escrever código é escolher pagar manutenção para sempre em troca de flexibilidade que você não vai usar.

Se o seu caso é esse, para de ler aqui e vai montar. Sério.

Sinal 1: você está lutando contra a plataforma, não contra o problema

Esse é o mais confiável de todos, e o mais fácil de ignorar porque ele chega devagar.

O sintoma é a proporção do seu tempo. No começo, você passa o tempo pensando no processo: qual é a regra, o que acontece quando o cliente não responde, para onde vai o registro. Depois de um tempo, você passa o tempo pensando na ferramenta: como faço esse nó devolver o formato que o próximo espera, por que esse laço roda duas vezes, onde eu guardo esse valor entre uma execução e outra.

Quando a segunda categoria passa da metade, você não está mais automatizando o seu negócio. Você está mantendo uma ferramenta.

Isso não é culpa da ferramenta. É o preço de qualquer camada de abstração: ela te dá velocidade dentro do que ela previu e cobra caro fora disso. A pergunta útil não é "essa ferramenta é boa?", é "o meu problema ainda cabe no que ela previu?".

Sinal 2: o estado é seu inimigo

A maioria dos fluxos prontos é feita para ser sem memória. Chega um gatilho, roda os passos, acabou. Isso cobre uma quantidade enorme de casos e é justamente o que deixa a coisa simples.

O teto aparece quando o seu processo precisa lembrar. Precisa saber que já mandou aquela mensagem, que aquele lead já entrou no funil semana passada, que aquele conteúdo já foi publicado, que aquela cobrança já foi feita e não pode sair de novo. No momento em que a resposta correta depende do que aconteceu antes, você precisa de um lugar para guardar isso, precisa decidir se grava antes ou depois da ação, e precisa decidir o que fazer quando a execução morre no meio.

Nada disso é impossível numa ferramenta de prateleira. Só que a partir daqui você está escrevendo um sistema, e o fato de estar escrevendo dentro de uma interface visual não muda a natureza das perguntas. Elas são as mesmas que um desenvolvedor responde, e se ninguém as responder de propósito, elas ficam respondidas por acidente.

Sinal 3: a plataforma do outro lado tem regras que você não controla

Esse é o teto que não é da ferramenta, é do mundo, e por isso ele te alcança independente de como você montou.

Toda API séria tem cota. A Graph API da Meta, por exemplo, trabalha com janelas de tempo e fórmulas que dependem do seu uso, e a documentação é direta sobre o que acontece quando você estoura: o app ou o usuário é limitado e as requisições passam a falhar. A recomendação oficial é parar de chamar assim que bater no limite e distribuir as chamadas em vez de concentrar.

Além da cota, tem o que a plataforma simplesmente não faz. A documentação de quick replies do Instagram lista limites que não se negocia: no máximo 13 botões, título truncado em 20 caracteres, só texto puro, indisponível no desktop. E tem o que ela faz de um jeito que você precisa descobrir, como o parâmetro fields, que decide se a resposta traz o campo que você vai ler ou só o ID.

Nenhuma ferramenta de automação protege você disso. Ela te dá um bloco bonito com o nome da plataforma, e por dentro é a mesma API com as mesmas regras. Quando algo aqui aperta, a solução nunca é trocar de ferramenta, é entender a plataforma.

Sinal 4: ninguém sabe dizer se está funcionando agora

Esse é o teto que mais custa dinheiro e o que menos aparece nas comparações de ferramenta.

A pergunta é curta: se o seu fluxo parar agora, em quanto tempo alguém percebe? Se a resposta for "quando um cliente reclamar", você já passou do teto, e passou faz tempo.

Painel de execuções ajuda, mas ele responde outra pergunta. Ele diz se o processo terminou, não se ele entregou. Fluxo que roda inteiro e manda a mensagem errada aparece verde. Fluxo que checa um campo que não veio na resposta e por isso manda todo mundo para o caminho errado aparece verde. Silêncio no painel não é notícia boa, é ausência de notícia.

O que separa uma automação madura de uma amadora não é a ferramenta. É existir alguém sendo avisado quando o resultado sai errado, e não só quando o processo morre.

Sinal 5: uma pessoa só consegue mexer

Comum, e desconfortável de admitir porque geralmente essa pessoa é quem montou.

Aqui o teto não é técnico, é operacional. O fluxo funciona, resolve, dá retorno. Só que ele não está documentado, os nomes dos passos só fazem sentido para quem lembra do dia em que criou, e nenhuma decisão está escrita: por que o intervalo é esse, por que essa condição existe, o que acontece se ela não bater. No dia em que essa pessoa sai de férias ou muda de emprego, o fluxo continua rodando e ninguém pode encostar nele.

Automação que ninguém pode mexer não é ativo da empresa. É dívida com data de vencimento desconhecida.

O que fazer quando reconhece um sinal

Quase nunca a resposta é jogar fora e refazer. Isso é caro, demora, e costuma trocar um problema conhecido por três desconhecidos.

O que funciona é mais chato e mais barato. Escrever numa página o que o fluxo faz e por quê, com as decisões e não só os passos. Colocar um aviso que dispara quando o resultado sai fora do esperado, não só quando o processo quebra. Definir onde mora o estado e quando ele é gravado. E, se for o caso, tirar do fluxo visual só o pedaço que virou luta contra a ferramenta, deixando o resto onde está.

Prateleira e código não são times rivais. Na prática, quase toda automação que dura é uma mistura das duas, com a fronteira desenhada de propósito em vez de ter surgido sozinha.

Se você olhou esses cinco sinais e reconheceu dois ou mais no seu, me manda uma mensagem. Eu começo olhando o que já está rodando, e digo com franqueza quando a resposta é "não mexe, está bom assim".