Os agentes de inteligência artificial funcionam bem em situações normais, mas falham em exceções, que é justamente onde reside a dificuldade de qualquer negócio. O pedido padrão é processado automaticamente; é no pedido com entrega parcial, no caso de um cliente com um problema em aberto e de um acordo comercial negociado por telefone que fica claro se a automação contribui ou atrapalha.
Nos processos que mapeamos, esse conjunto de casos "raros" normalmente representa entre 15% e 30% do volume. Não se trata de um resíduo: é um quarto da operação e geralmente concentra uma proporção muito maior do valor e do risco.
Porque não se aprende isso em vinte minutos. Uma demonstração precisa ser compreensível, e exceções são, por definição, aquilo que não é compreensível sem conhecimento do negócio.
Isso cria um viés sistemático nas decisões de compra. A ferramenta é avaliada com base no teste fácil 70%, é aprovada e o teste difícil 30% aparece em produção, quando já não se trata mais de uma decisão de compra, mas sim de um problema do projeto. É a mesma dinâmica que descrevemos ao falar sobre o purgatório do pilotoO projeto piloto evita, por definição, tudo o que possa dificultar a produção.
Há também uma razão técnica. Um modelo de linguagem não distingue entre "Eu não sei" e "Isso não corresponde ao que eu vi". Diante de um caso atípico, ele não para: preenche as lacunas. Produz uma resposta plausível construída a partir dos padrões que conhece, e essa resposta tem o mesmo tom de certeza que as respostas corretas. Em um processo automatizado, essa confiança indistinguível é o problema, não uma alucinação ocasional.
|
Cara |
Exemplo |
Como tratar isso |
|
Dados ausentes ou contraditórios |
O cliente aparece com dois números de identificação fiscal diferentes. |
Pare e suba: nunca escolha uma opção. |
|
regra não escrita do negócio |
Condição acordada verbalmente com o cliente. |
Documente a regra ou exclua o cliente do fluxo. |
|
Limite ultrapassado |
Quantidade, volume ou desconto fora do intervalo |
Validação humana obrigatória |
|
Estado incompatível |
Pedido para um cliente com pagamento pendente |
Bloqueio com justificativa explícita |
|
caso juridicamente sensível |
Dados de saúde, menores, decisões sobre pessoas |
Fora do alcance do agente |
A utilidade desta tabela não é teórica: ela serve como roteiro para uma sessão de trabalho de duas horas com as pessoas que estão implementando o processo atualmente. A pergunta a ser feita a elas não é "como o processo funciona" — elas explicarão isso em sua versão ideal —, mas sim "como ele funciona". «"Conte-me sobre o último caso que lhe deu trabalho."». Três ou quatro pessoas respondendo a essa pergunta produzem o mapa completo de exceções em uma tarde.
O aspecto mais importante no projeto de um sistema automatizado é o que acontece quando há incerteza. E para que algo aconteça, deve haver a possibilidade de o sistema declarar incerteza.
Isso requer três decisões de projeto:
Defina o que é uma condição de parada. Não se trata de uma pontuação de confiança abstrata, mas sim de condições comerciais concretas: faltam estes dados, este valor ultrapassa o limite, este cliente encontra-se nesta situação. As condições que são compreensíveis para uma pessoa são aquelas que podem ser auditadas e discutidas em comissão.
Defina onde dimensionar. Uma fila específica, com um responsável e um prazo. Uma exceção que é encaminhada para uma caixa de correio genérica não foi resolvida: foi adiada.
Defina quais informações acompanham o escalonamento. O agente deve apresentar um caso preparado: o que encontrou, o que está faltando e quais opções considera viáveis. É aí que reside a maior parte da economia de tempo, que se mantém mesmo que a decisão final seja tomada por uma pessoa.
Um sistema projetado dessa forma não automatiza o 100% do processo. Ele automatiza todo o 70% e preparar os 30% restantes. Em quase todos os casos que medimos, isso gera mais economia líquida do que tentar automatizar os 100% e ter que revisar tudo devido à desconfiança.
Há uma consequência cultural que vale a pena antecipar. Quando o indicador apresentado ao comitê é a "porcentagem de automação", a equipe tem um incentivo para reduzir as escalações, e a maneira mais rápida de fazer isso é expandir o escopo do agente para casos que ele não deveria estar tratando.
Portanto, o indicador correto não é a porcentagem automatizada, mas sim o custo total por caso resolvido corretamente. Um sistema que automatiza o 70% e dimensiona bem o 30% geralmente é mais barato do que um que automatiza o 95% e gera retrabalho, reclamações e desconfiança no 25%, que não deveria ter sido afetado.
Uma taxa de crescimento saudável não é uma taxa baixa. É uma taxa estável e explicável.
Não há necessidade de reescrevê-lo. O caminho usual tem três etapas e pode ser executado sem interromper a operação:
O erro a evitar é tentar implementar tudo de uma vez. Um sistema com duas camadas bem alinhadas é infinitamente mais gerenciável do que um com cinco camadas parcialmente alinhadas.
O mapeamento de exceções não é uma etapa preliminar em um projeto de IA; ele é o próprio projeto. Quando bem executado, produz quatro entregáveis que se sustentam por si só, independentemente de serem automatizados posteriormente ou não:
Este é exatamente o trabalho que fazemos antes de propor qualquer automação, e a razão pela qual insistimos que Primeiro, o processo é definido e, em seguida, é automatizado. . Não se trata de uma preferência metodológica: é a única maneira de saber qual parte do processo pode ser automatizada sem precisar descobrir isso em produção.
Quando um fornecedor apresentar uma solução baseada em agentes, peça uma coisa específica: que a demonstração inclui o caso raro de sua escolha.
Não se trata de um caso genérico ou raro. É um caso como o seu, com seus dados incompletos e sua regra de negócio não escrita. A resposta a essa solicitação diferencia alguém que construiu um sistema de alguém que criou uma apresentação.
Se a resposta for que este caso será tratado numa fase posterior, você já sabe onde estará o estouro de orçamento do projeto.
Porque um modelo de linguagem não distingue entre "Eu não sei" e "Isso não condiz com o que eu vi": diante de um caso atípico, ele não para, ele completa o processo. Ele produz uma resposta plausível com o mesmo tom de certeza das respostas corretas, tornando o erro difícil de detectar em um processo automatizado.
Nos processos que mapeamos, esses eventos normalmente ocorrem entre 15% e 30% do volume, embora concentrem uma proporção maior do valor e do risco. Isso não é um resíduo estatístico: é uma parte substancial da operação em si.
Em vez de pedir que descrevam o processo, pergunte a quem implementa o sistema sobre o último caso problemático. Com três ou quatro pessoas, é possível obter um panorama completo em uma única sessão. Os tipos de problemas mais comuns são: dados ausentes ou contraditórios, regras não escritas, limite excedido, status incompatível e casos juridicamente sensíveis.
Parar e subir, com três elementos definidos previamente: condições de parada expressas em termos comerciais, uma fila específica com responsável e prazo, e um pacote de informações que inclui o que foi encontrado, o que está faltando e quais opções estão sendo consideradas.
Normalmente não. Automatizar todo o formulário 70% e preparar o restante (30%) geralmente resulta em uma economia líquida maior do que automatizar o formulário 95% e gerar retrabalho, reclamações e desconfiança em casos que não deveriam ser automatizados. O indicador correto é o custo por caso resolvido com sucesso, não a porcentagem de casos automatizados.
Inclua um estudo de caso raro escolhido pelo cliente, com seus dados incompletos e regras de negócio não escritas. Se o fornecedor adiar esse caso para uma fase posterior, é aí que o estouro de orçamento do projeto aparecerá.
|
Antes de automatizar, mapeamos. Identificamos o processo real, as regras não escritas e as exceções que impediriam qualquer automação, e indicamos quais partes merecem ser automatizadas. Duas horas de análise sem compromisso. Vamos conversar → |