Toda demonstração de automação funciona. Ela funciona porque foi montada com um dado que a pessoa escolheu, num caminho que a pessoa desenhou, com um volume que a pessoa controlou. Isso não é desonestidade, é a natureza de uma demonstração.

O problema é que o dado real não pede licença. Ele vem com acento onde não devia, com o campo vazio que "nunca vem vazio", com o cliente que responde três dias depois, com o mês em que o volume triplicou. É aí que a automação decide se ela é uma ferramenta ou uma armadilha.

Estas quatro perguntas cabem numa conversa de vinte minutos, não exigem que você saiba programar, e a resposta a cada uma diz mais sobre o fornecedor do que qualquer portfólio. Elas vieram de erros que eu mesmo cometi, então não são hipotéticas.

1. Como eu fico sabendo que parou?

Comece por essa, sempre. Ela é a que separa quem já operou automação de verdade de quem só montou.

O que você quer ouvir não é "tem um painel". Painel é onde você vai olhar depois que já desconfiou de alguma coisa, e desconfiar é justamente o que não acontece quando o sistema falha em silêncio. O que você quer ouvir é para onde chega o aviso, quem recebe, e em quanto tempo.

E tem uma segunda camada nessa pergunta, que é a que realmente pega: existe aviso quando o processo termina mas entrega errado? Fluxo que roda inteiro, marca sucesso e manda a mensagem para a pessoa errada não aparece em nenhum monitor de erro. Ele aparece verde. Se a resposta for "aí a gente vê pelo painel", você já sabe que a resposta real é "quando alguém reclamar".

A pergunta de acompanhamento que fecha o assunto: se isso parar numa sexta às 19h, quando alguém percebe?

2. O que acontece quando o dado vem torto?

Aqui você não está pedindo uma garantia de que nunca vai vir torto. Está pedindo para saber o que o sistema faz quando vem.

Existem três comportamentos possíveis e eles são muito diferentes entre si. O primeiro é parar e avisar, que é o certo na maioria dos casos. O segundo é seguir com um valor vazio, que é o pior de todos, porque produz um resultado errado com cara de resultado certo. O terceiro é pular aquele item e continuar os outros, que às vezes é o certo e às vezes é como você perde um cliente sem saber.

Peça um exemplo concreto. Se o campo de telefone vier com letra no meio, o que acontece? Se o nome do cliente tiver uma quebra de linha, o que acontece?

Essa segunda pergunta não é aleatória. Quebra de linha dentro de um texto quebra JSON, que é o formato que quase toda integração usa por baixo. A RFC 8259 lista quais caracteres precisam ser escapados dentro de um texto, e os caracteres de controle, incluindo a quebra de linha, estão nessa lista. Uma automação montada às pressas costuma juntar texto com aspas na mão, e nesse caso o primeiro cliente que escrever um endereço em duas linhas derruba o fluxo. Ou pior: não derruba, e o conteúdo passa a significar outra coisa.

Você não precisa entender JSON para fazer a pergunta. Precisa entender a resposta: "isso está tratado" com um exemplo é diferente de "isso não costuma acontecer".

3. O que impede de fazer duas vezes?

Essa é a pergunta que eu mais vejo ficar sem resposta, e é a que gera o estrago mais caro, porque ela ataca coisas que já saíram: mensagem enviada, cobrança feita, post publicado, e-mail disparado.

O cenário é sempre o mesmo. A automação faz a ação, e morre antes de anotar que fez. Pode ser um tempo limite, uma queda de rede, um processo derrubado no meio. Na próxima execução, o sistema olha o registro, não encontra nada, e conclui que ainda não fez. Faz de novo.

Isso me pegou. Um post que já tinha ido ao ar foi publicado uma segunda vez porque o registro de "já publicado" não estava onde eu achava que estava. Em conteúdo isso é constrangedor. Em cobrança, é o cliente recebendo duas faturas. Em mensagem de venda, é a sua conta parecendo spam para o algoritmo da plataforma, o que custa muito mais caro do que o incômodo.

A pergunta específica é: o registro do que já foi feito é gravado antes ou depois da ação? E a resposta certa depende do que dói menos no seu caso. Gravar antes significa que uma falha pode fazer você pular um item. Gravar depois significa que uma falha pode fazer você repetir um item. Não existe opção sem custo, existe a escolha feita de propósito. Fornecedor que nunca pensou nisso vai responder com hesitação, e essa hesitação é a informação que você queria.

4. Quanto volume até quebrar, e quebrar como?

Toda plataforma tem cota. Não é detalhe de implementação, é regra escrita de quem opera do outro lado. A documentação de limites da Graph API da Meta, por exemplo, define janelas de tempo e fórmulas de uso, e diz o que acontece quando você estoura: o app passa a ser limitado e as requisições falham.

Isso significa que existe um número de clientes, de mensagens ou de itens por hora em que a sua automação para de funcionar, e esse número existe mesmo que ninguém tenha calculado. A pergunta é se alguém calculou.

O que você quer saber é: em que volume isso começa a apertar, o que acontece quando aperta (para tudo, fica lento, perde item), e o que precisaria mudar para aguentar o dobro. Se o fornecedor responder o volume atual e o teto conhecido, ótimo. Se responder "aguenta bastante", você acabou de descobrir que ninguém olhou.

Tem uma variação dessa pergunta que também vale, e que não é sobre volume: quando a plataforma do outro lado mudar, quem avisa? Integração com rede social, banco ou meio de pagamento muda sozinha, sem pedir licença. Uma automação sem ninguém acompanhando isso não quebra no dia da entrega, quebra alguns meses depois, quando todo mundo já esqueceu que ela existe.

O padrão por trás das quatro

Elas parecem quatro assuntos, mas são o mesmo assunto visto de quatro ângulos: o que essa automação faz quando o mundo não colabora?

E é por isso que elas funcionam mesmo com quem pergunta não sendo técnico. Nenhuma delas pede um detalhe de implementação. Todas pedem uma decisão, e decisão ou foi tomada ou não foi. Quem tomou responde rápido e com exemplo. Quem não tomou responde com adjetivo: robusto, confiável, escalável, seguro.

Uma última coisa, que vale mais do que as quatro juntas: peça para ver funcionando com um dado seu, não com o dado da demonstração. Um cliente real do seu banco de dados, com o nome do jeito que ele está escrito, com o telefone do jeito que ele foi digitado. Cinco minutos assistindo isso valem mais do que uma hora de conversa sobre arquitetura.

Se você está avaliando uma automação e quiser essas quatro perguntas respondidas por escrito antes de decidir, me manda uma mensagem. Respondo com exemplo, e digo qual dos quatro pontos o seu caso não precisa.