"E se der errado?" é a objeção mais legítima e mais subestimada quando uma PME está contratando automação operacional. Ninguém quer acordar numa terça-feira para descobrir que o agente de WhatsApp respondeu besteira para 200 clientes durante a madrugada, ou que o fluxo de cobrança mandou boleto duplicado para a carteira inteira.
O medo é real e, bem canalizado, vira o melhor filtro possível para contratar o fornecedor certo. Este artigo é um guia de como estruturar o projeto para que, mesmo quando algo der errado — porque vai dar, em algum momento — o estrago seja contido, reversível e aprendível. É isso que separa automação profissional de gambiarra contratada.
Por que automação vai falhar em algum momento
Primeiro, verdade desconfortável: todo sistema falha em algum ponto. Banco falha. Nubank falha. Google falha. A pergunta não é "se" — é "com que frequência, com que impacto e com que rapidez você descobre e recupera".
Automação tem três fontes clássicas de falha:
- Dado de entrada ruim — cadastro furado no ERP, cliente com CNPJ errado, produto sem preço
- Integração externa instável — API do WhatsApp fora, gateway de pagamento caindo, ERP lento
- Comportamento inesperado do LLM — cliente pergunta algo fora do escopo e o agente alucina
Empresa séria planeja para os três. Fornecedor amador finge que nada disso vai acontecer.
Os 6 mecanismos de proteção que devem existir
Antes de assinar qualquer contrato de automação, verifique se o projeto tem esses mecanismos. Sem eles, você está contratando otimismo.
1. Ambiente de testes antes de produção
Toda mudança relevante deveria rodar primeiro em ambiente de teste com dados reais mascarados, testada por alguém do time do cliente, e só depois ser promovida para produção. Isso é básico em engenharia de software e, inexplicavelmente, muitos fornecedores de automação ignoram.
Pergunte: existe um ambiente separado para testar antes de subir para produção? Se a resposta for "a gente testa direto na produção com clientes reais", rode.
2. Lançamento em canary (piloto pequeno)
Mesmo após testes internos, o primeiro lançamento em produção deveria atingir uma fração pequena de clientes — digamos, 10% do volume. Monitora-se por alguns dias, e só depois o lançamento sobe para 100%.
Isso limita o estrago de um bug que passou despercebido. Se der errado, 10% sofre. Se não tiver canary, 100% sofre.
3. Kill switch documentado
Tem que existir um botão que desliga a automação e devolve o fluxo para atendimento humano em menos de 5 minutos. Literalmente um botão — não um ticket de suporte, não um e-mail para o fornecedor, não "a gente vê amanhã cedo".
Pergunte no processo de venda: como a gente desliga isso se estiver fazendo estrago? Se a resposta for vaga, você está comprando sistema sem freio.
4. Logs e auditoria de tudo
Cada mensagem respondida, cada boleto enviado, cada pedido criado precisa estar registrado com timestamp, conteúdo e decisão. Quando algo der errado, a diferença entre "10 minutos para entender o que aconteceu" e "3 dias de debugging às cegas" é o log.
Pergunte: posso ver o log das últimas 1.000 interações agora? Se o fornecedor não conseguir te mostrar isso em 5 minutos, o log ou não existe ou está inacessível.
5. Escalonamento automático para humano
O agente de IA não é infalível — e o bom projeto reconhece isso com regras explícitas de escalonamento. Se o cliente pede desconto grande, se o valor passa de X, se a conversa dura mais de Y mensagens sem resolver, se o cliente está claramente irritado — tudo isso deveria automaticamente passar para humano.
Sem escalonamento, o agente tenta resolver tudo e queima clientes importantes sem o dono da empresa perceber.
6. Backup e rollback
Se uma atualização nova quebra algo, é possível voltar para a versão anterior em minutos? Banco de dados tem backup recente? O projeto tem versionamento de código? Se a resposta é "acho que sim", o projeto não tem. Se é "temos, testamos rollback mensalmente e aqui está o processo", você está em boa companhia.
O que deve estar no contrato
Mecanismo técnico sem contrato que obriga é promessa. Para transformar em garantia, o contrato de automação precisa prever:
- SLA de incidente crítico — tempo máximo de resposta (ideal: até 1h em horário comercial, até 4h fora) e tempo máximo de resolução ou mitigação
- Responsabilidade por bug em produção — se o bug for do fornecedor, quem banca o retrabalho? E o prejuízo operacional documentável?
- Propriedade do código e dos dados — quem é dono, como é entregue ao cliente em caso de encerramento, como é feita a transferência para outro fornecedor se necessário
- Auditoria técnica — direito do cliente de ter um terceiro auditando a implementação (raro, mas poderoso em projeto crítico)
- Cláusula de saída — como o cliente encerra o contrato sem ficar refém de dados dentro do sistema do fornecedor
Contrato que prevê tudo isso não encarece o projeto — estrutura a relação. Fornecedor que não quer assinar esses itens está te dizendo silenciosamente que não pretende sustentar o que prometeu.
O risco de não automatizar também existe
Um viés que quase ninguém admite: a contraparte de "e se der errado?" é "e se continuar como está?". Operação manual também falha — só que a falha fica diluída no dia a dia, sem ninguém medir.
Clientes atendidos com 3 horas de atraso em horário comercial. Boletos reenviados com CNPJ errado porque o atendente copiou de carteira vizinha. Pedido perdido porque o WhatsApp estava no celular do vendedor que saiu de férias. Inadimplência que sobe devagar porque ninguém cobra sistematicamente.
Esses prejuízos nunca viram linha em relatório porque são distribuídos no caos. Automação mal feita é pior que manual. Automação bem feita com garantias compete com a realidade manual, não com a fantasia de perfeição.
Como a BASE estrutura o risco em projeto novo
Para dar concretude: quando a BASE assume um projeto de automação, a primeira entrega não é o sistema funcionando com 100% do volume. É um plano de risco assinado junto com o contrato, que inclui:
- Qual ambiente de teste vai ser usado
- Qual fração do volume vai no canary inicial
- Quem são os 2-3 atendentes humanos de plantão durante a primeira semana
- Qual o botão de kill switch e quem sabe apertar
- Quais métricas vamos monitorar diariamente nos primeiros 30 dias
- Quem do time do cliente tem acesso ao log em tempo real
Isso não está nos panfletos do mercado porque não vende bem — "projeto com plano de risco detalhado" é menos sedutor que "IA revolucionária 100% automática". Mas é o que diferencia projeto que continua funcionando 2 anos depois.
Cheque antes de assinar
Se você está nessa conversa agora, use este checklist rápido como filtro final antes da decisão:
- [ ] Fornecedor tem ambiente de testes separado da produção?
- [ ] Primeiro lançamento é canary controlado?
- [ ] Existe kill switch documentado com acesso ao cliente?
- [ ] Logs e auditoria estão acessíveis ao cliente?
- [ ] Escalonamento automático para humano está definido?
- [ ] Rollback foi testado e documentado?
- [ ] SLA de incidente está em contrato (não só em proposta)?
- [ ] Propriedade de código e dados está resolvida?
- [ ] Cláusula de saída está clara?
Sete ou mais marcados — bom sinal. Menos de cinco — reconversa.
Próximo passo
Se você tem uma proposta na mesa e quer uma segunda opinião sem compromisso comercial, a gente olha e devolve leitura direta: o que está bem coberto, o que está frágil, o que é risco mascarado como recurso.
Agendar diagnóstico operacional →
Ver também: como escolher empresa de automação operacional e quanto custa automatizar WhatsApp.
Referências técnicas:
Este artigo foi pesquisado e estruturado por um agente autônomo da BASE.