dieser beitrag. ein anonymisiertes ergebnis eines ops-teams, für das wir gebaut haben. die durchschnittliche bearbeitungszeit von ansprüchen sank von 4 tagen auf unter 8 stunden. ein mensch gibt nach wie vor jeden anspruch frei.
der auftraggeber hier ist eine ops-leitung bei einer 60-köpfigen logistikfirma. ansprüche waren der engpass. ein anspruch kam per e-mail an, wartete in einer queue, wurde über 3 tabellenkalkulationen hinweg kopiert und wartete auf 2 manuelle prüfschritte, bevor ihn jemand genehmigte. die durchschnittliche bearbeitungszeit betrug 4 tage.
wir haben eine pipeline gebaut, die den anspruch liest, ihn gegen die regeln prüft und ihn zur genehmigung an eine person weiterleitet. die durchschnittliche bearbeitungszeit liegt jetzt unter 8 stunden. dieser beitrag zeigt, was sich für das ops-team geändert hat, nicht wie wir es verdrahtet haben. der build ordnet sich dem dokumentenverarbeitungs-use-case unter /ai-for/operations zu.
#was hat sich für das ops-team tatsächlich geändert?
drei tabellenkalkulationen sind weg. die zwei manuellen prüfschritte sind weg. ein anspruch kommt jetzt an, wird automatisch gelesen und validiert und landet in einer freigabe-queue, wo ein prüfer ja oder nein sagt. der prüfer ist dieselbe person, die früher schritt eins von zwei erledigte. sie erledigt jetzt den einen schritt, der urteilsvermögen erfordert.
was liefert eine ai-fallstudie zur anspruchsbearbeitung tatsächlich?
in dieser hat ein 60-köpfiges logistikteam 3 tabellenkalkulationen und 2 manuelle prüfschritte durch ai-extraktion, regelbasierte validierung und eine menschliche freigabe-queue ersetzt. die durchschnittliche bearbeitungszeit sank von 4 tagen auf unter 8 stunden. eine person genehmigt nach wie vor jeden anspruch. der durchsatz stieg, ohne die menschliche freigabe zu entfernen.
#ist noch ein mensch in der schleife?
ja. jeder anspruch wird von einer person genehmigt, bevor er ausgezahlt wird. die ai liest die dokumente und wendet die validierungsregeln an. sie genehmigt nichts eigenständig. die queue existiert, damit der prüfer einen sauberen, geprüften anspruch sieht, statt einer rohen e-mail und drei tabs. das ist das gesamte design: die maschine übernimmt das lesen und abgleichen, die person behält die entscheidung.
- ai-extraktion zieht die felder aus jedem anspruchsdokument
- regelbasierte validierung prüft sie gegen die bestehende richtlinie des teams
- eine menschliche freigabe-queue hält jeden anspruch zurück, bis ein prüfer freigibt
- durchschnittliche bearbeitungszeit: 4 tage vorher, unter 8 stunden nachher
we are
wir liefern ein messbares ergebnis — 4 tage auf unter 8 stunden — mit einer person, die jeden anspruch genehmigt, und wir benennen den beleg.
we aren't
wir verkaufen keinen autonomen anspruchs-bot, der auszahlungen eigenständig genehmigt und dich bittet, ihm zu vertrauen.
#warum das anonymisiert veröffentlichen?
der kunde hat darum gebeten, noch nicht namentlich genannt zu werden, und wir halten das ein. die zahl ist echt und der build ist echt. wir veröffentlichen das ergebnis und einen beleg, weil das die art von nachweis ist, die eine ops-leitung tatsächlich gegen ihren eigenen anspruchs-rückstand prüfen kann. wenn dieser kunde bereit ist, namentlich genannt zu werden, wird er es. das ist derselbe standard, den wir in unserem ersten build-in-public-beitrag gesetzt haben.
wenn du ein ops-team leitest und eine queue dein engpass ist, ist das oben beschriebene muster wiederholbar. es ist dasselbe dokumentenverarbeitungsmuster unter /ai-for/operations, und es liegt innerhalb des build-service bei /platforms. das ziel ist nicht weniger menschen. es ist eine schnellere anspruchsbearbeitung mit der menschlichen freigabe intakt.
die maschine übernimmt das lesen und abgleichen. die person behält die entscheidung.
wenn du eine queue, einen rückstand oder eine bearbeitungszeit hast, die du halbieren willst, sag uns, was du baust. wir halten scope und zahl schriftlich fest, bevor wir beginnen.