Die meisten Mid-Stage-B2B-SaaS-Teams, die ich treffe, quoten schlecht, und die Schlussfolgerung, die sie bereits gezogen haben, ist, dass sie Salesforce CPQ brauchen. Sie haben ein Quote-Template, das nicht zum Deal passt, Line Items, die nicht zum Quote passen, eine Produktliste, die alle als Vorschlag behandeln, und eine Discounting-Praxis, die niemand in einem Satz beschreiben kann. Die Diagnose, zu der sie gekommen sind, dass die Quoting-Komplexität dem CRM entwachsen ist, ist fast immer falsch. Die Komplexität ist Product-Library-Schulden, keine Konfigurationslogik. Die Lösung ist ein CPQ-Lite-Stack, HubSpot-Line-Items als Source of Truth, PandaDoc als gerendertes Quote, eine disziplinierte Product Library und drei Approval-Regeln. Unter einer bestimmten Größenschwelle übertrifft dieser Stack einen CPQ-Rollout in Time-to-Value und Gesamtkosten. Der Fehler ist, das schwere Tool zu kaufen, um ein leichtes Problem abzudecken.
Warum das jetzt wichtig ist
Quoting ist, wo die losen Enden in einer Sales-Motion sichtbar werden. Discounts, die Ausnahmen sein sollten, werden zur Policy; Line Items, die Standard sein sollten, werden zu dem, was eine Vertrieblerin letzte Woche eingetippt hat; das Dokument, das die Kundin unterschreibt, wird zu einer kleinen Fiktion, die nachträglich mit dem CRM reconciliert wird. Wie Jason Lemkin auf SaaStr argumentiert hat, wird Sales-Discounting nicht durch Tooling eliminiert: es wird durch Struktur kontrolliert, vertraute Reps, hochgesetzte Listenpreise, automatisierte Niedrigwert-Konzessionen und ins Deal modellierte Procurement-Discounts. Ein CPQ-Lite-Stack ist, wie Sie diese Struktur operativ machen, ohne CPQ zu kaufen. Die billigere Version der Disziplin schlägt jedes Mal die teurere Version des Chaos.
Die CPQ-Falle, Tooling für ein Prozessproblem kaufen
Der Standard-Eskalationspfad ist erkennbar. Reps beschweren sich, dass Quotes zu lange dauern. Finance beschwert sich, dass Bookings nicht zu Rechnungen passen. Eine Gründerin liest einen Vergleichsbeitrag über CPQ und das nächste Gespräch ist ein Salesforce-CPQ-Scoping-Call. Sechs Monate und ein nennenswertes Budget später hat das Team dasselbe Product-Library-Chaos, jetzt in ein teureres System verdrahtet, das niemand im Revenue-Team vollständig versteht.
Die ehrliche Diagnose ist kürzer. Wenn Ihre Quotes falsch sind, weil Reps Custom-Line-Items eintippen, statt aus einer sauberen Produktliste zu wählen, fixt CPQ das nicht, die Produktliste tut es. Wenn Ihre Quotes falsch sind, weil Discounts unbegrenzt sind, fixt CPQ das nicht, drei Approval-Regeln tun es. Wenn Ihre Quotes falsch sind, weil das Dokument nicht zum Deal passt, fixt CPQ das nicht, eine Zwei-Wege-Sync mit PandaDoc tut es. CPQ ist die richtige Antwort für tatsächlich konfigurierbare Produkte mit Abhängigkeiten, Eligibility-Logik und Bundling-Regeln. Das meiste B2B-SaaS-Quoting ist das nicht.
Die vier Primitive von CPQ-Lite
Die Architektur hat nur vier bewegliche Teile. Die Disziplin liegt darin, sie in ihren Spuren zu halten.
1. Die Product Library
Jedes bepreiste Ding, das das Unternehmen verkauft, bekommt einen HubSpot-Product-Record. Keine Ausnahmen. Keine „Custom"-Line-Items als Workaround für eine SKU, die Sie zu erstellen vergessen haben. Die Product Library ist die Master-Liste, verantwortet von einer Person, meist einer RevOps-Lead oder einer Finanzpartnerin, und Änderungen gehen durch diese Person. Die Library trägt den kanonischen Namen, die SKU, den Listenpreis, die Abrechnungsfrequenz und gegebenenfalls eine Produktfamilien-Taxonomie. Alles andere hängt daran.
2. Line Items auf dem Deal
Line Items leben auf dem HubSpot-Deal und werden aus der Product Library gezogen, nicht von Hand eingetippt. Die Deal-Summe ist die Summe der Line Items, Ende. Wenn Deal-Wert und Line-Item-Summe nicht übereinstimmen, sind die Line Items richtig und der Deal-Wert ist die Zahl, der man nicht trauen sollte. Reporting, Forecasting und Bookings lesen alle aus den Line Items.
3. Das PandaDoc-Quote-Dokument
PandaDoc ist der gerenderte Output, nicht die Source of Truth. Das Quote-Template zieht Line Items aus dem Deal über die Zwei-Wege-HubSpot-Integration, rendert sie in ein Dokument, das die Kundin unterschreiben kann, und schreibt den finalen akzeptierten Zustand zurück auf den Deal. Die Kundin sieht das CRM nie. Das CRM muss nie wie ein Vertrag aussehen. Beide Systeme machen den Job, in dem sie gut sind.
4. Die drei Approval-Regeln
Drei Approval-Trigger decken die Variation, Discount über einer definierten Schwelle, Laufzeit über zwölf Monaten und jedes als Custom geflaggte Line Item. Jeder routet an eine benannte Approverin, bevor das Dokument hinausgeht. Drei Regeln werden sich etwa eine Woche lang unzureichend anfühlen. Dann werden sie sich für ein Jahr ungefähr richtig anfühlen.
Product-Library-Disziplin, was eine SKU bekommt, was nicht
Der häufigste Failure Mode von CPQ-Lite ist, Custom-Line-Items als stille Notluke zu erlauben. Eine Vertrieblerin muss etwas quoten, das die Library nicht hat, tippt es als One-off ein, und das Quote geht raus. Zwei Monate später ist dieses One-off zu einer Phantom-Produktfamilie mit drei Varianten und ohne Eigentümerin geworden. Die Disziplin, die das verhindert, Alles, was zweimal gequotet wird, bekommt eine SKU. Alles, was einmal mit Custom-Pricing gequotet wird, routet durch die dritte Approval-Regel und triggert ein Product-Library-Review. Die Library ist klein, bewusst und oft editiert.
Was eine SKU bekommt: die Standard-Tiers, die benannten Add-ons, die Service-Pakete, die Implementierungsgebühren, die wiederkehrenden Overages. Was nicht, Per-Deal-Credits, einmalige Konzessionen und maßgeschneidert verhandelte Bedingungen. Diese gehen ins Discount-Feld oder als geflaggte Custom-Line, wo das Approval-Routing sie auffängt.
Muster aus der Praxis
Ein B2B-SaaS-Team aus dem DACH-Raum etwa in Series A kam überzeugt, sie bräuchten Salesforce CPQ. Der Trigger war ein Quoting-Backlog: Jedes Quote dauerte zwei Tage zum Zusammensetzen, die Hälfte brauchte einen Rebuild nach Legal-Review, und die Bookings-Zahl reconcilierte erst nach einem manuellen Quartalsende-Cleanup zum Vertrag. Das Team hatte bereits einen CPQ-Rollout abgegrenzt. Der Vorschlag, den wir machten, war eine Sechs-Wochen-Alternative: die Product Library bereinigen, die PandaDoc–HubSpot-Zwei-Wege-Line-Item-Sync aufsetzen, drei Approval-Regeln definieren. Bis Ende Woche sechs war das durchschnittliche Quote in unter einer Stunde zusammengestellt, die Bookings-Zahl passte beim ersten Durchlauf zum Vertrag, und das CPQ-Projekt fiel von der Roadmap. Der legitime CPQ-Trigger kam achtzehn Monate später, als die Produktkonfigurierbarkeit den Regeln tatsächlich entwachsen war, zu welchem Zeitpunkt CPQ-Lite die Brücke war, die die Zeit gekauft hatte, CPQ richtig zu scopen.
Auflösung, ein CPQ-Lite-Playbook
Wenn Sie nach CPQ greifen und das Symptom unsauberes Quoting statt konfigurierbare Produkte ist:
- Auditieren Sie die Product Library. Jedes bepreiste Ding bekommt eine SKU, einen Listenpreis und eine Abrechnungsfrequenz. Alles, was in den letzten zwölf Monaten gequotet wurde und nicht in der Library ist, wird entweder hinzugefügt oder ausgemustert. Eine Eigentümerin.
- Machen Sie Line Items zur Source of Truth. Reporting, Forecasting und Bookings lesen alle aus Line Items, nicht aus dem Deal-Wert-Feld. Trainieren Sie das Team, dass die Deal-Summe eine abgeleitete Zahl ist.
- Setzen Sie PandaDoc als Renderer auf. Zwei-Wege-Line-Item-Sync, ein kanonisches Quote-Template pro Motion, akzeptierter Zustand schreibt zurück auf den Deal. Die Kundin unterschreibt das Dokument; das Dokument passt zum Deal.
- Definieren Sie drei Approval-Regeln. Discount über einer definierten Schwelle, Laufzeit über zwölf Monaten, jedes Custom-Line-Item. Benennen Sie die Approverin für jede. Widerstehen Sie dem Drang, mindestens zwei Quartale lang eine vierte Regel hinzuzufügen.
- Wählen Sie den Migrations-Trigger im Voraus. Eine klare Schwelle, ab der CPQ-Lite den Use Case nicht mehr abdeckt: typischerweise eine Funktion aus Rep-Headcount, SKU-Count und echter Produktkonfigurierbarkeit: , schriftlich festgehalten, bevor der Stack im Einsatz ist. Der Trigger ist kein Bauchgefühl.
- Reviewen Sie quartalsweise, nicht wöchentlich. Library, Templates und Approval-Schwellen bekommen ein quartalsweises Review. Out-of-Cycle-Änderungen sind, wie die Disziplin erodiert.
- Dokumentieren Sie das Operating Model, nicht nur die Konfiguration. Die Disziplin ist das Asset. Schreiben Sie auf, wer die Library verantwortet, wer was approved und wie eine neue SKU hinzugefügt wird. Ohne das vergammelt der Stack innerhalb eines Jahres.
Wo Checkpoint ins Spiel kommt
Die meisten CPQ-Projekte, in die wir hineingezogen werden, werden entweder als CPQ-Lite umgebaut oder werden ordentlich gescoped, weil CPQ-Lite zuerst probiert wurde und die echte Schwelle erreicht wurde. Beide Outcomes sind in Ordnung. Das schlechte Outcome ist ein schwergewichtiger CPQ-Rollout, der Product-Library-Schulden mit Konfigurations-Komplexität überklebt. Wenn Sie Quoting-Tooling evaluieren, sprechen Sie mit uns vor dem Procurement-Gespräch, wir fahren das Line-Item-Audit, scopen die HubSpot-Implementation-Arbeit, fitten es ins breitere RevOps Operating Model ein und sagen Ihnen ehrlich, ob der CPQ-Lite-Stack Ihren Fall abdeckt oder ob Sie zu einer echten CPQ-Migration herangewachsen sind. Wenn ein Plattformwechsel auf dem Tisch liegt, übernimmt unsere CRM-Migration-Praxis die Brownfield-Arbeit neben dem Quoting-Redesign, sodass Sie es nur einmal machen.
Quellen
- Lemkin, Jason. „The Confounding Logic of Discounting." SaaStr. saastr.com
- Mohammed, R. „The Art of Discounting." Harvard Business Review, 4. Mai 2026. hbr.org