Fallstudien
So wirkt es innerhalb eines echten Betriebsworkflows.
Jede Geschichte unten folgt derselben Form wie ein echtes Engagement: was vorher wahr war, was wir gebaut haben und was sich geändert hat – gemessen auf dieselbe Weise wie jeder Pilot.
KI-Support-Triage-Agent
Schmerzpunkt
Tickets lagen stundenlang unangetastet, ein Drittel wurde beim ersten Anlauf falsch weitergeleitet.
Ergebnis
63%
weniger Zeit bis zur ersten Reaktion
Zeit bis zur ersten Reaktion: ~5.5 Stunden → ~2 Stunden
Tickets mit Eskalations-Nacharbeit: 1 von 3 → 1 von 8
Zeit leitender Mitarbeitender für Triage: ~10 Std./Woche → ~2 Std./Woche
Relevant, wenn
Ihr Support-Team hat nicht zu wenig Personal, sondern zu wenig Kontext im Moment des Ticket-Eingangs – und dieselben Weiterleitungsfragen werden jedes Mal neu beantwortet.
Fallstudie lesen↓
TechnologieEngineering-Backlog-Agent
Schmerzpunkt
Jeder Bug verbrauchte 1–3 Stunden Analyse, bevor ein Ingenieur überhaupt mit der Behebung beginnen konnte.
Ergebnis
~15 Std.
Engineering-Zeit pro Monat zurückgewonnen
Analysezeit pro Bug: ~1–3 Stunden → ~15 Min. Review
Bugs mit verwendbarem PR-Entwurf vorab angehängt: 0% → ~40%
Engineering-Zeit pro Monat zurückgewonnen: 0 Std. → ~15 Std./Ingenieur
Relevant, wenn
Ingenieure verbringen mehr Zeit mit der Reproduktion und Analyse von Bugs als mit deren Behebung, und dieser Overhead verteilt sich ungleich im Team.
Fallstudie lesen↓
Venture CapitalVC Deal- und Portfolio-Wissensplattform
Schmerzpunkt
Deal-Historie und Portfolio-Wissen waren über Notion, E-Mail und die Köpfe der Partner verstreut.
Ergebnis
~80%
weniger Zeit mit der Rekonstruktion von Deal- und Portfolio-Historie
Zeit zur Rekonstruktion der Deal-/Portfolio-Historie vor einem Meeting: ~halber Tag → Minuten
Einarbeitungszeit neuer Associates auf Portfolio-Wissen: mehrere Wochen → unter einer Woche
Vorbereitung des Quartals-Portfolio-Reviews: mehrtägige Datensammlung → Arbeitssession, Daten vorab zusammengestellt
Relevant, wenn
«Was wissen wir bereits darüber?» ist eine Frage, die nur durch Nachfragen bei demjenigen beantwortet wird, der sich zufällig erinnert.
Fallstudie lesen↓
VersicherungVersicherungs-Schadensmeldungs-Sprachagent
Schmerzpunkt
Anrufe in Spitzenzeiten landeten auf dem Anrufbeantworter, was Schadenabwicklungen verzögerte.
Ergebnis
~35% → ~95%
eingehender Anrufe live beantwortet, kein Anrufbeantworter
Live beantwortete Anrufe in Spitzenfenstern: ~35% → ~95%
Zeit von gemeldeter Schaden bis aufgezeichneter Erstmeldung: bis zu 1 Arbeitstag → im selben Anruf
Durchlaufzeit Terminvereinbarung: 2–3 Tage Telefonate → beim ersten Anruf gebucht
Relevant, wenn
Ihr Telefonkanal ist Ihr meistgenutzter und schwächster Kanal – besonders ausserhalb der Geschäftszeiten.
Fallstudie lesen↓
GesundheitswesenGesundheitswesen-KI-Governance-Ebene
Schmerzpunkt
Drei KI-Piloten hatten dauerhaften Zugriff auf Patientendaten und Abrechnung ohne Audit-Trail.
Ergebnis
100%
der Agentenaktionen protokolliert, genehmigt und überprüfbar
Agentenaktionen protokolliert und zuordenbar: 0% → 100%
Abrechnungscode-Änderungen mit menschlicher Genehmigung: 0% (direkter Schreibzugriff) → ~100% (zweistufige Genehmigung)
Patientennachrichten ohne aufgezeichneten menschlichen Review-Schritt gesendet: nicht erfasst → 0%
Relevant, wenn
KI-Piloten laufen bereits mit echtem Zugriff auf sensible Systeme, und niemand könnte derzeit einen Audit-Trail vorlegen, wenn danach gefragt würde.
Fallstudie lesen↓
TechnologieSlack/Chat-Ops-Async-Agent
Schmerzpunkt
Kleine «Könnte jemand...»-Anfragen häuften sich und landeten immer bei denselben zwei oder drei Personen.
Ergebnis
~25/Woche
Ad-hoc-Anfragen direkt in Slack erledigt, ohne jemanden von der Arbeit abzuziehen
Zeit für eine Antwort auf eine schnelle «Könnte jemand prüfen...»-Anfrage: Minuten bis Tage → meist unter wenigen Minuten
Ad-hoc-Anfragen erledigt ohne jemanden von der Arbeit abzuziehen: 0 → ~25/Woche
Wiederkehrende Kleinkram-Anfragen am Ursprung behoben: 0 → 2 (in sechs Wochen)
Relevant, wenn
Ihr Team-Slack ist voll von «Könnte jemand...»-Anfragen, die alle bei denselben zwei oder drei Personen landen.
Fallstudie lesen↓
FintechAML/Betrug-Alarm-Triage-Agent
Schmerzpunkt
Hunderte täglicher Transaktionsüberwachungs-Alarme bedeuteten, dass Analysten die meiste Zeit damit verbrachten, Rauschen auszuschliessen statt echte Risiken zu untersuchen.
Ergebnis
~50%
der täglichen Alarme ohne vollständige manuelle Untersuchung geklärt
Risikoarme Alarme, die ein Analyst ohne Neuaufbau des Falls klären kann: 0% → ~50%
Alarm-Rückstand älter als 5 Arbeitstage: ~600 → ~120
Übereinstimmung zwischen Agentenempfehlung und endgültiger Analystendisposition: n/a (keine Agentenempfehlung vorhanden) → ~85% (von ~55% in Woche eins)
Relevant, wenn
Ihr Compliance- oder Risikoteam verbringt mehr Zeit damit, Kontext für Alarme zusammenzustellen, als tatsächlich zu entscheiden, was damit zu tun ist.
Fallstudie lesen↓
RechtswesenNDA- und Vertrags-Intake-Triage-Agent
Schmerzpunkt
Routine-NDAs warteten tagelang in derselben Queue wie Verträge, die tatsächlich das Urteilsvermögen eines Anwalts erforderten.
Ergebnis
~70%
der eingehenden NDAs am selben Tag ohne Anwaltsbegutachtung freigegeben
Eingehende NDAs/Verträge ohne Anwaltsbegutachtung freigegeben: 0% → ~70%
Zeit zur Freigabe einer Routine-NDA im Playbook: 2–4 Tage → am selben Tag (meist innerhalb von Stunden)
Anwaltszeit für Routine-Dokumentenprüfung pro Woche: ~12 Std./Woche → ~3 Std./Woche
Relevant, wenn
Das meiste, was im Eingang des Rechtsteams landet, entspricht Ihren Standardbedingungen, aber jedes Dokument wartet in der Schlange hinter denen, die wirklich einen Anwalt benötigen.
Fallstudie lesen↓
63%
weniger Zeit bis zur ersten Reaktion
Ein 40-köpfiges Support-Team bei einem Series-B-SaaS-Unternehmen
So funktioniert es
Zeit bis zur ersten Reaktion
So wurde gemessen
Gemessen über die allgemeine Eingangs-Queue über sechs Wochen; P1-Incidents ausgeschlossen.
Tickets mit Eskalations-Nacharbeit
So wurde gemessen
Gezählt als Tickets, die innerhalb von 48 Stunden nach der ersten Antwort erneut geöffnet oder einem anderen Bearbeiter zugewiesen wurden.
Zeit leitender Mitarbeitender für Triage
So wurde gemessen
Selbstberichtete Wochenschätzung der beiden leitenden Support-Mitarbeitenden, vor dem Rollout und erneut in Woche sechs.
Womit es verbunden ist
- Zendesk (Ticket-Queue, Makros und Weiterleitungsregeln)
- CRM-Kontoeinträge (Planebene, Abrechnungsstatus, Nutzungshistorie)
- Help Center und interne SOP-/Richtliniendokumente
- Eskalationsregeln und On-Call-Zuständigkeitsplan
Wo Menschen die Kontrolle behielten
- Der Agent entwirft nur Antworten und Weiterleitungsempfehlungen – nichts wird an einen Kunden gesendet, ohne dass ein Mensch auf Senden geklickt hat.
- Eskalationspakete sind klar als agentenerstellt gekennzeichnet, damit der empfangende Ingenieur weiss: prüfen, nicht annehmen.
- Akzeptanzrate und Zeit bis zur ersten Reaktion wurden ab der ersten Woche erfasst, damit das Team genau sehen konnte, wie sehr dem Agenten tatsächlich vertraut wurde.
- Agenten lesen CRM- und Richtliniendaten, können aber keine Konten bearbeiten, Rückerstattungen ausstellen oder Abrechnungen ändern.
Das Problem
Das Support-Volumen hatte die manuelle Triage-Kapazität des Teams überschritten. Jedes Ticket erforderte, dass jemand es las, das Konto im CRM prüfte, die relevante Richtlinie oder das Runbook fand, entschied, ob es sich um ein Abrechnungsproblem, einen Bug oder eine Nutzungsfrage handelte, und es dann an die richtige Queue weiterleitete. Allein dieser Triage-Schritt beanspruchte rund 10 Stunden pro Woche des leitenden Support-Mitarbeiters – Zeit, die für die schwierigsten Tickets hätte genutzt werden sollen, nicht für die Weiterleitung einfacher. In der Zwischenzeit lag das durchschnittliche Ticket 5.5 Stunden unbeachtet, und etwa ein Drittel der Tickets wurde beim ersten Anlauf falsch weitergeleitet, was Nacharbeit und eine zweite Wartezeit für den Kunden verursachte.
Was sich geändert hat
Innerhalb von sechs Wochen sank die Zeit bis zur ersten Reaktion von 5.5 Stunden auf rund 2 Stunden – der grösste Teil dieses Gewinns entstand dadurch, dass Tickets nicht mehr unbeachtet blieben, da der Agent Priorität und Weiterleitung im Moment des Eingangs bestimmt. Tickets, die Eskalations-Nacharbeit erforderten, sanken von 1 von 3 auf etwa 1 von 8, weil der richtige Kontext nun beim ersten Mal mit dem Ticket mitreist. Der Triage-Aufwand für leitendes Personal sank von rund 10 Stunden pro Woche auf 2 – Zeit, die sie auf die kritischsten Konten und die Überprüfung der Agentenantworten umlenken konnten.
Was es schwierig gemacht hat
In der ersten Woche des Agenten waren die Prioritätsbewertungen unscharf – er setzte stark auf abrechnungsbezogene Schlagwörter, die in vielen Standardkontofragen vorkommen, und markierte daher routinemässig niedrigprioriäre Tickets als hochprioriär. Eine Neugewichtung zugunsten von Kontostatus und Eskalationshistorie brachte die Akzeptanz bis zur dritten Woche auf über 90 %.
~15 Std.
Engineering-Zeit pro Monat zurückgewonnen
Ein 12-köpfiges Produkt-Team bei einer wachsenden B2B-Plattform
So funktioniert es
Analysezeit pro Bug
So wurde gemessen
Erfasst über bestehende Zeiterfassungs-Tags über einen achtwöchigen Pilot, verglichen mit denselben Tags aus dem Vorquartal.
Bugs mit verwendbarem PR-Entwurf vorab angehängt
So wurde gemessen
«Verwendbar» bedeutete, dass der Ingenieur den Entwurf weiterentwickelte statt ihn zu verwerfen.
Engineering-Zeit pro Monat zurückgewonnen
So wurde gemessen
Selbstberichtet in einer kurzen wöchentlichen Umfrage im 12-köpfigen Team, gemittelt über den zweiten Monat des Pilots.
Womit es verbunden ist
- Issue-Tracker (Backlog und Ticket-Metadaten)
- Git-Repository – Code, Historie und offene PRs
- CI-Logs und Testergebnisse
- Frühere Incident-Berichte und Runbooks
Wo Menschen die Kontrolle behielten
- Der Agent hat Lesezugriff auf Code, Logs und Historie – Schreibzugriff ist auf das Öffnen von PR-Entwürfen in eigenen Branches beschränkt.
- Jeder PR-Entwurf ist als agentenerstellt gekennzeichnet und durchläuft denselben Review- und CI-Prozess wie jeder menschlich erstellte PR.
- Nichts wird ohne menschliche Genehmigung zusammengeführt.
- Kann der Agent ein Problem nicht reproduzieren, postet er nur die Analysezusammenfassung und hört dort auf.
Das Problem
Die Liefergeschwindigkeit des Teams wurde durch die unscheinbaren Teile der Bug-Behebung gebremst: das Reproduzieren des Problems, das Durchsuchen von Logs und Codebase nach dem relevanten Pfad, das Prüfen ob ein ähnlicher Incident früher aufgetreten war. Diese Analysephase beanspruchte routinemässig 1–3 Stunden pro Ticket – oft mehr als die Behebung selbst.
Was sich geändert hat
Im Teamdurchschnitt berichteten Ingenieure, monatlich rund 15 Stunden zurückgewonnen zu haben. Bei etwa 40 % der eingehenden Bugs war ein verwendbarer PR-Entwurf angehängt, bevor ein Mensch das Ticket überhaupt angesehen hatte. Die mediane Durchlaufzeit von Bug erfasst bis Fix zusammengeführt sank entsprechend – nicht weil der Agent Engineering-Urteil ersetzte, sondern weil er den Teil entfernte, der hauptsächlich darin bestand, Dinge zu finden.
Was es schwierig gemacht hat
Anfänglich öffnete der Agent für fast jeden Bug einen PR-Entwurf, auch für mehrere, die er nicht wirklich reproduziert hatte. Wir haben die Richtlinie verschärft: ein PR öffnet sich nur, wenn die Reproduktionssicherheit einen Schwellenwert überschreitet; darunter postet er nur die Analysezusammenfassung.
~80%
weniger Zeit mit der Rekonstruktion von Deal- und Portfolio-Historie
Ein 9-köpfiges Investmentteam bei einem frühen Wachstumsfonds
So funktioniert es
Zeit zur Rekonstruktion der Deal-/Portfolio-Historie vor einem Meeting
So wurde gemessen
Basierend auf Associate-Zeitprotokollen für Partner-Meeting-Vorbereitung über eine sechswöchige Stichprobe.
Einarbeitungszeit neuer Associates auf Portfolio-Wissen
So wurde gemessen
Gemessen für den einen neuen Associate, der während des Pilots eintrat.
Vorbereitung des Quartals-Portfolio-Reviews
So wurde gemessen
Vergleich der Vorbereitungszeit für das Quartal unmittelbar vor dem Rollout mit dem ersten Review auf dem neuen System.
Womit es verbunden ist
- Deal-CRM (Pipeline, Due-Diligence-Notizen, Entscheidungsbegründung)
- Geteiltes Laufwerk (Decks, Data Rooms, Board-Materialien)
- Notion (Meeting-Notizen und Partner-Berichte)
- E-Mail (Deal-Flow und Portfolio-Unternehmenskommunikation)
Wo Menschen die Kontrolle behielten
- Der Agent zeigt nur Informationen an, auf die der anfragende Partner oder Associate bereits Zugriff hat.
- Jede Antwort enthält eine Quellenangabe, damit Aussagen geprüft werden können, bevor sie in einem Board-Meeting wiederholt werden.
- Der Agent beantwortet Fragen; er entwirft oder sendet keine Kommunikation an Gründer, LPs oder Portfolio-Unternehmen selbstständig.
- Der erste Monat lief mit einem «Diese Antwort markieren»-Schritt, damit das Team Retrieval-Probleme finden und korrigieren konnte.
Das Problem
Das institutionelle Wissen des Fonds war real, aber verstreut – Due-Diligence-Notizen in der Notion eines Partners, eine aktualisierte Cap-Table vergraben in einem E-Mail-Thread, Portfolio-KPIs aufgeteilt zwischen einem CRM, einer Tabelle und Gründer-Decks. Jede Woche hatte das einen Preis: Associates verloren einen halben Tag vor Partner-Meetings damit, die aktuelle Situation zu rekonstruieren. Neue Associates brauchten Wochen zum Einarbeiten, weil das Muster-Wissen des Fonds in den Köpfen der Partner lebte.
Was sich geändert hat
Die Zeit für die Rekonstruktion von Deal- und Portfolio-Historie vor Meetings sank um rund 80 % – aus einem halben Tag Suchen wurde eine quellenbelegte Antwort in Minuten. Die Einarbeitungszeit neuer Associates sank von mehreren Wochen auf unter eine Woche, und mindestens zweimal gelang es dem Agenten, ein früheres Ablehnungsmemo zu einem Unternehmen aufzuzeigen, das mit einer neuen Runde wiederkehrte.
Was es schwierig gemacht hat
Das Schwierigste waren die Widersprüche. Das Deck eines Gründers nannte eine ARR-Zahl, das eigene Tracking-Sheet eine andere, und ein alter E-Mail-Thread eine dritte. Frühe Antworten nahmen einfach die zuletzt geänderte Quelle – manchmal die veraltete. Wir haben den Agenten so eingestellt, dass er alle drei mit Datumsangaben anzeigt und den Partner entscheiden lässt.
~35% → ~95%
eingehender Anrufe live beantwortet, kein Anrufbeantworter
Ein regionaler Versicherungsmakler mit Privatkundengeschäft und Service für rund 14’000 Versicherungsnehmer
So funktioniert es
Live beantwortete Anrufe in Spitzenfenstern
So wurde gemessen
Aus Anrufprotokollen über vier Wochen nach Rollout, verglichen mit denselben Fenstern im Vormonat.
Zeit von gemeldeter Schaden bis aufgezeichneter Erstmeldung
So wurde gemessen
Basierend auf Zeitstempeln des Schadensystems für Anrufe des Sprachagenten im selben Vierwochen-Fenster.
Durchlaufzeit Terminvereinbarung
So wurde gemessen
Geschätzt aus den Rückrufprotokollen des Vormonats gegenüber direkt während Agentenanrufen gemachten Buchungen.
Womit es verbunden ist
- Policemanagement-System (Deckung, Limits, Zahlungsstatus)
- Schadenmanagement-System (Erstmeldungs-Intake und Schadenakten)
- Agenturkalender und Terminplanung (Berater-Verfügbarkeit und Buchungen)
- Anrufaufzeichnung und Transkriptions-Pipeline
Wo Menschen die Kontrolle behielten
- Der Agent übergibt sofort an einen Menschen bei Verletzungen, Todesfällen, aufgebrachten Anrufern oder dem Wunsch, mit einer Person zu sprechen.
- Der Agent kann Police- und Schadensdaten lesen, kann aber keine Deckung binden, einen Schaden genehmigen, eine Zahlung auslösen oder eine Police ändern.
- Jeder Anruf wird aufgezeichnet und jede Erstmeldung von einem menschlichen Sachbearbeiter überprüft, bevor der Schaden weiterläuft.
- Die Übergabegrenze wurde über drei Wochen anhand echter Anrufaufzeichnungen feinabgestimmt.
Das Problem
Die Telefonleitung des Maklers war sein meistgenutzter und schwächster Kanal. Das Anrufvolumen stieg vorhersehbar – Montagmorgen, Mittagszeiten und 48 Stunden nach jedem lokalen Wetterereignis – und in diesen Fenstern wurden teils nur einer von drei Anrufen live beantwortet. Eine Erstmeldung, die einen Tag im Anrufbeantworter lag, verzögerte die gesamte Schadenabwicklung.
Was sich geändert hat
Die Live-Antwortrate in Spitzenfenstern stieg von etwa 35 % auf rund 95 % – fast jeder Anruf wird nun sofort beantwortet, einschliesslich Anrufen ausserhalb der Geschäftszeiten. Erstmeldungen erfolgen nun beim Anruf selbst, Terminvereinbarungen, die zwei bis drei Tage benötigten, werden beim ersten Anruf gebucht.
Was es schwierig gemacht hat
Das Schwierigste war die Übergabegrenze. In der ersten Woche versuchte der Agent, einen sichtlich aufgebrachten Versicherungsnehmer durch eine Deckungsstreitigkeit zu führen, statt sofort eine Person hinzuzuziehen. Wir setzten den Eskalationsauslöser früher: jedes Zeichen von Frustration oder der Wunsch nach «jemandem», und er übergibt sofort.
100%
der Agentenaktionen protokolliert, genehmigt und überprüfbar
Eine Gesundheitsgruppe mit mehreren ambulanten Standorten und rund 180 Mitarbeitenden
So funktioniert es
Agentenaktionen protokolliert und zuordenbar
So wurde gemessen
Basierend auf der Abdeckung des zentralisierten Audit-Logs über alle drei Piloten am Ende des zehnwöchigen Rollouts.
Abrechnungscode-Änderungen mit menschlicher Genehmigung
So wurde gemessen
Vorher hatte der Abrechnungsassistent direkten Schreibzugriff. Nachher gehen Abrechnungscode-Änderungen immer in eine Genehmigungswarteschlange.
Patientennachrichten ohne aufgezeichneten menschlichen Review-Schritt gesendet
So wurde gemessen
Es gab keine verwendbare frühere Baseline – der Vorher-Zustand hatte keine Aufzeichnung, ob Überprüfung überhaupt stattgefunden hatte.
Womit es verbunden ist
- Patientenakten-System (gezielter Lesezugriff auf nicht-klinische Felder)
- Praxisverwaltungssystem (Terminplanung und Abrechnung)
- Patientennachrichten-Portal
- Zentralisierter Audit-Log zugeordnet auf Compliance-Anforderungen
Wo Menschen die Kontrolle behielten
- Jede Agentenaktion wird mit Wer/Was/Wann/Im-Auftrag-von protokolliert sowie Vorher/Nachher-Zustand für jede Datensatzänderung.
- Der Zugriff des Patientenfragen-Assistenten wurde auf nur die für häufige Fragen benötigten Felder beschränkt.
- Abrechnungscode-Änderungen erfordern menschliche Genehmigung vor Anwendung.
- Keine Patientennachricht wird gesendet, ohne dass ein Mensch sie zuerst überprüft.
Das Problem
Drei separate KI-Piloten waren von verschiedenen Teams über etwa ein Jahr aufgebaut worden, jeder ein echtes Problem lösend – und jeder mit mehr Zugriff und weniger Aufsicht als irgendwer wirklich entschieden hatte. Einer hatte Lesezugriff auf Patientenakten einschliesslich klinischer Notizen, ohne Protokollierung. Ein zweiter hatte Schreibzugriff auf das Praxisverwaltungssystem. Ein dritter entwarf Patientennachrichten ohne Aufzeichnung, was gesendet versus bearbeitet wurde. Zusammen hatten drei Systeme dauerhaften Zugriff auf Gesundheitsdaten, Abrechnung und Patientenkommunikation, ohne Audit-Trails.
Was sich geändert hat
Jede der rund 40’000 Agentenaktionen pro Monat wird nun protokolliert, berechtigt und zuordenbar – der Audit-Log der Governance-Ebene wurde zum primären Nachweis im nächsten Compliance-Review. Im Zwei-Stufen-Modell des Abrechnungsassistenten werden rund 70 % seiner Schreibaktionen direkt ausgeführt, während Abrechnungscode-Änderungen immer in eine Genehmigungswarteschlange gehen – was zwei vorgeschlagene Änderungen auffing, die ein Reviewer korrigierte, bevor sie wirksam wurden.
Was es schwierig gemacht hat
Die Migration des Patientenfragen-Assistenten war am kniffligsten, weil die Einschränkung des Zugriffs einige Workflows brach, auf die das Frontdesk-Team still angewiesen war. Wir verbrachten eine Woche damit, echte Anfragen durchzugehen, um zu unterscheiden, welche ein anderes, engeres Feld benötigten, versus welche tatsächlich hätten nie beantwortet werden sollen.
~25/Woche
Ad-hoc-Anfragen direkt in Slack erledigt, ohne jemanden von der Arbeit abzuziehen
Eine 25-köpfige Produkt- und Engineering-Organisation bei einem Series-A-Startup
So funktioniert es
Zeit für eine Antwort auf eine schnelle «Könnte jemand prüfen...»-Anfrage
So wurde gemessen
Informelle Slack-Reaktionszeitbeobachtungen aus dem Monat vor Rollout verglichen mit protokollierten Agentenreaktionszeiten.
Ad-hoc-Anfragen erledigt ohne jemanden von der Arbeit abzuziehen
So wurde gemessen
Aus dem Slack-Aktivitätslog des Agenten über ein Vierwochen-Fenster gezählt.
Wiederkehrende Kleinkram-Anfragen am Ursprung behoben
So wurde gemessen
Aus der sichtbaren Anfragen-Historie in Slack identifiziert.
Womit es verbunden ist
- Slack / Google Chat (Agent agiert als Workspace-Mitglied)
- Issue-Tracker – Linear/Jira (Status, Kommentare, Historie)
- Git-Repository, CI und interne Admin-/Reporting-Tools (gezielter Lesezugriff; PRs als Entwürfe)
- Geteilte Dokumente (Bearbeitungen als Vorschläge, keine direkten Überschreibungen)
Wo Menschen die Kontrolle behielten
- Jede Änderung an Code, Docs oder Config kommt als Entwurf im normalen Review-Prozess zurück – der Agent schreibt nie direkt in ein Produktionssystem.
- Jede Anfrage und Antwort erfolgt im offenen Slack-Thread, nie in einer DM oder einem versteckten Kanal.
- Der Zugang begann in den ersten zwei Wochen mit reinen Leseabfragen.
- Der Agent lehnt Anfragen ausserhalb seines gezielten Zugangs ab, statt auf andere Wege zu erraten.
Das Problem
Als das Team auf rund 25 Personen wuchs, floss ein stetiger Strom kleiner Anfragen durch Slack – die Anmeldenummern des letzten Monats heraussuchen, prüfen warum ein Ticket feststeckt, Text aktualisieren. Keine war gross genug für eine Roadmap, aber alle benötigten Zugang zu einem bestimmten System, sodass sie auf denselben zwei oder drei Personen landeten. Da es keine echten Kosten hatte, nicht zu antworten, wurden viele kleine aber nützliche Anfragen still nie erledigt.
Was sich geändert hat
Innerhalb eines Monats erledigte der Agent rund 25 Anfragen pro Woche direkt in Slack. Schnelle Nachschlagevörgänge werden nun in unter wenigen Minuten gelöst statt in Minuten bis Tagen. Weil Fragen zu stellen niemanden mehr ihre Zeit kostete, begannen Menschen, die kleinen Dinge anzusprechen, mit denen sie vorher einfach gelebt hatten.
Was es schwierig gemacht hat
Der frühe Fehler war Ton und Umfang. In der ersten Woche beantwortete der Agent manchmal eine vage Anfrage, indem er erriet was gewollt war, und einen vollständigen Bericht postete den niemand verlangt hatte. Wir haben einen Klärungsfragen-Schritt für mehrdeutige Anfragen eingebaut.
~50%
der täglichen Alarme ohne vollständige manuelle Untersuchung geklärt
Das Compliance-Team eines Zahlungs-Fintechs, das Transaktionsaktivitäten für rund 120’000 aktive Konten überwacht
So funktioniert es
Risikoarme Alarme, die ein Analyst ohne Neuaufbau des Falls klären kann
So wurde gemessen
Gemessen als Anteil täglicher Alarme, bei denen der Analyst die Klären-Empfehlung mit nur einer Bestätigungsprüfung akzeptierte.
Alarm-Rückstand älter als 5 Arbeitstage
So wurde gemessen
Rückstandszählung aus dem Fallverwaltungssystem zu Beginn des Pilots und erneut nach acht Wochen.
Übereinstimmung zwischen Agentenempfehlung und endgültiger Analystendisposition
So wurde gemessen
Wöchentlich aus dem Empfehlungslog des Agenten verfolgt.
Womit es verbunden ist
- Transaktionsüberwachungs-/Fallverwaltungssystem (Alarme und Fall-Queues)
- Kernbankenledger (Kontohistorie und Salden)
- KYC- und Onboarding-Unterlagen (Kundenprofil, Risikobewertung)
- Sanktions- und Watchlist-Screening-Feeds
Wo Menschen die Kontrolle behielten
- Der Agent empfiehlt eine Disposition, aber nur ein zugelassener Compliance-Analyst kann einen Alarm schliessen oder einen Bericht einreichen.
- Jede Empfehlung enthält die spezifischen Datenpunkte und Begründungen, sodass der Analyst prüfen statt blind zustimmen kann.
- Der Agent kann kein Geld bewegen, ein Konto einfrieren oder einen Kunden kontaktieren.
- Die Übereinstimmung zwischen Agentenempfehlung und endgültiger Analystendisposition wurde ab der ersten Woche erfasst.
Das Problem
Das Transaktionsüberwachungssystem des Compliance-Teams generierte täglich mehrere Hundert Alarme – von denen die meisten nichts bedeuteten: das Ausgabemuster eines Kunden hatte sich mit einer neuen Stelle geändert, ein Kleinunternehmen hatte einen saisonalen Anstieg, eine Übertragung stimmte zufällig mit einem Watchlist-Namen überein. Für jeden Alarm musste ein Analyst über vier oder fünf separate Systeme prüfen, bevor er überhaupt entscheiden konnte, ob es relevant war. Der Rückstand an Alarmen älter als fünf Arbeitstage war auf rund 600 angewachsen.
Was sich geändert hat
Der Agent nimmt nun jeden Alarm im Moment seines Auslösens auf und stellt ein Untersuchungspaket mit empfohlener Disposition zusammen. Rund die Hälfte aller Alarme ist nun risikoarm genug, dass ein Analyst die Klaren-Empfehlung in ein paar Minuten bestätigen kann – was den Alarm-Rückstand von rund 600 auf etwa 120 innerhalb von zwei Monaten reduzierte.
Was es schwierig gemacht hat
Die frühe Version setzte stark auf Transaktionsgeschwindigkeit und Betragsschwellenwerte, was routinemässig Konten markierte, die schlicht volumenreich waren. Analysten lernten, diese Markierungen zu ignorieren. Wir haben die Bewertung umgebaut, um jedes Konto gegen seine eigene historische Baseline zu vergleichen – rund drei Wochen Analysten-Feedback, um es richtig hinzubekommen.
~70%
der eingehenden NDAs am selben Tag ohne Anwaltsbegutachtung freigegeben
Ein 4-köpfiges internes Rechtsteam, das ein Unternehmen mit rund 300 Mitarbeitenden mit einem stetigen Strom eingehender NDAs und Lieferantenverträge unterstützt
So funktioniert es
Eingehende NDAs/Verträge ohne Anwaltsbegutachtung freigegeben
So wurde gemessen
Über einen sechswöchigen Pilot gemessen, gegen die Baseline des Vormonats.
Zeit zur Freigabe einer Routine-NDA im Playbook
So wurde gemessen
Durchschnittliche Durchlaufzeit im Vertrags-Tool für den Monat vor Rollout verglichen mit dem sechswöchigen Pilot.
Anwaltszeit für Routine-Dokumentenprüfung pro Woche
So wurde gemessen
Selbstberichtet von den vier Anwälten in einer wöchentlichen Zeitschätzung, gemittelt über den zweiten Monat des Pilots.
Womit es verbunden ist
- Vertrags-Management-/E-Signatur-System (eingehende Dokumente und Ausführung)
- Rechts-Playbook und Klauselbibliothek (genehmigte Positionen und Ausweichformulierungen)
- E-Mail (Intake von Vertrieb, Procurement und Gegenparteien)
- CRM oder Procurement-System (Deal-Kontext zu jedem Vertrag)
Wo Menschen die Kontrolle behielten
- Der Agent gibt ein Dokument nur frei, wenn jede Klausel exakt mit dem Playbook übereinstimmt – eine einzige Abweichung leitet das gesamte Dokument an einen Anwalt weiter.
- Jede vom Agenten vorgeschlagene Korrektur zitiert die spezifische Playbook-Position, sodass der Anwalt Begründungen prüft, nicht errät.
- Der Agent kann nicht gegenzeichnen oder ein ausgefertigtes Dokument senden.
- Der erste Monat lief mit einem Anwalt, der eine Stichprobe der freigegebenen Dokumente spot-checkte.
Das Problem
Der Eingang des Rechtsteams war eine Mischung aus dem gelegentlichen Vertrag, der wirklich das Urteilsvermögen eines Anwalts erforderte, und einem stetigen Strom von NDAs, die klauselweise fast identisch mit der eigenen Vorlage des Unternehmens waren. Aber beide kamen in derselben Queue an, und ein Anwalt musste das gesamte Dokument in jedem Fall lesen. Routine-NDAs konnten zwei bis vier Tage warten, bis jemand bestätigte, was meistens ohnehin schon stimmte.
Was sich geändert hat
Der Agent prüft nun jede eingehende NDA und jeden Lieferantenvertrag im Moment des Eingangs. Wenn ein Dokument passt, gibt der Agent es frei und benachrichtigt den Anforderer direkt – kein Anwalt involviert. Rund 70 % der eingehenden NDAs werden nun am selben Tag freigegeben, und die Anwaltszeit für Routine-Dokumentenprüfung sank von rund 12 auf etwa 3 Stunden pro Woche.
Was es schwierig gemacht hat
Das Schwierigste war, dem Agenten den Unterschied zu beibringen zwischen einer Klausel, die anders formuliert war aber dasselbe bedeutete, und einer echten substantiellen Abweichung. Das trieb die Ausserhalb-des-Playbooks-Rate in der ersten Woche auf fast die Hälfte. Wir verbrachten zwei Wochen damit, eine Bibliothek gleichwertiger Formulierungen aufzubauen, bevor sich die Freigaberate auf rund 70 % stabilisierte.
Klein starten, ernsthaft bauen