Três sinais de que não és dono das tuas automações mesmo pagando-as
A propriedade de um sistema automatizado não se decide na factura. Decide-se onde ele corre, em nome de quem estão as chaves e se alguém para além de quem o montou consegue percebê-lo. Há três sinais que aparecem sempre, e os três verificam-se numa tarde sem avisar ninguém.
- Não entras sozinho. Se para veres como vai um processo tens de pedir uma captura de ecrã a alguém, não tens acesso: tens um intermediário. O teste é literal — entra hoje, sem avisar, e olha para a última execução.
- Não sabes o que decide. Se ninguém na tua equipa consegue explicar porque é que um caso foi parar à fila de revisão e outro parecido não, a regra de negócio não é tua. Funciona, mas não a possuis.
- Não podes mudar de fornecedor sem parar. Se a única resposta a «e se no mês que vem acabamos?» é «pára tudo», o que contrataste não é um serviço: é uma dependência com factura mensal.
Nenhum dos três implica má-fé. Na maioria das vezes são o resultado natural de ter começado depressa: montou-se na conta de quem montava porque era o caminho ágil, ligou-se com as credenciais que havia à mão e a regra combinou-se ao telefone. Funciona. E continua a funcionar até ao dia em que queres mexer-lhe. Por isso é que isto se verifica quando está tudo bem, não depois de já teres decidido cortar.
A conta e as credenciais: onde vive o sistema e em nome de quem
É o ponto que mais vezes se salta e o único que, se falhar, invalida tudo o resto. Há duas camadas e confundem-se constantemente: a conta da ferramenta onde os fluxos correm e as credenciais de cada serviço a que esses fluxos se ligam.
- A conta da plataforma. O espaço de trabalho do Make, a instância de n8n, o projecto de Zapier. Tem de estar num endereço do teu domínio —nunca a caixa pessoal de alguém—, com o teu método de pagamento e pelo menos dois administradores do teu lado. Se o plano é pago pelo fornecedor e refacturado, não é tua.
- As credenciais de cada ligação. O acesso ao teu CRM, ao teu ERP, à caixa partilhada, à gateway de pagamento. Cada uma devia ser criada por ti, de preferência como utilizador de serviço com permissões limitadas, e não como a conta pessoal de um consultor que um dia sai.
- O domínio e os webhooks. Os URLs para onde outros sistemas te empurram dados. Se apontam para um domínio do fornecedor, mudar de fornecedor obriga a mexer em configuração de terceiros, e essa é a parte lenta de qualquer migração.
A verificação honesta é uma pergunta: se mudasses amanhã a palavra-passe de administrador, continuava tudo a funcionar? Se a resposta é não, ou não sabes, está aí o trabalho pendente. E não é um trabalho de negociação: é uma migração técnica de dois dias bem feita, que ainda te deixa as credenciais inventariadas — exactamente o que pede qualquer controlo sério sobre o que a automação pode tocar.
Exportar os fluxos: o que um ficheiro leva e o que fica de fora
É aqui que quase toda a gente relaxa cedo demais. Recebes um ficheiro JSON com os fluxos, guardas e dás o assunto por encerrado. O ficheiro é necessário, mas não é o sistema: é a planta. E há uma parte da planta que as plataformas deixam de fora por desenho.
- No Make, o blueprint do cenário é um JSON com os módulos, as suas definições e os valores mapeados; as ligações não viajam lá dentro, por isso quem importa tem de voltar a autorizar cada serviço com as suas próprias contas.
- No n8n, o JSON do fluxo inclui o nome e o id da credencial, mas não o seu conteúdo; as credenciais exportam-se à parte por linha de comandos, saem cifradas e só se decifram numa instância com a mesma chave de cifra.
- Em todas, o que o ficheiro deixa de fora é o ambiente: variáveis, cabeçalhos, limites de pedidos acordados com um fornecedor, caixas autorizadas a enviar. É a parte que faz o mesmo fluxo funcionar aqui e falhar ali.
Por isso a entrega não se aceita contra um ficheiro, aceita-se contra uma execução. O teste é simples e não admite matizes: importar os fluxos numa conta tua e vê-los completar um caso real de ponta a ponta, com as tuas credenciais, antes de alguém assinar seja o que for. Se o processo mexe em dinheiro ou compromissos com cliente, esse teste faz-se primeiro num ambiente de testes, com a mesma disciplina com que se testa qualquer alteração sem partir a automação.
A regra de negócio: aquilo que não aparece em nenhum export
Um fluxo exportado diz-te o que o sistema faz. Não te diz porquê. E o porquê é a parte cara: o limiar dos 3.000 euros, a lista dos cinco clientes que nunca passam por aprovação automática, a razão pela qual os emails de um domínio concreto são ignorados desde Março. Nada disso está no JSON. Está em decisões que alguém tomou e não escreveu.
A forma de o recuperar não é pedir «documentação» —essa palavra produz PDFs que ninguém lê—. É pedir uma lista de decisões, um artefacto muito mais pequeno e muito mais útil.
- Cada ramificação do fluxo, com o seu limiar e o seu motivo. Uma linha por cada «se… então…»: o que compara, contra que valor e de onde saiu esse valor.
- As excepções com nome. Clientes, fornecedores ou casos com tratamento diferente, e quem autorizou esse tratamento.
- O que o sistema faz quando algo falha. A quem avisa, o que repete, o que deixa à espera de um humano.
- O que NÃO faz de propósito. A lista do que se decidiu deixar de fora é a que evita que a equipa nova «arranje» algo que estava bem assim.
Se o fornecedor não consegue produzir essa lista em duas horas, não é má vontade: é que o sistema nunca foi documentado e a regra vive numa cabeça. É um risco teu, não dele, e resolve-se com o mesmo método com que se documenta qualquer automação já em produção: reconstruir o porquê a olhar para as execuções reais, não para a memória.
O histórico de execuções: o activo que ninguém pede e todos dão pela falta
É o pedido esquecido em nove de cada dez traspasses e o que mais falta faz um mês depois. O histórico —o que correu, quando, com que dados, com que resultado— é o que transforma uma automação em algo mensurável em vez de um acto de fé.
- É a tua linha de base. Sem saber quantas execuções por dia havia e que percentagem falhava, não consegues demonstrar que o sistema internalizado vai igual ou melhor. Vais discuti-lo de memória, e a memória diz sempre que antes era melhor.
- É o teu detector de casos raros. Os casos que partem um fluxo não aparecem na documentação: aparecem nos últimos seis meses de registo de erros. Essa lista vale mais do que o manual.
- Caduca. A maioria das plataformas guarda o detalhe de execução por um tempo limitado conforme o plano. Pedido três meses depois do corte, já não existe.
Pede-o antes de anunciar a mudança e guarda-o fora da plataforma: uma exportação do registo, mesmo em bruto. É também o material de que precisas para saber o que caiu e o que tem de ser reprocessado se a migração deixar um buraco.
A sobreposição: como se corta sem cortar o serviço
Um traspasse bem feito não tem dia D. Tem uma janela em que os dois sistemas convivem e só um manda. O erro clássico é ao contrário: data de fim de contrato, luzes apagadas, e a equipa nova a descobrir a quente que o fluxo de facturação tinha uma condição que ninguém contou.
- Primeiro espelho, depois comando. O sistema novo corre em paralelo sem escrever em produção —ou a escrever num destino de teste— e comparam-se resultados durante vários dias. O que divergir investiga-se antes de tocar em nada.
- Corte por troços, não de uma vez. Passa um fluxo, verifica-se uma semana, passa o seguinte. O processo que mexe em dinheiro vai em último, nunca em primeiro.
- O sistema velho desliga-se, não se apaga. Fica desactivado e acessível durante a sobreposição. Um fluxo apagado no dia do corte é uma ponte queimada com o único que sabia como aquilo funcionava.
- Um ciclo completo antes de fechar. Se há fecho mensal, a sobreposição inclui um fecho inteiro. Os casos raros não aparecem às terças: aparecem no dia 30.
A lógica é a de qualquer migração de plataforma bem montada —é exactamente o método para mudar de uma ferramenta para outra sem parar o serviço— com uma diferença: aqui não mudas só de ferramenta, mudas de dono do conhecimento. E essa parte não se importa com um JSON.
Uma nota honesta para fechar: internalizar nem sempre é a resposta. Trazer os fluxos para casa significa que alguém da tua equipa fica com a piquete, com as actualizações das APIs e com a manutenção contínua, que é trabalho real com custo real. A pergunta certa não é «dentro ou fora?», é «isto é meu nos dois casos?». Quando a resposta é sim, continuar com um fornecedor é uma decisão económica tranquila. Quando é não, não estás a contratar um serviço: estás a alugar o teu próprio processo. Se queres essa verificação feita por alguém de fora —inventário de contas, export testado, regra de negócio reconstruída e plano de sobreposição—, é exactamente o que fazemos em automação de operações.