Quanto custa automatizar um processo: o que determina o custo e como saber se vale a pena
Não existe preço de tabela para automação: o custo de um projeto é determinado por quantos sistemas entram, que caminho de integração cada um oferece, quantas exceções o processo esconde e quanta manutenção ele vai exigir depois — e só faz sentido comparar esse custo com o que o processo manual já custa hoje.
Quem pergunta quanto custa automatizar um processo quase sempre quer um número único, e quem responde com um número único antes de olhar os sistemas está chutando. O preço de um projeto de automação não sai de tabela: é montado a partir de fatores que variam caso a caso. E o número isolado decide pouco, porque a escolha não é entre gastar e não gastar — é entre dois custos que já existem.
Este texto faz duas coisas: entrega o método para você calcular o custo do processo que já roda na sua operação e destrincha, um a um, os fatores que movem o preço de um projeto. Nenhum valor da Projask aparece aqui — os números da conta são os seus.
Antes do preço: quanto o processo manual já custa hoje
O custo do processo manual é o número que dá sentido a qualquer orçamento, e ele está ao seu alcance sem depender de fornecedor. São quatro variáveis, na ordem em que dá para levantar:
- Frequência. Quantas vezes o processo roda por mês. Conte execuções, não dias de trabalho.
- Tempo de trabalho por execução. Some o tempo efetivo de todas as pessoas que encostam no processo, inclusive os dois minutos de quem só aprova.
- Tempo de ciclo. Quanto leva do começo ao fim, incluindo as esperas. Esse número mede prazo, não dinheiro — e por isso fica fora da multiplicação.
- Custo da hora dessas pessoas. O custo real para a empresa: salário bruto mais encargos e benefícios, dividido pelas horas efetivamente trabalhadas no mês. Não é o salário líquido.
A variável medida errado costuma ser a segunda. Tempo de trabalho não é tempo de digitação: inclui procurar a informação que falta, conferir o que foi preenchido e cobrar quem não respondeu. Digitar é quase sempre a menor parte.
Já a espera — o arquivo que não chegou, a resposta que não veio — pertence ao tempo de ciclo, e não ao custo em dinheiro: ninguém fica parado olhando a caixa de entrada enquanto espera. Multiplicar a espera pelo custo da hora infla o número e derruba a credibilidade dele na primeira pergunta de quem estiver do outro lado da mesa. A espera entra na decisão por outro caminho: prazo perdido, cliente aguardando resposta.
E não estime de memória. Cronometre duas ou três execuções reais. A estimativa de memória tende a ficar abaixo do real, porque o que se lembra é o tempo em que se estava fazendo algo, não o tempo espalhado em idas e voltas.
A parte da conta que quase ninguém soma: erro e retrabalho
Processo manual não custa só o tempo que consome. Custa também o que produz errado. Redigitação entre sistemas gera erro de digitação, e a correção costuma sair mais cara que a digitação original, porque envolve três etapas que a digitação não tem: alguém descobrir o erro, alguém avisar quem precisa saber e alguém refazer — normalmente em dois sistemas.
Dá para levantar isso sem estatística nenhuma. Durante um mês, anote quantas vezes alguém teve que corrigir algo naquele processo. Na prática, a operação já sabe de cor quais são os casos; o que falta é o registro.
Quando existirem, entram na conta também os custos indiretos: pagamento feito em duplicidade, prazo perdido, cliente esperando resposta, relatório desatualizado que alguém usou para decidir alguma coisa.
Vale separar dois conceitos que costumam ser tratados como um só. Erro é engano — alguém digitou 1.200 onde era 12.000. Exceção é um caso legítimo que foge da regra — aquele cliente que é faturado de outro jeito. Erro é custo do processo manual; exceção vai reaparecer daqui a pouco como um dos fatores que mais encarecem o projeto.
Uma observação honesta: parte desses custos não é mensurável em dinheiro, e forçar um número só serve para enfraquecer a conta. Registre como fato qualitativo da decisão e siga.
Quanto custa automatizar um processo: os fatores que movem o preço
Com o custo do lado manual na mão, dá para olhar o outro lado. Estes são os fatores que realmente movem o preço de um projeto — e que permitem prever, antes de qualquer orçamento, se o seu caso é simples ou caro.
- Quantos sistemas estão envolvidos. Automatizar dentro de um sistema é um problema. Entre dois é outro. Entre quatro, a complexidade não cresce em linha reta: cada par que precisa conversar é mais um mapeamento de campos para fazer e mais um caminho para testar.
- Quantas etapas o processo tem, e quantas delas exigem decisão humana. Etapa que só transporta dado é barata. Etapa em que alguém olha e decide precisa de tela para a pessoa ver, de fila para o que está pendente e de registro de quem decidiu o quê e quando.
- Quantas exceções não documentadas o processo tem. É o fator que mais estoura orçamento, justamente porque ninguém as menciona no começo. Elas aparecem no meio do projeto, em frases do tipo "quando o cliente é daquele estado a gente faz diferente" ou "quando o pedido é urgente, pula a aprovação".
- Se a entrada é estruturada ou exige interpretação. Dado que já chega em campo é regra, e regra custa pouco. Documento com layout variável e texto livre exigem IA aplicada ao processo, o que traz custo por execução e, quase sempre, uma fila de revisão humana para os casos de baixa confiança.
- O que acontece quando dá errado. Definir quem é avisado, o que é reprocessado automaticamente e o que jamais pode ser executado duas vezes é trabalho de projeto, não detalhe de implementação. Pular isso é o que transforma automação em fonte de problema.
Os cinco pesam. Mas, na prática, costuma pesar mais do que qualquer um deles o caminho de integração que cada sistema oferece.
Por que a pergunta "esse sistema tem API?" define o preço
API é a porta oficial que um sistema oferece para outro sistema pedir e enviar dados sem passar por uma pessoa. Quando existe e é documentada, é o caminho mais barato de construir e o mais estável de manter. Quando não existe, o mesmo processo custa bem mais — e essa diferença não é visível de fora.
| Caminho disponível | O que significa | Efeito no esforço |
|---|---|---|
| API documentada | O sistema publica uma porta oficial para consultar e gravar dados, com documentação de como usá-la. | Menor esforço de construção e de manutenção. |
| Webhook | O sistema avisa sozinho quando algo acontece, em vez de você ficar perguntando de tempo em tempo. Costuma vir junto com a API, não no lugar dela. | Reduz a consulta repetida e aproxima a reação do imediato, mas exige um endereço público para receber os avisos e tratamento para aviso repetido ou perdido. |
| Banco de dados ou arquivo | Acesso direto à base, ou troca por CSV, XML e planilha depositada numa pasta. | Funciona, mas custa mais em conferência e depende de o formato não mudar. Gravar direto na base de um sistema de terceiro passa por cima das validações dele: em geral só a leitura é defensável. |
| Só a tela (RPA) | Nenhum dos anteriores: sobra um robô de RPA — automação que opera a interface clicando e digitando como um usuário faria. | Maior esforço de construção e o mais frágil de manter: mudança de layout, de fluxo de login ou de mensagem de erro quebra o robô. |
A consequência no orçamento é direta. Um processo com três sistemas em que dois têm API e um só permite automação de tela custa diferente do mesmo processo em que os três têm API. É o mesmo desenho, a mesma regra de negócio, e preços que não se parecem. Por isso nenhum orçamento sério sai antes de alguém olhar os sistemas envolvidos.
Esse ponto tem um artigo inteiro dedicado a ele: integração de sistemas.
Custo total: construção, homologação e manutenção
Construção é a parte visível, e é a única que a maioria dos orçamentos cobre: desenho do processo, desenvolvimento e testes.
Homologação é a fase em que a automação roda em paralelo com o processo manual até a operação confiar nos números. Custa tempo das pessoas e é a primeira coisa que alguém propõe cortar para economizar. Não corte: é justamente a homologação que revela as exceções que ninguém contou na reunião inicial — e descobrir exceção em homologação sai mais barato que descobrir em produção.
Manutenção é o custo que costuma ser omitido e que precisa estar no contrato. O sistema do outro lado muda de versão, renomeia um campo, altera a regra de autenticação, e a integração para de funcionar sem que ninguém do seu lado tenha mexido em nada. Isso não é defeito do projeto: é o ciclo de vida normal de qualquer integração em produção.
A pergunta certa para qualquer fornecedor, então, não é "tem garantia?". É: o que está incluído quando a quebra vem de mudança de terceiro, qual o prazo de resposta e como isso é cobrado.
Some ainda o monitoramento. Automação que falha em silêncio é pior que processo manual, porque o erro só aparece quando alguém sente falta do resultado — e aí o estrago já está distribuído. E some os custos recorrentes de infraestrutura e, quando há IA no caminho, o custo por execução: pequeno em volume baixo, relevante em volume alto.
Quando automatizar não se paga
Há casos em que a conta não fecha, e dizer isso faz parte do diagnóstico:
- Processo raro e curto. Roda poucas vezes por mês e leva minutos. O custo de construir e manter não é recuperado; a melhor decisão pode ser simplificar o processo manual e parar por aí. A exceção é o processo raro cujo erro sai caro — um pagamento em duplicidade, um prazo regulatório perdido.
- Regra instável. A política muda a cada poucos meses e ninguém consegue dizer qual será a regra no semestre que vem. Automatizar regra em movimento é pagar duas vezes pela mesma coisa.
- Sistema em substituição. Se o ERP vai ser trocado, integrar com o atual é construir para descartar. Vale esperar, ou desenhar a automação na camada que sobrevive à troca.
- Volume baixo com exceções demais. Quando quase toda execução é um caso especial, não existe caminho comum para automatizar. O processo precisa ser padronizado antes — e isso é trabalho de gestão, não de software.
- Processo que ninguém consegue descrever. Se duas pessoas explicam o mesmo processo de formas diferentes, o problema ainda é de desenho. Software aplicado sobre confusão produz confusão mais rápida.
Descobrir que não vale a pena é um resultado legítimo de um diagnóstico — e sai bem mais barato do que descobrir isso com o projeto pronto.
Licença de plataforma ou solução sob medida
São dois modelos de custo com formatos diferentes, e nenhum é superior por natureza.
Plataforma cobra licença. O custo de entrada é menor e o prazo é curto para os casos que ela já prevê. Em compensação, existe um valor que se repete todo mês enquanto o processo existir. O que costuma escalar nessa cobrança é número de usuários, volume de execuções ou conectores adicionais — então projete o custo no volume futuro, não no de hoje.
O limite real da plataforma aparece na exceção. Ela resolve bem o que cabe no modelo dela; quando o processo tem um caso fora do padrão, restam duas saídas — acomodar o processo à ferramenta, ou pagar desenvolvimento por cima da licença mesmo assim.
Sob medida tem custo de construção maior no início e pode ser contratado sem licença recorrente pelo uso. O que foi construído atende exatamente o processo existente, exceções incluídas.
Duas coisas aqui dependem do contrato, não do modelo, e precisam estar escritas antes da assinatura: de quem fica o código e o que a manutenção cobre. Quando o código fica com a empresa, trocar de fornecedor é possível; na plataforma, parar de pagar é parar de operar.
O critério prático: processo comum, sem exceção relevante e sem sistema legado no caminho tende à plataforma. Processo que é o jeito específico daquela empresa trabalhar tende ao sob medida.
Como pedir um orçamento que signifique alguma coisa
Três coisas você levanta sozinho, antes de falar com qualquer fornecedor: o custo mensal calculado nas duas primeiras seções, a lista dos sistemas envolvidos e a lista das exceções que a operação já conhece. Com isso na mão, a conversa deixa de ser sobre preço e passa a ser sobre escopo.
E quatro perguntas valem para qualquer proposta: quais dos meus sistemas têm API; o que acontece quando um deles muda; o que está incluído na manutenção; quanto tempo de homologação está previsto. Desconfie de preço fechado dado antes de alguém olhar os sistemas — o caminho de integração disponível é o que mais move o custo, e ele não é visível de fora.
A posição da Projask é essa: diagnóstico do processo antes do código, escopo baseado no processo real e não no catálogo de uma ferramenta, e a disposição de dizer que não vale a pena quando não vale.
Se você já tem o processo em mente, o começo é um diagnóstico — descreva o processo pelo WhatsApp e a gente olha os sistemas envolvidos antes de falar em número. Se ainda está mapeando o terreno, comece por automação de processos.
Perguntas frequentes
Como eu calculo quanto o processo manual já me custa hoje?
Multiplique a frequência no mês pelas horas de trabalho somadas de todas as pessoas por execução e pelo custo da hora dessas pessoas. O custo da hora é o custo real para a empresa: salário bruto mais encargos e benefícios, dividido pelas horas efetivamente trabalhadas no mês.
O tempo de trabalho não é só o tempo de digitação — inclui procurar a informação que falta, conferir o que foi preenchido e cobrar quem não respondeu. Já o tempo de espera pertence ao tempo de ciclo e fica fora da multiplicação, porque ninguém fica parado enquanto espera; ele entra na decisão como indicador de prazo. Em vez de estimar de memória, cronometre duas ou três execuções reais, e some à conta o custo de erro e retrabalho.
O que faz um projeto de automação ficar mais caro ou mais barato?
Cinco fatores movem o preço: quantos sistemas estão envolvidos, quantas etapas exigem decisão humana, quantas exceções não documentadas o processo esconde, se a entrada é estruturada ou exige interpretação, e o que precisa acontecer quando algo dá errado.
Na prática, costuma pesar mais do que qualquer um deles o caminho de integração que cada sistema oferece. Quando existe API documentada, o esforço de construir e manter é o menor; quando só sobra automatizar a tela com um robô de RPA, o mesmo processo custa mais e fica mais frágil, porque qualquer mudança de layout ou de login quebra o robô. Por isso nenhum orçamento sério sai antes de alguém olhar os sistemas envolvidos.
Automação é um custo único ou tem manutenção depois?
O custo total tem três partes. Construção é a visível — desenho, desenvolvimento e testes. Homologação é a fase em que a automação roda em paralelo com o processo manual até a operação confiar nos números, e é ela que revela as exceções que ninguém contou na reunião inicial. Manutenção é o custo mais omitido: o sistema do outro lado muda de versão, renomeia um campo ou altera a autenticação, e a integração para de funcionar sem que ninguém do seu lado tenha mexido em nada.
Some ainda monitoramento, custos recorrentes de infraestrutura e, quando há IA no caminho, o custo por execução. A pergunta certa para o fornecedor não é se tem garantia, e sim o que está incluído quando a quebra vem de mudança de terceiro, qual o prazo de resposta e como isso é cobrado.
Vale a pena automatizar um processo que roda poucas vezes por mês?
Em geral não, quando ele também é curto: o custo de construir e manter não é recuperado, e a melhor decisão pode ser simplificar o processo manual e parar por aí. A exceção é o processo raro cujo erro sai caro — um pagamento em duplicidade, um prazo regulatório perdido.
Outros casos em que a conta não fecha: regra que muda a cada poucos meses, sistema que vai ser substituído, volume baixo com exceções demais (aí o processo precisa ser padronizado antes, e isso é trabalho de gestão) e processo que ninguém consegue descrever de forma consistente. Descobrir que não vale a pena é um resultado legítimo de diagnóstico, e sai mais barato do que descobrir com o projeto pronto.
É melhor pagar licença de uma plataforma ou mandar construir sob medida?
São dois modelos de custo com formatos diferentes, e nenhum é superior por natureza. A plataforma cobra licença: o custo de entrada é menor e o prazo é curto para os casos que ela já prevê, mas existe um valor que se repete todo mês enquanto o processo existir. O que costuma escalar nessa cobrança é número de usuários, volume de execuções ou conectores adicionais — por isso vale projetar o custo no volume futuro, não no de hoje.
O limite real da plataforma aparece na exceção. Ela resolve bem o que cabe no modelo dela; quando o processo tem um caso fora do padrão, restam acomodar o processo à ferramenta ou pagar desenvolvimento por cima da plataforma.