A demonstração sempre funciona: Como diferenciar um sistema de IA verdadeiro de um ensaiado

Traze o seu próprio input

A coisa mais útil que você pode fazer em uma reunião com um fornecedor é pegar o teclado. Entregue ao sistema um documento da sua própria empresa: um contrato bagunçado, um thread de suporte com três pessoas falando uma sobre a outra, uma fatura do seu pior fornecedor formatado. Peça-lhes para executá-lo ao vivo, sem preparação.

Observe as mudanças. O tempo de resposta, o contornamento, a formatação, a confiança da resposta. Um sistema que mantém sua forma em um input que ninguém preparou já enfrentou o mundo real pelo menos uma vez.

Se o fornecedor recusar, pergunte por quê. "Seus dados não estão carregados no sandbox" é uma resposta justa. Aceite-a, então coloque o teste por escrito como uma condição antes de assinar, com os seus arquivos e sua definição de aprovação.

Pergunte o que acontece quando está errado

Ignore a porcentagem de precisão por um momento e pergunte sobre o restante. Se o sistema estiver certo 92% do tempo, o que é o outro 8% da perspectiva do usuário? Existem apenas três opções: ele diz que não sabe, escala para uma pessoa ou produz uma resposta confiante errada.

Sistemas que falham de forma barulhenta são fáceis de operar. Sistemas que falham silenciosamente são caros, porque o custo recai sobre o cliente que age com base em informações ruins e o funcionário que gasta uma semana desentortando tudo.

Então, peça para ver um caso onde o sistema se recusou a responder. Equipes com um produto funcional geralmente exibem esses casos com algum orgulho, pois a moderação é a parte difícil de construir.

Pergunte de onde vem a resposta

Qualquer coisa que toque no seu material - políticas, preços, contratos, especificações de produtos - deve citar sua fonte. Peça uma citação, depois abra-a. A questão não é se um link apareceu. É se o documento citado realmente diz o que a resposta afirma.

Faça isso duas vezes. Duas verificações dizem mais sobre um sistema do que uma hora de slides.

Pergunte sobre o dia após os dados mudarem

As demonstrações são executadas em um snapshot congelado. O seu negócio não está congelado. Estas perguntas separam um produto de um protótipo:

Como novas ou informações corrigidas entram, com que frequência e quem é responsável?
Quando um documento é excluído ou substituído, quanto tempo leva até o sistema parar de usá-lo?
O sistema respeita as suas permissões existentes, ou todos recebem as mesmas respostas independentemente do papel?
Quando o modelo subjacente muda, você tem a oportunidade de testar antes que chegue aos seus usuários?
Quem está de plantão quando ele quebra às 9h de uma segunda-feira e qual é o tempo de resposta?

Respostas vagas aqui são o sinal mais forte que você receberá durante toda a reunião. Uma equipe que já operou algo em produção passou por todos esses cinco pontos.

Peça números que custam algo para produzir

As porcentagens em um slide são gratuitas. Peça números com forma: quantos usuários, durante quantos meses, contra qual base e quem os mediu. "Resolve 60% dos tickets de primeiro nível" significa pouco até você saber o que os outros 40% custaram para redirecionar e se essa figura veio de um piloto com dez pessoas ou de um ano com mil.

Fornecedores bons respondem com especificidades e reservas. Alguém que já lançou um sistema real sabe exatamente onde ele é problemático e diz isso sem ser pressionado.

Pergunte o que não pode fazer

Peça ao fornecedor para descrever os casos de uso em que seu sistema é uma má adaptação. Uma equipe confiante tem esta resposta pronta e geralmente é precisa: documentos longos em formato escaneado, idiomas fora do conjunto de avaliação deles, qualquer coisa que exija um julgamento com exposição legal.

Uma equipe que diz que lida com tudo está te contando que ainda não executou o sistema o suficiente para encontrar as bordas. Você encontrará neles depois de assinar o contrato.

A última pergunta

Antes de sair, pergunte para ver o que um cliente existente vê em uma terça-feira comum. Não a demonstração: o painel, os logs, a fila de casos escalonados, o relatório que alguém lê na sexta-feira de manhã. Sistemas reais acumulam essa mobília pouco glamourosa porque alguém teve que operá-los. Uma demonstração ensaiada não tem terças-feiras.