Operating Leverage
|

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.

Technologie

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 31 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

Technologie

Engineering-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 Capital

VC 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 TagMinuten

Einarbeitungszeit neuer Associates auf Portfolio-Wissen: mehrere Wochenunter einer Woche

Vorbereitung des Quartals-Portfolio-Reviews: mehrtägige DatensammlungArbeitssession, 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

Versicherung

Versicherungs-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 Arbeitstagim selben Anruf

Durchlaufzeit Terminvereinbarung: 2–3 Tage Telefonatebeim ersten Anruf gebucht

Relevant, wenn

Ihr Telefonkanal ist Ihr meistgenutzter und schwächster Kanal – besonders ausserhalb der Geschäftszeiten.

Fallstudie lesen

Gesundheitswesen

Gesundheitswesen-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 erfasst0%

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

Technologie

Slack/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 Tagemeist unter wenigen Minuten

Ad-hoc-Anfragen erledigt ohne jemanden von der Arbeit abzuziehen: 0~25/Woche

Wiederkehrende Kleinkram-Anfragen am Ursprung behoben: 02 (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

Fintech

AML/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

Rechtswesen

NDA- 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 Tageam 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

1Ticket geht ein
2Agent holt CRM-Historie und Richtliniendokumente
3Entwirft Priorität, Weiterleitung und Antwort
4Mensch prüft, bearbeitet, sendet
5Eskalationspaket bei Bedarf angehängt

Zeit bis zur ersten Reaktion

~5.5 Stunden~2 Stunden
So wurde gemessen

Gemessen über die allgemeine Eingangs-Queue über sechs Wochen; P1-Incidents ausgeschlossen.

Tickets mit Eskalations-Nacharbeit

1 von 31 von 8
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

~10 Std./Woche~2 Std./Woche
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

1Bug wird erfasst
2Agent reproduziert und scannt Code, Logs, Historie
3Postet Analysezusammenfassung
4Öffnet PR-Entwurf bei gesicherter Reproduktion
5Ingenieur überprüft; normaler CI- und Review-Prozess

Analysezeit pro Bug

~1–3 Stunden~15 Min. Review
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

0%~40%
So wurde gemessen

«Verwendbar» bedeutete, dass der Ingenieur den Entwurf weiterentwickelte statt ihn zu verwerfen.

Engineering-Zeit pro Monat zurückgewonnen

0 Std.~15 Std./Ingenieur
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

1Frage gestellt (z.B. «Was hat sich dieses Quartal geändert?»)
2Agent durchsucht CRM, Laufwerk, Notion, E-Mail
3Gleicht Zahlen über Quellen ab
4Antwort mit Zitaten zurückgegeben, Widersprüche markiert
5Partner verifiziert und nutzt in Meeting

Zeit zur Rekonstruktion der Deal-/Portfolio-Historie vor einem Meeting

~halber TagMinuten
So wurde gemessen

Basierend auf Associate-Zeitprotokollen für Partner-Meeting-Vorbereitung über eine sechswöchige Stichprobe.

Einarbeitungszeit neuer Associates auf Portfolio-Wissen

mehrere Wochenunter einer Woche
So wurde gemessen

Gemessen für den einen neuen Associate, der während des Pilots eintrat.

Vorbereitung des Quartals-Portfolio-Reviews

mehrtägige DatensammlungArbeitssession, Daten vorab zusammengestellt
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

1Anruf eingehend
2Agent nimmt entgegen, identifiziert Versicherungsnehmer
3Ruft Police-/Schadensystem auf
4Bearbeitet Erstmeldung, Statusabfrage oder Terminvereinbarung
5Übergibt an Menschen ausserhalb seines Kompetenzbereichs

Live beantwortete Anrufe in Spitzenfenstern

~35%~95%
So wurde gemessen

Aus Anrufprotokollen über vier Wochen nach Rollout, verglichen mit denselben Fenstern im Vormonat.

Zeit von gemeldeter Schaden bis aufgezeichneter Erstmeldung

bis zu 1 Arbeitstagim selben Anruf
So wurde gemessen

Basierend auf Zeitstempeln des Schadensystems für Anrufe des Sprachagenten im selben Vierwochen-Fenster.

Durchlaufzeit Terminvereinbarung

2–3 Tage Telefonatebeim ersten Anruf gebucht
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

1Patienten-/Mitarbeiteraktion löst einen Agenten aus
2Sandbox-Ausführung prüft Berechtigungsstufe
3Geringes Risiko: Direkte Ausführung + Protokollierung
4Höheres Risiko: Vorgeschlagene Änderung in Genehmigungswarteschlange
5Mitarbeiter genehmigt/bearbeitet; Audit-Log zeichnet alles auf

Agentenaktionen protokolliert und zuordenbar

0%100%
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

0% (direkter Schreibzugriff)~100% (zweistufige 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

nicht erfasst0%
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

1Jemand @-erwähnt den Agenten mit einer Anfrage
2Agent klassifiziert: schnelle Suche vs. Hintergrundaufgabe
3Schnell: direkt im Thread beantwortet
4Hintergrund: arbeitet asynchron, postet Ergebnis wenn fertig
5Systemänderungen von Menschen über normalen Review-Prozess angewendet

Zeit für eine Antwort auf eine schnelle «Könnte jemand prüfen...»-Anfrage

Minuten bis Tagemeist unter wenigen Minuten
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

0~25/Woche
So wurde gemessen

Aus dem Slack-Aktivitätslog des Agenten über ein Vierwochen-Fenster gezählt.

Wiederkehrende Kleinkram-Anfragen am Ursprung behoben

02 (in sechs Wochen)
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

1Transaktionsüberwachungssystem löst Alarm aus
2Agent zieht Kontohistorie, KYC-Profil, Verbundparteien-Daten, frühere Alarme
3Erstellt Untersuchungspaket mit empfohlener Disposition
4Analyst überprüft Paket, bestätigt oder überschreibt
5Entscheidung und Begründung in Fallakte protokolliert

Risikoarme Alarme, die ein Analyst ohne Neuaufbau des Falls klären kann

0%~50%
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

~600~120
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

n/a (keine Agentenempfehlung vorhanden)~85% (von ~55% in Woche eins)
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

1NDA oder Lieferantenvertrag per E-Mail oder Vertrags-Tool eingehend
2Agent vergleicht jede Klausel gegen das Rechts-Playbook
3Im Playbook: Agent gibt frei und informiert Anforderer
4Ausserhalb des Playbooks: Agent entwirft Korrekturen und markiert Abweichungen
5Anwalt prüft nur die markierten Punkte und gibt frei

Eingehende NDAs/Verträge ohne Anwaltsbegutachtung freigegeben

0%~70%
So wurde gemessen

Über einen sechswöchigen Pilot gemessen, gegen die Baseline des Vormonats.

Zeit zur Freigabe einer Routine-NDA im Playbook

2–4 Tageam selben Tag (meist innerhalb von Stunden)
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

~12 Std./Woche~3 Std./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

Bringen Sie Ihren teuersten Workflow mit. Gehen Sie mit einem priorisierten Plan, wo KI zuerst auszahlt.