Este post. Um exemplo prático ilustrativo, não um resultado de cliente. A equipe de logística e cada número abaixo são suposições que escolhemos para ilustrar. O desenho: a ia lê cada sinistro, regras o validam e uma pessoa aprova cada um antes do pagamento.
Para ilustrar, imagine um líder de operações numa empresa de logística de 60 pessoas. Os sinistros são o gargalo. Um sinistro chega por e-mail, espera numa fila, é copiado em três planilhas e aguarda duas etapas de revisão manual antes de alguém aprová-lo. Nada disso é uma empresa real. O cenário é suposto.
O desenho é um pipeline que lê o sinistro, o confere com as regras e o encaminha a uma pessoa para aprovação. Uma equipe nessa situação mediria o tempo médio de tratamento antes e depois, e este post não afirma nada sobre qual seria esse número. Ele mostra o que muda para a equipe de operações. O padrão corresponde ao caso de uso de processamento de documentos em /ai-for/operations.
#O que mudaria para a equipe de operações?
No cenário suposto, as três planilhas somem e as duas etapas de revisão manual também. Um sinistro chega, é lido e validado automaticamente e cai numa única fila de aprovação onde um revisor diz sim ou não. O revisor é a mesma pessoa que antes fazia a etapa um de duas. Agora faz a única etapa que exige julgamento.
O que um exemplo prático de tratamento de sinistros com ia mostra?
Neste exemplo ilustrativo, uma equipe de logística troca três planilhas e duas etapas de revisão manual por extração com ia, validação baseada em regras e uma fila de aprovação humana. O objetivo é tratar mais rápido mantendo a aprovação. Uma pessoa continua aprovando cada sinistro. Os números são suposições, não um resultado de cliente.
#Ainda há um humano no processo?
Sim. Cada sinistro é aprovado por uma pessoa antes de ser pago. A ia lê os documentos e aplica as regras de validação. Ela não aprova nada por conta própria. A fila existe para que o revisor veja um sinistro limpo e verificado em vez de um e-mail bruto e três abas. Esse é todo o design: a máquina faz a leitura e a correspondência; a pessoa mantém a decisão.
- A extração com ia coleta os campos de cada documento de sinistro
- A validação por regras os verifica contra a política existente do time
- Uma fila de aprovação humana retém cada sinistro até um revisor confirmar
- O tempo médio de tratamento, medido antes e depois, é o número a acompanhar
We are
Desenhamos para um resultado que dá para medir, como o tempo médio de tratamento, com uma pessoa aprovando cada sinistro.
We aren't
Não vendemos um bot autônomo de sinistros que aprova pagamentos sozinho e pede que você confie.
#Por que chamar de exemplo prático?
Porque aqui não temos um resultado de cliente para publicar e não vamos inventar um. A equipe e os números são suposições, então você pode conferir a lógica com o seu próprio backlog de sinistros em vez de confiar num número. Quando tivermos um engajamento real que possamos nomear, vamos publicá-lo com as provas e dizer isso. O resto dos nossos posts está no journal.
Se você lidera uma equipe de operações e uma fila é o seu gargalo, o formato acima é repetível. é o mesmo padrão de processamento de documentos de /ai-for/operations, e ele cabe em AI implementation. O objetivo não é ter menos pessoas. é tratar sinistros mais rápido, com a aprovação intacta.
A máquina faz a leitura e o cruzamento. A pessoa fica com a decisão.
Se você tem uma fila, um backlog ou um tempo de tratamento que quer melhorar, conte o que você está construindo. Vamos combinar o escopo por escrito antes de começAR.
