Unser Kunde wollte einen Chatbot. Wir haben stattdessen seinen Angebotsdesk gebaut.

Ein Händler, mit dem wir gearbeitet haben, bekommt jeden Tag ein paar hundert Angebotsanfragen. Sie kommen per E-Mail, als PDF, als Tabelle ohne einheitliches Schema und gelegentlich als Foto einer handgeschriebenen Liste, aufgenommen in der Lagerhalle. Jemand liest jede einzelne, überlegt, welche Artikelnummern der Kunde wirklich meint, prüft den Bestand, wendet die richtige Vertragspreisstufe an und schickt ein Angebot zurück. Die Durchlaufzeit beträgt einen Tag, manchmal zwei. Ein nennenswerter Teil der Anfragen wird nie beantwortet, weil die Warteschlange länger ist als der Tag.

Als wir den Betriebsleiter fragten, was er automatisieren wolle, kam die Antwort schnell: einen Chatbot für die Website.

Nicht, weil der Chatbot wichtig war. Sondern weil der Chatbot das war, was nach KI aussah. Der Angebotsdesk sah nicht nach KI aus. Er sah aus wie zwei Leute, die das seit neun Jahren machen und sehr gut darin sind.

Wir haben stattdessen das Angebotssystem gebaut. Die Durchlaufzeit sank von Tagen auf Minuten, und die Anfragen, die früher hinten aus der Warteschlange fielen, werden jetzt beantwortet. Wir dürfen die Zahlen des Kunden nicht veröffentlichen, und Richtungsaussagen sind weniger wert als Zahlen. Nehmen Sie das also als Kontext für das Engineering, nicht als Beweis. Was folgt, ist die Funktionsweise des Systems, und die können Sie selbst beurteilen.

Arbeit, die nach Menschen aussieht, besteht meist aus Regeln

Im März 2026 veröffentlichte Julien Bek, Investor bei der Venture-Firma Sequoia Capital, einen Essay mit dem Titel Services: The New Software. Sein Argument, das weit über Investorenkreise hinaus Verbreitung fand, lautet: Der eigentliche Gewinn von KI liegt nicht im Verkauf von Software-Werkzeugen, sondern darin, die Arbeit selbst zu erledigen. Er gibt dem Chatbot-Muster von oben auch ein Vokabular, das wir seither ständig benutzen.

Bek teilt professionelle Arbeit in zwei Hälften. Intelligenz ist der Teil mit Regeln, so komplex sie auch sein mögen: eine Spezifikation in Code übersetzen, eine klinische Notiz einem Abrechnungscode zuordnen, eine unsaubere Anfrage gegen einen Katalog lesen. Urteilsvermögen ist der Teil, der auf Geschmack und jahrelanger Mustererkennung beruht: was als Nächstes gebaut wird, ob man beim Preis nachgibt, um einen Kunden zu halten. Seine These: Modelle können den größten Teil der Intelligenzarbeit inzwischen allein erledigen. Unsere Erfahrung im Produktivbetrieb bestätigt das, mit einer Bedingung, die alles entscheidet: Es gilt nur dort, wo man das Ergebnis prüfen kann.

Legt man diese Teilung über den Angebotsdesk, verändert sich das Bild. Eine verstümmelte Anfrage gegen einen bekannten Katalog zu deuten ist Mustererkennung nach Regeln. Preisfindung ist ein Nachschlagen mit Bedingungen. Das echte Urteilsvermögen, ob man für einen strategischen Kunden beim Preis nachgibt, ist eine dünne Scheibe ganz am Ende des Prozesses, und genau dort kann ein Mensch sie verantworten. Neun Jahre Können waren echt. Das meiste davon war trotzdem automatisierbar, und niemand im Unternehmen konnte das sehen, weil die Arbeit ein Gesicht hatte.

Das sei deutlich gesagt: Die beiden arbeiten noch dort. Sie sind in die Prüfwarteschlange und zu den Ausnahmen gewechselt, also zu dem Teil der Arbeit, der immer der schwierigste war und durch das Volumen an den Rand gedrängt wurde. Das war die Entscheidung des Kunden, keine Folge unserer Arbeit, und wir hätten das System anders gebaut, wenn der Plan gewesen wäre, den Desk abzuschaffen. Ein System, das aus Korrekturen lernt, braucht die Menschen, die wissen, wie richtig aussieht.

Was wir tatsächlich gebaut haben

Nichts an dem System ist exotisch, und genau das ist der Punkt.

Die Eingangsverarbeitung normalisiert E-Mail-, PDF- und Tabelleneingaben in ein einziges Anfrageschema. Ein Modell übernimmt die Extraktion, und eine Validierungsschicht weist alles Fehlerhafte ab, bevor es weiterwandert. Der Katalogabgleich ist eine Suche gegen den Artikelstamm, abgestimmt auf die Kurzschreibweisen, die Kunden tatsächlich tippen, denn kein Kunde auf der Welt schreibt Artikelnummern so, wie das ERP sie speichert. Die Preisfindung ist deterministischer Code. Das Modell erfindet nie eine Zahl, niemals.

Jede Ausgabe trägt einen Konfidenzwert. Alles unter der Schwelle geht in eine menschliche Prüfwarteschlange statt zum Kunden, und die dort vorgenommenen Korrekturen werden zum Testdatensatz, der uns sagt, ob das System wirklich besser wird oder sich nur bewegt.

Wer diese Liste als Engineer liest, merkt: Da ist keine neuartige Technik drin. Suche, Extraktion, Validierung, Schwellenwerte. Das ist der ehrliche Stand der meisten produktiven KI, und die Schwierigkeit lag nie in den Bausteinen. Sie lag darin zu lernen, welche der fünfzig Preisausnahmen des Kunden echte Regeln waren und welche die Gewohnheit einer einzelnen Person, und darin, dass Artikelstamm und Bestandssystem oft genug voneinander abwichen, um zu stören.

Die harte Engineering-Arbeit war die Prüfbarkeit: günstig feststellen zu können, ob ein erzeugtes Angebot korrekt ist, bevor ein Kunde es sieht. Wenn Sie das für einen Workflow nicht können, haben Sie noch kein Automatisierungsproblem. Sie haben ein Messproblem, und das ist zuerst zu lösen. Diese Frage entscheidet, ob ein Projekt den Kontakt mit dem Produktivbetrieb überlebt, und fast alle überspringen sie.

Warum kein Anbieter gekommen wäre

Beks Essay endet mit einer Karte von Dienstleistungsmärkten, die reif dafür sind, von KI-Start-ups angegriffen zu werden: Versicherungsvermittlung, Schadenregulierung, Steuern, IT-Managed-Services. Diese Märkte haben gemeinsam, dass sie groß, fragmentiert und standardisiert genug sind, um ein venturefinanziertes Unternehmen zu tragen. Das ist genau der richtige Filter, wenn man einen Fonds führt. Es ist der falsche Filter, wenn man ein Operations-Team führt, und zwei Dinge fallen sofort durch.

Das Erste ist Arbeit, die Unternehmen im Haus behalten haben. Eine ausgelagerte Aufgabe hat eine Budgetzeile, die man ersetzen kann, und einen Käufer, der bereits für ein Ergebnis zahlt, was den Verkauf leicht macht. Aber das ist eine Aussage über die Leichtigkeit des Verkaufs, nicht darüber, wo der Wert sitzt. Ein Betreiber besitzt die Gewinn- und Verlustrechnung bereits und braucht keine Budgetzeile, die er verdrängen müsste.

Das Zweite sind ganze Branchen. Fertigung, Handel, Fracht, Außendienst und Großhandel fehlen auf der Karte, nicht weil der Wert klein wäre, sondern weil die Workflows zwischen Unternehmen nicht standardisiert sind. Es gibt keine Version von „Entwirf eine Geheimhaltungsvereinbarung“, die in zehntausend Firmen dasselbe bedeutet. Der Angebotsprozess jedes Händlers ist eine Funktion seines eigenen Katalogs, seines eigenen ERP, seiner eigenen Vertragsbedingungen und dreier Ausnahmen, die im Kopf einer Person leben.

Diese Heterogenität ist der Grund, warum kein Start-up den Angebotsdesk zum Produkt machen wird. Sie ist auch der Grund, warum das System, einmal gebaut, Ihres bleibt. Jede Korrektur, jeder Sonderfall, jede Kundeneigenheit, die es aufnimmt, macht es spezifischer für Ihren Betrieb und für andere schwerer nachzubauen.

Ihren eigenen Angebotsdesk finden

Drei Fragen haben bei diesem Kunden die Priorisierung erledigt, und sie tun es bei den meisten.

Wie viel der Aufgabe sind Regeln, die auf Eingaben angewendet werden, und wie viel braucht Kontext, den ein Modell nicht haben kann? Seien Sie hier ehrlich: Menschen überschätzen das Urteilsvermögen in ihrer eigenen Arbeit und unterschätzen es in der aller anderen.

Können Sie das Ergebnis günstig prüfen? Aus den genannten Gründen ist das die Frage, die entscheidet, ob überhaupt etwas gebaut wird.

Und wie oft kommt die Aufgabe vor? Vierhundertmal am Tag summiert sich. Zweimal im Monat ist eine Ablenkung, so laut sich jemand auch darüber ärgert.

So sortiert ist das richtige erste System meist offensichtlich, und meist nicht das aus der Präsentation. Wo eine Kategorie standardisiert genug ist, dass jemand sie zum Produkt gemacht hat, kaufen Sie es. Überall sonst, und für die meisten operativen Unternehmen sitzt dort der Großteil des Werts, muss das System auf Ihren Daten, Ihrem ERP und Ihren Regeln gebaut werden, von Engineers, die lange genug im Betrieb sitzen, um zu lernen, wie die Arbeit wirklich passiert.

Das Schwierige waren nie die Modelle. Es ist das Wissen, auf welchen Workflow man sie richtet, und das lässt sich aus der Ferne nicht wissen.