← Blog

Vom Pricing-Review zum Pricing-Assistenten: Eine Woche RevMan-Arbeit, wenn ein Agent den ersten Durchgang macht

28. Mai 2026Maurice8 min

Ein monatliches Pricing-Review für einen mittleren Schweizer Betrieb fraß früher fast die ganze Woche. Drei Tage Daten ziehen, ein Tag Beurteilung, ein halber Tag Aufschrieb. Wir haben die ersten drei Tage als Agent-Run neu gebaut, die letzten zwei beim Menschen gelassen und die neue Form sechs Monate lang in zwei Branchen gefahren. Hier steht, was sich wirklich geändert hat — und wo der Agent weiterhin an die Leine gehört.

Es ist, ganz bewusst, keine Chatbot-Geschichte.

Wie die Woche aussah

Nehmen Sie ein Schweizer KMU mit 80–250 SKUs oder Leistungslinien, einem monatlichen oder quartalsweisen Pricing-Rhythmus und der üblichen Datenverteilung: ein ERP, ein CRM, zwei oder drei Wettbewerber-Quellen, öffentliche Statistik vom BFS, ein Sharepoint-Ordner mit historischen Decks. Eine typische Woche, vorher:

  • Montag–Mittwoch: ziehen. Exporte aus dem ERP, Screenshots von Wettbewerber-Sites, Einheiten normalisieren, Spalten wieder geradeziehen. Drei ganze Tage, fast alles mechanisch, fast nichts davon dort, wo die Operatorin Wert stiftet.
  • Donnerstag: Beurteilung. Der eine Tag, an dem Domänenwissen tatsächlich auftaucht — welche Linien marginseitig verteidigt werden, welche neu positioniert, wo die Elastizität real ist und wo das Signal vom letzten Quartal nur Rauschen war.
  • Freitag morgen: Aufschrieb. Ein Deck oder ein Memo mit den Empfehlungen, den Stütztabellen, der zwei-Absatz-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 bezahlt.

Was wir dem Agenten übergeben

Der erste Durchgang — Montag bis Mittwoch — ist heute ein Agent-Run. Die Form, generisch:

  • Wettbewerber-Scrape und Normalisierung. Ein Browser-nutzender Agent besucht die 6–12 öffentlichen Wettbewerber-Quellen, zieht Preise und Bundle-Strukturen, normalisiert Einheiten (pro Monat, pro Liter, pro Kilometer, pro Pflegestunde) und schreibt das Ergebnis in eine strukturierte Tabelle. Für Wettbewerber ohne öffentliche Site liest der Agent den letzten gescrapten Snapshot in unserem internen Store, statt erneut zu scrapen.
  • Benchmark-Aufbau. Öffentliche Datensätze des BFS, FSO-Branchenreports und — wo es ihn gibt — das Bulletin des relevanten Branchenverbands (Spitex Schweiz, Auto-Schweiz, Suva-Unfallquoten) werden in dieselben Einheiten zusammengeführt. Der Agent markiert jede Quelle, die älter als 90 Tage ist.
  • Internes Daten-Join. Umsatz nach SKU/Leistungslinie aus dem ERP, Kundenmix aus dem CRM, vertragsspezifische Rabatte, wo sie existieren. Zusammengeführt in eine einzige Langform-Tabelle, die die Operatorin öffnen kann.
  • Erste Szenarien. Drei Pricing-Szenarien mit P&L-Wirkung entworfen: halten, +3%, segmentiert (+5% auf preis-unempfindliche Segmente, sonst halten). Der Agent zeigt sein Rechnen — die Elastizitätsannahme, die Segmentanteil-Annahme, 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 Tools des Agenten hinter einem einzigen MCP-Server. Die ganze Pipeline läuft in einem Schweiz-gehosteten Container; die LLM-Aufrufe gehen über AWS Frankfurt an Anthropic mit Zero-Retention-Klausel. Nichts an der Architektur ist exotisch. Die Disziplin liegt darin, was wir den Agenten noch nicht tun lassen.

Wo die Operatorin in der Schleife bleibt

Drei Entscheidungen gehören nie dem Agenten.

  • Floor-Pricing strategischer Accounts. Der Agent sieht nicht und empfiehlt nicht zu den 8–15 Accounts, deren Beziehungsverlauf wichtiger ist als die Stückmarge. Die laufen separat und werden von Hand entschieden.
  • Ausnahme-Behandlung. Wenn der Agent einen Wettbewerberpreis flaggt, der sich in einem Monat um 18% bewegt hat, ist die Antwort fast immer ein Datenfehler oder eine einmalige Promotion — kein Marktsignal. Diese Beurteilung trifft die Operatorin, nicht das Modell.
  • Das "wie sagen wir das dem Kunden". Der Agent darf entwerfen. Er entscheidet nicht, welchen Ton die Beziehung dieses Quartal trägt. Das bleibt bei dem, der mit dem Kunden am Telefon war.

Das Muster ist wichtig: Der Agent darf alles tun, was reversibel und messbar ist. Jeder unumkehrbare Schritt — der Strategie-Account-Override, das Ausnahme-Urteil, die Kundenkommunikation — läuft durch eine menschliche Warteschlange. Die Warteschlange ist absichtlich kurz. Wächst sie in einer Woche über 20 Einträge, fragt der Agent zu viel und der Workflow muss enger gefasst werden, nicht mit mehr Reviewerinnen besetzt.

Wie das Artefakt am Dienstag morgen aussieht

Hier scheitern die meisten "AI-Report"-Projekte. Das Liefergut ist kein PDF, das in einer Inbox landet. Es ist ein Dashboard, das die Operatorin um 08:00 Uhr am Dienstag öffnet und aus dem sie handelt.

Konkret:

  • Eine Sicht. Langform-Tabelle über jede SKU oder Leistungslinie, der Preis dieses Monats, die Empfehlung des Agenten, die Belege inline (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 eine menschliche Entscheidung will, bevor etwas bewegt wird — Ausnahme, Strategie-Account-Flag, fehlende Daten.
  • Ein Knopf pro Zeile. "Annehmen und für die nächste Preislisten-Publikation einreihen", "Zurückgeben mit Notiz", "Für Manager-Review parken". Jeder Klick wird mit Zeitstempel, Operatorin und Begründung geloggt.

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

Drei Dinge, die uns gebissen haben

Sechs Monate drin, drei Fehlerformen, die einen Namen verdienen.

  • Übermütige Normalisierung. Anfangs hat der Agent ein "die ersten drei Monate gratis" eines Wettbewerbers hilfsbereit als Fußnote wegnormalisiert. Es stellte sich heraus, dass der Wettbewerber das stillschweigend dauerhaft gemacht hatte, und wir haben zwei Monate echtes Signal verpasst. Fix: Jeder Normalisierungsschritt erzeugt heute ein explizites "was-ich-fallen-gelassen-habe"-Log, und die Operatorin sieht das Drop-Log einmal pro Woche durch.
  • Die menschliche Review-Warteschlange ist explodiert. In Monat zwei lag der Gelb-Anteil bei 35% — der Agent hat alles abgesichert, was er noch nicht gesehen hatte. Fix: Wir haben die Zuversichtsschwellen angezogen, die Elastizitätsannahmen des Agenten verengt und ihm verboten, "Datenfrische" allein als Eskalationsgrund zu nutzen. Gelb-Anteil heute: ~9%.
  • Die Kosten pro Run haben uns einmal überrascht. Ein einzelner Review-Run kostete CHF 6.40 an API-Spend, als die Wettbewerber-Sites eine schlechte Scrape-Woche hatten und der Agent aggressiv neu versuchte. Wir haben einen harten Retry-Cap und ein Per-Run-Budget-Alert gesetzt. Steady-State-Kosten: 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 berührt. In keiner Keynote tauchen diese Punkte auf; jedes Team trifft sie in Monat zwei.

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

Zwei Tage Beurteilung statt einer. Das ist die Schlagzeile.

Die mechanischen 60% der Woche — ziehen, normalisieren, joinen, ersten Entwurf bauen — laufen über Nacht, mit dem Agenten allein, und landen am Dienstag morgen als Dashboard. Die Operatorin hat jetzt zwei volle Tage für den Teil, der sich aufzinst: Welche Linien verteidigen, wo die Elastizität real ist, welche strategischen Accounts ein anderes Gespräch verdienen und wie die Empfehlung gegenüber dem Kunden zu rahmen ist.

Das ist eine Verdoppelung der Zeit auf den teuren 40% der Arbeit. Keine 10×-Produktivitätsbehauptung. Eine saubere Verschiebung dorthin, wo die Woche sitzt.

Wenn Sie als Operations-Leitung eines Schweizer KMU mitlesen

Zwei praktische Mitnahmen.

Erstens, die Build-vs-Buy-Frage ist enger, als sie aussieht. Für einen wiederkehrenden, vertikalen Pricing-Workflow mit benannten Datenquellen ist der Build-Pfad 4–6 Wochen Arbeit, landet innerhalb Ihrer Tenancy und kostet im niedrigen dreistelligen CHF-Bereich pro Monat im Betrieb. Es gibt keine Pricing-Assistant-SaaS von der Stange, die Ihre Branchen auf diesem Niveau kennt, und es wird so schnell keine geben — der Long Tail ist zu lang. Die richtige Frage ist nicht "welcher Anbieter", sondern "welcher eine Workflow zuerst, und wer hält das Dashboard".

Zweitens, das Liefergut ist das Dashboard, nicht der Bericht. Wenn Ihr KI-Pilot mit einem schön geschriebenen Dokument endet, das am Dienstag morgen niemand öffnet, hat sich der Workflow nicht geändert. Der Agent ist nur 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 inline.

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

Vom Pricing-Review zum Pricing-Assistenten: Eine Woche RevMan-Arbeit, wenn ein Agent den ersten Durchgang macht — opsautomation.ch