Ficção científica não é manual de SaaS

Você já ouviu alguém numa reunião dizer que o produto vai "resolver o problema de uma vez por todas". Aquele tom de promessa grande. Aquele slide com uma frase de filme. E aí, seis meses depois, o sistema virou uma máquina que ninguém entende, que ninguém consegue corrigir, e que trata o cliente como uma linha numa planilha.

Isso tem nome. A historiadora Jill Lepore, de Harvard, andou dizendo que boa parte da indústria de tecnologia é feita de "maus leitores". Gente que leu as distopias de ficção científica e entendeu como manual de instruções. O aviso virou roteiro. E esse jeito de pensar escorre para baixo, até chegar no seu SaaS, na sua automação, no seu fluxo de atendimento. É por isso que o assunto interessa a quem gerencia um negócio, não só a quem escreve código.

O que "ler mal a ficção científica" significa na prática

Ficção científica quase sempre é um alerta. O robô que decide sozinho, o sistema que otimiza tudo e esmaga as pessoas no caminho, a empresa que sabe demais sobre você. O autor está dizendo "olha o perigo". Uma parte da indústria leu e pensou "que ideia legal de produto".

No dia a dia de um SaaS, isso aparece assim:

• O sistema decide sozinho e não avisa ninguém.
• A pessoa que usa não consegue desfazer.
• Ninguém consegue explicar por que aquilo aconteceu.
• A eficiência do painel vale mais que o cliente do outro lado.

Nada disso precisa de robô nem de IA de filme. Um algoritmo bobo de cobrança automática já faz estrago suficiente.

O caso do cliente que sumiu sem motivo

Já vi isso acontecer mais de uma vez. Uma empresa de assinatura montou uma regra "inteligente": se o pagamento falhasse duas vezes, o acesso caía na hora e a conta entrava numa fila de recuperação.

Parece razoável no slide. Na prática, o cartão de um cliente antigo, cliente de quatro anos, teve uma falha do banco emissor. Duas tentativas em dois dias. Acesso cortado numa terça-feira de manhã, com a equipe dele no meio de uma entrega. Ele mandou email. Caiu num robô. O robô respondeu que a conta estava "em processo de recuperação". Ninguém do time viu.

O cliente cancelou. Levou junto uma indicação que estava quase fechando.

O erro não foi técnico. O código funcionou exatamente como foi escrito. O erro foi de leitura: alguém achou que automatizar significa tirar a pessoa do circuito. Automatizar bem é o contrário. É tirar o trabalho chato da pessoa e deixar ela no lugar onde a decisão pesa.

A correção custou pouco, aliás. Uma regra a mais: cliente com mais de doze meses de casa e histórico limpo não perde acesso automático, vira um alerta no Slack do time de contas. Duas horas de trabalho. Zero cancelamento por esse motivo no semestre seguinte.

Automação boa devolve tempo pra pessoa decidir. Automação ruim decide no lugar dela e some.

A parte que ninguém fala: o "sem fricção" é uma ideologia

Tem uma palavra que virou dogma no mercado de SaaS: fricção. Todo mundo quer tirar. Menos cliques, menos telas, menos confirmações, menos perguntas.

Aqui vai minha opinião forte: fricção zero é uma ideia perigosa quando aplicada sem critério. Fricção é o que dá tempo da pessoa pensar. Aquela tela de "tem certeza?" antes de apagar um projeto inteiro existe por um motivo muito bom.

Quando você remove toda a fricção, você não removeu a decisão. Você só transferiu a decisão para quem escreveu o software. E quem escreveu o software não estava na sala quando o seu cliente precisou.

O trabalho de verdade é escolher onde a fricção fica. No cadastro? Tira. Na exclusão permanente de dados, no cancelamento de contrato, no envio em massa pra base inteira? Deixa. E deixa bem visível.

Democracia, no seu contexto: quem pode discordar do sistema

Lepore fala de democracia sendo minada. Soa distante de quem toca uma empresa de trinta pessoas. Mas tem uma tradução bem direta.

Democracia, num sistema, é ter mecanismo de discordância. É poder dizer "esse resultado está errado" e alguém ouvir. Pergunte isso do seu produto:

• Se o sistema errar com um cliente, existe um caminho pra ele contestar?
• Esse caminho leva a uma pessoa ou a outro robô?
• Alguém do time olha os casos onde a automação foi contestada?
• Você consegue explicar, em português, por que o sistema tomou aquela decisão?

Se a resposta pra qualquer uma for "não", você tem um problema de produto. E, dependendo do setor, um problema jurídico esperando na esquina. A LGPD, no artigo 20, dá ao titular o direito de pedir revisão de decisão automatizada que afete os interesses dele. Isso não é filosofia. É lei em vigor desde 2020.

E a IA no meio disso?

A tentação hoje é gigante. Colocar um modelo no meio do fluxo e deixar ele responder, classificar, priorizar, decidir. Funciona bem em muita coisa. Eu uso todo dia.

Só que modelo de linguagem erra com uma confiança impressionante. Ele erra com boa gramática, o que é pior, porque parece certo. Então a regra que uso nos projetos é chata e simples:

IA sugere, gente confirma, quando o custo do erro é alto.

Classificar um ticket de suporte por assunto: solta a IA, o erro custa um reencaminhamento. Decidir se um cliente entra em cobrança judicial: nem pensar sem revisão humana. Escrever o rascunho de uma proposta: IA rascunha, você revisa. Enviar a proposta sozinha para o cliente: não.

O critério não é "IA sim ou IA não". É "quanto dói se estiver errado, e quem paga essa conta". Normalmente quem paga é quem menos tem poder no sistema. É exatamente esse o alerta que a ficção científica estava dando e que muita gente leu ao contrário.

Um teste de cinco minutos pro seu sistema

Pega o fluxo mais automatizado que você tem hoje. Pode ser cobrança, onboarding, disparo de email, aprovação de cadastro. Responda três perguntas, sem consultar ninguém:

1. Qual é a pior coisa que esse fluxo pode fazer com um cliente bom, por engano?
2. Quanto tempo leva até alguém do time perceber que aconteceu?
3. O que o cliente faz enquanto espera?

Se a resposta da segunda for "quando ele reclamar", você não tem automação. Você tem uma aposta.

A correção geralmente é pequena. Um log que uma pessoa de verdade lê. Um alerta quando a regra dispara em caso fora do padrão. Um botão de desfazer. Um limite: "se for afetar mais de X clientes de uma vez, para e pergunta". Nada disso é caro. É só menos glamouroso que a versão do slide.

O produto que sobra depois de tirar a fantasia

Tecnologia boa envelhece bem porque foi feita por gente que respeita quem vai usar. É menos empolgante que a promessa de revolucionar um setor inteiro. Também dá muito menos dor de cabeça às três da manhã.

Se você está montando ou arrumando um SaaS e desconfia que a automação está decidindo mais do que devia, essa desconfiança é boa. Vale sentar e mapear onde o sistema fala e onde uma pessoa precisa falar. É o tipo de trabalho que faço com quem me chama: dá uma olhada em como eu trabalho e me conta qual fluxo está te tirando o sono.

Seu sistema cortou o acesso de um cliente de 4 anos porque o cartão dele falhou duas vezes. O código funcionou perfeitamente. O cliente cancelou.

Automação boa devolve tempo pra pessoa decidir. Automação ruim decide no lugar dela e some.

Virou moda tirar toda fricção do produto. Só que fricção zero não elimina a decisão, ela só transfere pra quem escreveu o software. E quem escreveu não estava na sala quando seu cliente precisou.

Minha regra nos projetos: IA sugere, gente confirma, quando o custo do erro é alto.

Faz um teste rápido no seu fluxo mais automatizado: qual a pior coisa que ele pode fazer com um cliente bom por engano, e quanto tempo até alguém perceber? Se a resposta for "quando ele reclamar", você não tem automação. Tem uma aposta.

Se essa desconfiança bateu aí, me conta qual fluxo está te tirando o sono.

#SaaS #Automação #ProdutoDigital #IA #TechLeadership