Como Evitar que uma Automação no Make Consuma Operações Demais

Cada Módulo Executado, Uma Operação

A unidade de cobrança do Make não é o cenário nem o lead: é o módulo que roda. Um cenário de sete módulos processando mil leads consome perto de sete mil operações por mês. Se um desses módulos é um iterador que percorre dez itens, os módulos seguintes rodam dez vezes por lead.

Isso explica a surpresa mais comum: o volume de negócio não mudou, mas o consumo dobrou porque alguém acrescentou dois módulos no meio do fluxo. O desenho do cenário é uma decisão financeira.

A Maior Fonte de Desperdício

Um cenário que consulta uma fonte a cada minuto roda mais de quarenta mil vezes por mês — mesmo nos dias em que não há nada novo. Cada verificação consome operação.

Correções, em ordem de impacto:

• Troque consulta por webhook sempre que a origem permitir. Passa a rodar só quando há dado, e é instantâneo.
• Aumente o intervalo onde webhook não existe. Muita coisa que roda de minuto em minuto funciona igual de quinze em quinze.
• Restrinja o horário. Cenário comercial não precisa rodar de madrugada, fim de semana e feriado.

Filtro Depois de Cinco Módulos é Dinheiro Já Gasto

É o erro mais frequente: o cenário busca o dado, enriquece, formata, consulta o CRM — e só então descobre que aquele registro não deveria ter seguido. As operações anteriores já foram cobradas.

Coloque o filtro imediatamente depois do gatilho. Descarte teste interno, dado inválido, registro duplicado e tudo que estiver fora do escopo antes de qualquer processamento. Quando a fonte permite filtrar na própria busca — trazer só os registros novos, só de um período, só de um status —, melhor ainda: o dado nem entra no cenário.

Onde o Consumo Cresce sem Ninguém Notar

Quando um iterador quebra uma lista em itens, tudo que vem depois roda uma vez por item. Uma lista de cinquenta linhas com quatro módulos na sequência são duzentas operações — por execução.

O que fazer: filtre a lista antes de iterar, para percorrer só o que interessa; use agregadores para juntar resultados e fazer uma única chamada em vez de cinquenta; e prefira, quando a API permitir, operações em lote a uma chamada por item.

Limpeza que Devolve 20% do Consumo

• Módulos de formatação separados. Várias transformações de texto em módulos distintos podem virar um único módulo de definição de variáveis.
• Buscas redundantes. Consultar o mesmo registro duas vezes no mesmo cenário é operação paga duas vezes. Guarde o resultado em variável.
• Notificações duplicadas. Avisar no e-mail, no canal interno e por mensagem o mesmo evento triplica o custo daquela etapa. Escolha um canal principal.
• Rotas paralelas que fazem quase a mesma coisa. Muitas vezes viram uma rota só com um campo condicional.
• Módulos de teste esquecidos. Sempre existem. Abra o cenário e procure.

Falha Também Consome

Um módulo que falha e tenta de novo consome em cada tentativa. Um cenário com erro recorrente pode queimar milhares de operações por mês entregando zero resultado — e, pior, sem ninguém saber.

Configure rota de tratamento de erro com um destino visível, limite o número de novas tentativas e crie um alerta quando a taxa de falha passar de um patamar. E desative cenários que ninguém usa mais: eles continuam rodando e cobrando.

Três Hábitos Simples

Estime antes de publicar. Número de execuções esperadas por mês multiplicado pelo número de módulos que realmente rodam. Se o número assusta, o cenário está mal desenhado, não o plano.

Olhe o histórico uma vez por mês. Ordene os cenários por consumo. Quase sempre dois ou três respondem pela maior parte da conta — e é neles que a otimização compensa.

Documente cada cenário. O que dispara, o que faz, quem é o dono. Sem isso, em um ano existem dezenas rodando, metade quebrada, e ninguém sabe qual desligar.

Na Arquitetura de Receita, automação é instrumento de vazão. Se o consumo cresce mas nenhum número do funil melhora, o cenário está ocupado, não produtivo — e ocupação não é resultado.