O que deve exigir a um parceiro antes de automatizar processos críticos do negócio

Automatizar processos críticos do negócio não é o mesmo que automatizar o envio de um email interno. Se o fluxo que emite as faturas parar numa sexta-feira à noite, a empresa não perde dez minutos de trabalho. Perde tesouraria, prazos e credibilidade junto do cliente.

Por isso, a escolha de um parceiro de automação joga-se menos na demonstração e mais no contrato. A demonstração corre sempre bem. O que interessa é o que acontece no dia mau, e quem fica com a fatura desse dia.

As exigências que se seguem não são técnicas ao ponto de precisar de um informático na sala. São perguntas que um gestor pode fazer, e cuja resposta diz quase tudo.

Comece por definir o que é mesmo crítico

Há um teste simples. Se o processo estiver parado quatro horas, alguém de fora da empresa dá por isso?

Se a resposta for sim — um cliente, um fornecedor, a Autoridade Tributária, um banco —, o processo é crítico. Se for não, é apenas importante, e as exigências deste artigo são excessivas para ele.

Vale a pena fazer esta triagem antes da primeira reunião. Um parceiro que trate a faturação e o envio de newsletters com o mesmo nível de cuidado está a cobrar a mais por um e a proteger a menos o outro. E se ainda está na dúvida entre construir com recursos internos ou contratar, a comparação entre automação interna e parceiro especializado vem antes desta conversa.

Exija a propriedade do que for construído

Parece óbvio e raramente está escrito. O contrato tem de dizer que os fluxos, o código e as configurações desenvolvidos para a sua empresa pertencem à sua empresa.

Mas a propriedade no papel não serve de nada sem acesso na prática. Exija duas coisas concretas: que os fluxos existam em formato aberto e exportável, e que uma cópia atualizada esteja num repositório a que a sua empresa tem acesso, não apenas o fornecedor.

Aqui há um detalhe que convém conhecer. No n8n, a integração nativa com Git só está disponível nos planos Business e Enterprise. Em instalações mais simples, o versionamento tem de ser feito por exportação periódica, e isso alguém tem de garantir. Pergunte quem.

Exija um plano de saída já testado, não prometido

Esta é a exigência que separa fornecedores a sério dos restantes: mostre-me a recuperação a funcionar.

Não basta "temos backups". Um exemplo concreto, outra vez com o n8n: a documentação oficial de backup é explícita a dizer que a exportação de fluxos e credenciais pela linha de comandos não constitui uma cópia completa da instância. Fica de fora o histórico de execuções, as variáveis, os utilizadores e as definições — incluindo a chave de encriptação.

E sem essa chave, as credenciais exportadas não voltam a ser legíveis. A empresa fica com os desenhos dos fluxos e sem as chaves que os fazem andar.

Por isso, a exigência certa não é um documento. É um ensaio: repor o processo numa instalação limpa, à frente de alguém da sua equipa, e cronometrar. Se ninguém conseguir dizer quantas horas demora, o plano de saída não existe.

Exija saber o que acontece quando o fluxo falha às três da manhã

Todos os processos automatizados falham. A API do banco muda, o fornecedor de email rejeita um pedido, um ficheiro chega com um formato diferente. A diferença entre um bom e um mau parceiro está no que foi construído à volta dessa falha.

Faça três perguntas. Como é que a falha é detetada? Quem é avisado, e em quanto tempo? O que acontece aos registos que ficaram a meio — repetem-se, duplicam-se, perdem-se?

O n8n permite associar um fluxo de erro a cada processo, que é disparado quando a execução principal falha. Não vem ligado por omissão. É uma escolha de quem constrói, e é um bom indicador: quem não o configura em processos críticos, provavelmente também não pensou no resto.

Ponha um número na falha silenciosa

O pior cenário não é a falha ruidosa. É a que ninguém vê durante uma semana.

Uma estimativa, com as contas à vista. Imagine uma empresa que emite 600 faturas por mês, cerca de 30 por dia útil. Se o fluxo falhar em silêncio numa segunda-feira e só for detetado na sexta, são cinco dias e cerca de 150 faturas por emitir.

A um prazo médio de 30 dias, isso atrasa em cinco dias a entrada de todo o valor faturado nessa semana. A recuperação manual dessas 150 faturas, a três minutos cada, são sete horas e meia de trabalho não previsto. Para chegar ao custo real do seu caso, o método de cálculo do custo de um processo manual aplica-se sem alterações.

Os números mudam conforme a empresa. A conclusão não: o custo da falha está quase todo no tempo até à deteção, não na falha em si.

Exija clareza sobre onde ficam os dados

Se o processo trata dados pessoais — e a faturação, os salários e o recrutamento tratam —, o parceiro é um subcontratante na aceção do RGPD. Isso exige contrato escrito, instruções documentadas e autorização prévia para subcontratar.

Três perguntas resolvem a maior parte da conversa. Em que país corre a plataforma? Que dados ficam guardados no histórico de execuções, e durante quanto tempo? Quem, do lado do fornecedor, continua com acesso de administrador depois do projeto entregue?

A última apanha muita gente desprevenida. É comum o acesso ficar aberto indefinidamente, por comodidade. Exija que seja nominal, revogável e revisto. Quando a plataforma corre em servidor próprio, esta conversa fica bastante mais simples: os dados não saem da infraestrutura da empresa e a lista de quem lhes toca é curta e verificável.

Exija as cláusulas que a lei já pede

Desde 3 de abril de 2026 está em vigor em Portugal o Decreto-Lei n.º 125/2025, que transpõe a diretiva NIS2 e aprova o novo regime jurídico da cibersegurança. Entre as medidas obrigatórias para as entidades abrangidas está, explicitamente, a segurança da cadeia de abastecimento — ou seja, os fornecedores.

Duas consequências práticas para uma PME.

A primeira: mesmo que a sua empresa não esteja diretamente abrangida, os seus clientes maiores podem estar, e vão passar estas exigências para os contratos. Quem já as cumpre ganha tempo.

A segunda tem a ver com prazos. O regime obriga a uma notificação inicial de incidente significativo em 24 horas, com atualização a 72 horas e relatório final a um mês. Se o contrato com o seu parceiro de automação não o obrigar a avisá-lo em horas, o prazo de 24 horas queima-se à espera de um email. As coimas previstas chegam a 10 milhões de euros ou 2% do volume de negócios anual global para entidades essenciais.

Exija documentação que sobreviva a quem a escreveu

A pergunta é esta: se a pessoa que construiu isto sair amanhã, quanto tempo demora outra a perceber o que está lá?

A documentação mínima de um processo crítico cabe em poucas páginas. O que o fluxo faz, por que ordem e com que dados. Que sistemas toca e com que credenciais. O que fazer quando falha, passo a passo. E quem decide, do lado da empresa, quando há dúvida.

Um bom teste de aceitação: peça que a documentação seja escrita de forma a que outro fornecedor consiga retomar o processo. Um parceiro confiante aceita sem hesitar.

O que não vale a pena exigir

Nem todas as exigências ajudam.

Não peça preço fechado para um processo que ainda não mediu. Vai receber uma margem de segurança embutida no orçamento, e vai pagá-la. Mapear o processo antes de automatizar sai mais barato do que essa margem.

Não exija automatizar o processo a 100%. Os últimos 10% de exceções costumam custar mais do que os primeiros 90%, e raramente compensam. Um bom parceiro diz-lhe onde parar.

E não imponha a ferramenta antes de descrever o problema. A escolha entre plataformas é consequência de requisitos como soberania dos dados, volume e integrações existentes, não o ponto de partida.

A pergunta que resolve a reunião

Antes de assinar, escolha o processo mais crítico da lista e faça uma pergunta única: se este parceiro desaparecesse amanhã, quantos dias até o processo voltar a funcionar?

A resposta certa é um número, acompanhado da explicação de como se chega lá. Qualquer outra coisa — "não há esse risco", "temos tudo replicado", "isso não acontece" — significa que ainda não tem um parceiro de automação. Tem uma dependência.