Was wir nicht automatisieren
Ein Kunde bat uns, einen Schritt zu automatisieren, der seine Mitarbeiter etwa vierzig Sekunden kostet. Wir haben abgelehnt, und der Grund ist derselbe, der Assistenten-Benchmarks unangenehm zu lesen macht.
Die Vierzig-Sekunden-Aufgabe
Der Schritt war die Entscheidung, ob eine eingehende Beschwerde in die technische oder die kaufmännische Warteschlange gehört. Die Mitarbeiter erledigten das in Sekunden, allein aus dem Text, scheinbar ohne nachzudenken. Es sah nach dem am besten automatisierbaren Teil des Prozesses aus.
Beim Zusehen zeigte sich, dass die Zuordnung sich auf Dinge stützte, die im Text nicht stehen: welcher Kunde das ist, was bei seinem letzten Auftrag passierte, ob die Formulierung nach Eskalation klingt bei jemandem, der sonst geduldig ist. Nichts davon liegt in einem System, das ein Assistent abfragen könnte.
Warum kurze Aufgaben in die Irre führen
Dauer ist ein schlechter Näherungswert für Schwierigkeit, und sie führt in eine bestimmte Richtung in die Irre: Gerade die Aufgaben, die Menschen am schnellsten erledigen, stützen sich oft am stärksten auf Kontext, dessen Nutzung ihnen gar nicht auffällt.
Mialon und Kollegen haben einen Benchmark genau um diese Asymmetrie gebaut, mit Fragen, die für Menschen konzeptionell einfach und für Assistenten schwer sind. Wir lesen ihn weniger als Rangliste denn als Beschreibung der Lücke, der wir in Scoping-Gesprächen immer wieder begegnen.
Die drei Prüfungen
Erstens: Lässt sich die Entscheidung aus Daten treffen, die in einem System existieren? Hängt sie daran, den Kunden zu kennen, und steckt dieses Wissen in jemandes Kopf, wird die Automatisierung es annähern — und an den Rändern selbstsicher danebenliegen.
Zweitens: Ist der Fehler sichtbar? Eine falsch geroutete Beschwerde fällt binnen eines Tages auf. Eine fein danebenliegende sitzt in der richtigen Warteschlange mit falscher Priorität und fällt niemandem auf. Drittens: Was kostet ein Fehler? Wir automatisieren bereitwillig, wo Fehler billig und sichtbar sind, und zögernd, wo sie keines von beidem sind.
| Wir automatisieren | Bleibt beim Menschen |
|---|---|
| Entscheidung folgt aus vorhandenen Daten | Entscheidung braucht unerfassten Kontext |
| Fehler zeigen sich schnell | Fehler sind still oder verzögert |
| Falschliegen ist reparabel | Falschliegen erreicht Kunden oder Aufsicht |
| Hohes Volumen, stabile Form | Selten, verschieden, ermessensbehaftet |
Was wir stattdessen gebaut haben
Wir haben die Teile automatisiert, die die Prüfungen bestanden. Der Assistent extrahiert die strukturierten Fakten aus der Beschwerde, schlägt Auftrag und letzten Kontakt nach und legt alles zusammen mit einer vorgeschlagenen Warteschlange und seiner Begründung vor. Entschieden wird weiterhin vom Menschen.
Der messbare Effekt lag bei der Entscheidungsdauer, nicht bei der Personalstärke: Aus vierzig Sekunden wurden etwa fünfzehn, und diese fünfzehn gehen in Urteil statt in Nachschlagen über drei Systeme.
Warum die Liste gewachsen ist
Wir hatten erwartet, dass die Ablehnungsliste schrumpft, während die Modelle besser werden. Sie ist gewachsen — weil unser Zuschnitt besser wurde, nicht weil die Modelle schlechter wurden. Früh haben wir Dinge automatisiert, die wir nicht hätten automatisieren sollen, und es aus Vorfällen gelernt.
Die Zugänge sind überwiegend Fälle, in denen Falschliegen still bleibt. Diese Kategorie hat sich als wichtiger erwiesen als Schwierigkeit, und sie wird von einem stärkeren Modell nicht behoben.
Was wir nicht behaupten
Wir behaupten nicht, diese Aufgaben seien dauerhaft unerreichbar. Mehrere bestünden die erste Prüfung schon morgen, wenn der nötige Kontext in einem System erfasst wäre — und manchmal ist genau diese Erfassung das richtige Projekt, nicht der Assistent.
Wir verkaufen es auch nicht als Vorsicht um ihrer selbst willen. Arbeit abzulehnen kostet uns etwas. Wir tun es, weil ein System, das unsichtbar falsch liegt, schlechter ist als eines, das weniger kann.