journal

de quatro dias para menos de oito horas: um estudo de caso em sinistros

um estudo de caso anônimo de sinistros com ia: um time de logística de 60 pessoas reduziu o prazo médio de sinistros de 4 dias para menos de 8 horas, com um humano aprovando cada um.

daniel o.content & research··3 min de leitura

este post. um resultado anônimo de um time de operações para o qual desenvolvemos. o prazo médio de sinistros caiu de 4 dias para menos de 8 horas. um humano ainda aprova cada sinistro.

o comprador aqui é um líder de operações numa empresa de logística de 60 pessoas. os sinistros eram o gargalo. um sinistro chegava por e-mail, ficava parado numa fila, era copiado entre 3 planilhas e esperava 2 etapas de revisão manual antes de alguém aprová-lo. o prazo médio era de 4 dias.

entregamos um pipeline que lê o sinistro, verifica pelas regras e o encaminha a uma pessoa para aprovação. o prazo médio agora é de menos de 8 horas. este post mostra o que mudou para o time de operações, não como fizemos a conexão técnica. o build corresponde ao caso de uso de processamento de documentos em /ai-for/operations.

#o que de fato mudou para o time de operações?

três planilhas foram eliminadas. as duas etapas de revisão manual foram eliminadas. um sinistro agora chega, é lido e validado automaticamente, e vai para uma ú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 estudo de caso de processamento de sinistros com ia entrega de fato?

neste caso, um time de logística de 60 pessoas substituiu 3 planilhas e 2 etapas de revisão manual por extração com ia, validação por regras e uma fila de aprovação humana. o prazo médio de sinistros caiu de 4 dias para menos de 8 horas. uma pessoa ainda aprova cada sinistro. a capacidade aumentou sem remover a aprovação humana.

#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
  • prazo médio: 4 dias antes, menos de 8 horas depois

we are

entregamos um resultado mensurável — de 4 dias para menos de 8 horas — com uma pessoa aprovando cada sinistro, e nomeamos o comprovante.

we aren't

não vendemos um bot autônomo de sinistros que aprova pagamentos por conta própria e pede que você confie nele.

#por que publicar isso de forma anônima?

o cliente pediu para não ser identificado ainda, então respeitamos isso. o número é real e o build é real. publicamos o resultado e um comprovante porque esse é o tipo de prova que um líder de operações pode verificar contra seu próprio backlog de sinistros. quando este cliente estiver pronto para ser identificado, será. é o mesmo padrão que estabelecemos no nosso primeiro post de build in public.

se você lidera um time de operações e uma fila é o seu gargalo, o modelo acima é replicável. é o mesmo padrão de processamento de documentos em /ai-for/operations, e faz parte do serviço de build em /platforms. o objetivo não é menos pessoas. é sinistros mais rápidos com a aprovação intacta.

a máquina faz a leitura e a correspondência. a pessoa mantém a decisão.

daniel o., conteúdo e pesquisa

se você tem uma fila, um backlog ou um prazo que quer reduzir pela metade e um pouco mais, diga o que você está construindo. manteremos o escopo e o número por escrito antes de começar.

voltar para o journal
build in publicoperationsclaims processingcase study

diga o que vocêprecisa entregue.

agendar uma chamada de 30 min