Vom Pricing-Review zum Pricing-Assistenten: Eine Woche RevMan, wenn der erste Durchgang vom Agenten kommt

28. Mai 2026Maurice8 min

Ein monatliches Pricing-Review hat einen mittelgrossen Schweizer Betrieb früher fast eine ganze Woche gekostet: drei Tage Daten ziehen, einen Tag beurteilen, einen halben Tag aufschreiben. Die ersten drei Tage haben wir als Agent-Run neu aufgebaut, die letzten zwei beim Menschen gelassen, und das neue Modell läuft seit sechs Monaten in zwei Branchen. Hier steht, was sich wirklich geändert hat — und wo der Agent nach wie vor an die kurze Leine gehört.

Und nein, das ist ganz bewusst keine Chatbot-Geschichte.

Wie die Woche früher aussah

Stellen Sie sich ein Schweizer KMU vor: 80–250 SKUs oder Leistungslinien, ein monatlicher oder quartalsweiser Pricing-Rhythmus und die übliche Datenlage. Ein ERP, ein CRM, zwei bis drei Wettbewerber-Quellen, öffentliche Statistik vom BFS, ein Sharepoint-Ordner voller alter Decks. Eine typische Woche, vorher:

Montag bis Mittwoch: ziehen. Exporte aus dem ERP, Screenshots von Wettbewerber-Seiten, Einheiten vereinheitlichen, Spalten erneut geradeziehen. Drei volle Tage, fast alles mechanisch, fast nichts davon dort, wo die Operatorin tatsächlich Wert stiftet.
Donnerstag: beurteilen. Der eine Tag, an dem das Domänenwissen wirklich zum Zug kommt — welche Linien man auf die Marge verteidigt, welche man neu positioniert, wo die Elastizität real ist und wo das Signal vom letzten Quartal bloss Rauschen war.
Freitagvormittag: aufschreiben. Ein Deck oder ein Memo mit den Empfehlungen, den Belegtabellen und je zwei Absätzen Begründung pro Empfehlung.

Das Verhältnis ist das Problem. Fünf Tage, davon einer für die Arbeit, für die der Kunde tatsächlich zahlt.

Was wir dem Agenten übergeben

Der erste Durchgang — Montag bis Mittwoch — läuft heute als Agent-Run. So sieht das generisch aus:

Wettbewerber scrapen und vereinheitlichen. Ein Browser-Agent ruft die 6–12 öffentlichen Wettbewerber-Quellen auf, zieht Preise und Bundle-Strukturen, bringt die Einheiten auf einen Nenner (pro Monat, pro Liter, pro Kilometer, pro Pflegestunde) und schreibt das Ergebnis in eine strukturierte Tabelle. Bei Wettbewerbern ohne öffentliche Seite greift der Agent auf den letzten gespeicherten Snapshot in unserem internen Store zurück, statt erneut zu scrapen.
Benchmark aufbauen. Öffentliche Datensätze des BFS, Branchenreports des FSO und — wo vorhanden — das Bulletin des passenden Branchenverbands (Spitex Schweiz, Auto-Schweiz, Suva-Unfallquoten) führt der Agent in dieselben Einheiten zusammen. Jede Quelle, die älter als 90 Tage ist, wird markiert.
Interne Daten zusammenführen. Umsatz nach SKU bzw. Leistungslinie aus dem ERP, Kundenmix aus dem CRM, vertragsspezifische Rabatte, wo es sie gibt. Alles fliesst in eine einzige Langform-Tabelle, die die Operatorin direkt öffnen kann.
Erste Szenarien. Drei Pricing-Szenarien samt P&L-Wirkung: halten, +3%, segmentiert (+5% auf preisunempfindliche Segmente, sonst halten). Der Agent legt seine Rechnung offen — die Elastizitätsannahme, die angenommenen Segmentanteile, die Volumen-Baseline.

Der Stack darunter ist unspektakulär: Claude als Reasoning-Modell, ein n8n-Flow für die Orchestrierung, eine Postgres für die Langform-Tabelle, die Werkzeuge des Agenten hinter einem einzigen MCP-Server. Die ganze Pipeline läuft in einem in der Schweiz gehosteten Container; die LLM-Aufrufe gehen über AWS Frankfurt an Anthropic, mit Zero-Retention-Klausel. An der Architektur ist nichts exotisch. Die Disziplin liegt darin, was wir den Agenten noch nicht tun lassen.

Wo die Operatorin eingebunden bleibt

Drei Entscheidungen gehören nie dem Agenten.

Floor-Pricing bei strategischen Accounts. Die 8–15 Accounts, bei denen der Beziehungsverlauf schwerer wiegt als die Stückmarge, sieht der Agent gar nicht und gibt dazu auch keine Empfehlung ab. Die laufen separat und werden von Hand entschieden.
Ausnahmen behandeln. Markiert der Agent einen Wettbewerberpreis, der sich innerhalb eines Monats um 18% bewegt hat, steckt fast immer ein Datenfehler oder eine einmalige Promotion dahinter — kein Marktsignal. Diese Einschätzung trifft die Operatorin, nicht das Modell.
Das «wie sagen wir das dem Kunden». Entwerfen darf der Agent. Welchen Ton die Beziehung in diesem Quartal verträgt, entscheidet er nicht. Das bleibt bei der Person, die mit dem Kunden am Telefon war.

Das Muster zählt: Der Agent darf alles tun, was umkehrbar und messbar ist. Jeder unumkehrbare Schritt — das Übersteuern bei Strategie-Accounts, das Urteil über Ausnahmen, die Formulierung an den Kunden — läuft über eine menschliche Warteschlange. Diese Warteschlange ist bewusst kurz gehalten. Wächst sie in einer Woche über 20 Einträge, fragt der Agent zu viel: Dann muss man den Workflow enger fassen, nicht mehr Prüferinnen einsetzen.

Wie das Ergebnis am Dienstagmorgen aussieht

Genau hier scheitern die meisten «AI-Report»-Projekte. Das Liefergut ist kein PDF, das im Posteingang landet. Es ist ein Dashboard, das die Operatorin am Dienstag um 08:00 Uhr öffnet und aus dem heraus sie handelt.

Konkret:

Eine Sicht. Eine Langform-Tabelle über jede SKU oder Leistungslinie: der Preis dieses Monats, die Empfehlung des Agenten, die Belege gleich daneben (Wettbewerber-Zeile, Benchmark-Zeile, Umsatztrend, Szenario-P&L).
Drei Farben. Grün, wenn der Agent zuversichtlich ist und die Änderung klein. Gelb, wenn die Zuversicht mittel ist oder die Änderung über 3% liegt. Rot, wenn der Agent vor einer Bewegung eine menschliche Entscheidung will — Ausnahme, Strategie-Account oder fehlende Daten.
Ein Knopf pro Zeile. «Annehmen und für die nächste Preislisten-Publikation einreihen», «Mit Notiz zurückgeben», «Für Manager-Review parken». Jeder Klick wird mit Zeitstempel, Operatorin und Begründung protokolliert.

Genutzt wird das Dashboard mit dem Knopf. Nicht genutzt wird das 40-seitige Deck, das der Agent ohne Weiteres produzieren könnte und das niemand liest. Output zügeln. Das Artefakt ist der Workflow, nicht der Text.

Drei Dinge, mit denen wir auf die Nase gefallen sind

Nach sechs Monaten haben drei Fehlerformen einen Namen verdient.

Übereifrige Vereinheitlichung. Anfangs hat der Agent das «erste drei Monate gratis» eines Wettbewerbers hilfreich als Fussnote weggerechnet. Es stellte sich heraus, dass der Wettbewerber das stillschweigend dauerhaft gemacht hatte — und wir haben zwei Monate echtes Signal verpasst. Fix: Jeder Vereinheitlichungsschritt erzeugt heute ein ausdrückliches «Was-ich-weggelassen-habe»-Log, und die Operatorin geht dieses Log einmal pro Woche durch.
Die menschliche Review-Warteschlange ist explodiert. Im zweiten Monat lag der Gelb-Anteil bei 35% — der Agent hat alles abgesichert, was er noch nie gesehen hatte. Fix: Wir haben die Zuversichtsschwellen angezogen, seine Elastizitätsannahmen verengt und ihm untersagt, «Datenfrische» allein als Eskalationsgrund zu nehmen. Heute liegt der Gelb-Anteil bei rund 9%.
Die Kosten pro Run haben uns einmal kalt erwischt. Ein einzelner Review-Run kostete CHF 6.40 an API-Spend, als die Wettbewerber-Seiten eine schlechte Scrape-Woche hatten und der Agent aggressiv neu versuchte. Wir haben ein hartes Retry-Limit und einen Budget-Alert pro Run gesetzt. Im Normalbetrieb liegen die Kosten bei CHF 1–2 pro monatlichem Run. Die Lehre ist nicht, dass es teuer ist — die Lehre ist, dass ein Budget-Wächter da sein muss, bevor man es herausfindet.

Nichts davon ist exotisch. Es ist das Operations-Handwerk von allem, was echte Daten anfasst. In keiner Keynote kommen diese Punkte vor; jedes Team läuft im zweiten Monat hinein.

Was sich für die Operatorin tatsächlich ändert

Zwei Tage beurteilen statt einem. Das ist die Schlagzeile.

Die mechanischen 60% der Woche — ziehen, vereinheitlichen, zusammenführen, ersten Entwurf bauen — laufen über Nacht, allein mit dem Agenten, und liegen am Dienstagmorgen als Dashboard bereit. Die Operatorin hat jetzt zwei volle Tage für den Teil, der sich auszahlt: welche Linien sie verteidigt, wo die Elastizität real ist, welche strategischen Accounts ein anderes Gespräch verdienen und wie sich die Empfehlung gegenüber dem Kunden einbetten lässt.

Das verdoppelt die Zeit für die teuren 40% der Arbeit. Keine Behauptung von 10× mehr Produktivität. Eine saubere Verschiebung dorthin, wo das Gewicht der Woche liegt.

Wenn Sie als Operations-Leitung eines Schweizer KMU mitlesen

Zwei praktische Mitnahmen.

Erstens: Die Frage Eigenbau gegen Zukauf ist enger, als sie aussieht. Für einen wiederkehrenden, vertikalen Pricing-Workflow mit benannten Datenquellen sind das vier bis sechs Wochen Arbeit. Das Ergebnis bleibt in Ihrer eigenen Tenancy und kostet im Betrieb einen niedrigen dreistelligen CHF-Betrag pro Monat. Es gibt keine fertige Pricing-Assistant-SaaS, die Ihre Branchen auf diesem Niveau kennt, und so bald wird es auch keine geben — der lange Rattenschwanz an Sonderfällen ist zu lang. Die richtige Frage lautet nicht «welcher Anbieter», sondern «welcher eine Workflow zuerst, und wer betreut das Dashboard».

Zweitens: Das Liefergut ist das Dashboard, nicht der Bericht. Wenn Ihr KI-Pilot mit einem schön geschriebenen Dokument endet, das am Dienstagmorgen niemand öffnet, hat sich am Workflow nichts geändert. Dann ist der Agent bloss zum eloquenteren Praktikanten geworden. Die Verschiebung passiert erst, wenn das Artefakt ein Interface ist, aus dem die Operatorin handelt — mit der Arbeit des Agenten sichtbar gleich daneben.

Wenn Sie einen wiederkehrenden Pricing-, Benchmark- oder Wettbewerbs-Review-Workflow haben, bei dem das Verhältnis von Ziehen zu Beurteilen so aussieht wie oben, dann ist der erste Durchgang die einfachste Woche Arbeit, die Sie Ihrem Team zurückgeben können. Schreiben Sie uns kurz — eine Zeile reicht.