Por que seu piloto não virou operação
O teste funcionou, a demonstração foi aplaudida e nada entrou no dia a dia da empresa. Isso quase nunca é problema da tecnologia. São cinco decisões que ninguém tomou.
Passar qualquer teste da sua empresa por uma lista de cinco checagens e dizer, com argumento, o que falta para ele virar rotina — ou por que ele deve ser encerrado.
Faça um cadastro para liberar este curso
O curso 01 é aberto. Para os cursos 02 a 05, pedimos seis campos. É um cadastro único: feito uma vez, vale para toda a trilha. Não é diagnóstico gratuito nem gera contato comercial automático.
Demonstrar e funcionar no dia a dia são coisas diferentes
Uma demonstração precisa dar certo uma vez, com dados escolhidos a dedo, na frente de quem já quer ver aquilo funcionando. O dia a dia precisa dar certo todos os dias, com os dados que aparecem de verdade — e, quando falhar, precisa falhar de um jeito que já estava previsto.
A maioria dos testes morre porque foi feita para o primeiro caso e depois cobrada pelo segundo. O time apresenta um exemplo que funcionou, alguém pergunta o que acontece quando o documento chega ilegível, e a reunião termina numa promessa de ajuste.
Uma demonstração precisa dar certo uma vez, com dados escolhidos, para quem já quer ver aquilo funcionando. O dia a dia precisa dar certo sempre, e falhar de um jeito previsto quando falha.O argumento central deste curso
Não existe responsável, existe entusiasta
Todo teste tem um padrinho que aparece nas fotos e um entusiasta que faz a coisa andar. Nenhum dos dois é o responsável. Responsável é quem tem que explicar quando o número não aparece, tem orçamento para manter aquilo funcionando e autoridade para mudar o processo em volta.
O teste é simples: se isso parar de funcionar numa terça-feira, quem recebe a ligação? Se a resposta for “o pessoal de TI” ou “depende”, não existe responsável.
Ninguém escreveu quando a tarefa está pronta
Para funcionar no dia a dia é preciso saber quando um caso terminou: o documento foi conferido, o cliente foi qualificado, a proposta está pronta para enviar. Sem esse critério escrito, não dá para contar quantos casos foram feitos, não dá para medir erro e não dá para pagar por resultado.
O teste sobrevive sem isso porque a avaliação é no olhômetro: alguém olha o resultado e diz que ficou bom. O dia a dia não sobrevive assim.
A exceção não tem para onde ir
Todo processo real gera casos fora do padrão. No teste, a exceção volta para o entusiasta, que resolve à mão e não registra em lugar nenhum. No dia a dia, a exceção precisa de endereço: quem recebe, em quanto tempo, com quais informações, e o que acontece se ninguém responder.
Pergunte quantos por cento dos casos precisaram de alguém intervindo no último mês. Se ninguém sabe responder, é porque isso nunca foi medido — e se não foi medido, não foi desenhado.
Ninguém calculou quanto custa cada caso
O teste roda com volume pequeno, e o custo parece irrelevante. No dia a dia, esse mesmo custo por caso multiplicado pelo volume real pode virar a conta do avesso. Quando a fatura chega antes de alguém ter feito essa conta, quem manda parar é o financeiro, não a tecnologia.
São três números: quanto custa um caso simples, quanto custa um caso que precisou ser refeito e quanto custa um caso que acabou nas mãos de uma pessoa.
Ligar ao sistema ficou para depois
Se alguém precisa baixar uma planilha e colar o resultado em outro sistema, aquilo não virou rotina: virou trabalho manual com uma etapa nova no meio. Enquanto o resultado não cai automaticamente no sistema onde a decisão é tomada, o ganho fica preso na demonstração.
| Decisão | Como está no teste | O que o dia a dia exige |
|---|---|---|
| Responsável | Um entusiasta que faz a coisa andar | Alguém que responde pelo número, com orçamento e autoridade |
| Quando está pronto | Alguém olha o resultado e diz que ficou bom | Critério escrito do que conta como caso concluído |
| Exceção | Volta para o entusiasta e ninguém registra | Endereço, prazo, responsável e o que acontece se ninguém responder |
| Custo | Parece irrelevante no volume do teste | O custo do caso simples, do refeito e do que foi para uma pessoa |
| Ligação com o sistema | Baixar planilha e colar em outro sistema | O resultado entra sozinho no sistema onde a decisão acontece |
Encerrar pode ser a decisão certa
Nem todo teste merece virar rotina. Se o volume é pequeno, se o dado necessário não existe, se o processo em volta vai mudar nos próximos meses, encerrar preserva orçamento e credibilidade. O erro não é encerrar. É deixar aquilo eternamente quase pronto.
O piloto em estado permanente de quase
Um teste é apresentado com um exemplo que funcionou. Alguém pergunta o que acontece quando o documento chega ilegível, e a resposta é uma promessa de ajuste. Isso se repete a cada nova apresentação.
Um ano depois, o teste continua ligado, consumindo atenção e orçamento, sem nunca ter virado rotina nem sido encerrado. Ninguém quer ser a pessoa que cancelou, e ninguém consegue defender que continue.
De onde vem o argumento
Os cinco pontos não são teoria de gestão. São as perguntas que aparecem de verdade quando algo com IA passa a rodar no dia a dia e alguém tem que responder por aquilo numa reunião de resultado.
Quando o checklist virar decisão de investimento
Se o teste já tem responsável, critério e volume, e falta só construir e ligar aos sistemas, o problema é de execução. Se falta responsável e critério, o problema vem antes da tecnologia. O Prumo Discovery separa os dois casos antes de construir qualquer coisa.