SteelBrick CPQ vs. Salesforce CPQ: Unterschiede, Historie und aktuelle Einordnung

SteelBrick CPQ vs. Salesforce CPQ ist heute weniger ein Produktduell als eine Frage der richtigen Einordnung. In vielen Unternehmen steht „SteelBrick“ noch in alten Dokumenten, während Salesforce längst andere Produktnamen und Revenue-Cloud-Strukturen verwendet.

Salesforce meldete 2016, dass SteelBrick CPQ nach Abschluss der Übernahme Teil von Sales Cloud wurde. Heute beschreibt Salesforce CPQ und Revenue-Management-Funktionen stärker über integrierte CPQ-, Billing- und Quote-to-Cash-Prozesse.

Für Entscheider ist das wichtig. Wer ein bestehendes System bewertet, darf nicht nur nach Namen gehen. Entscheidend ist, welche Funktionen wirklich aktiv sind: Konfiguration, Preisregeln, Rabattlogik, Angebotsdokumente, Genehmigungen, Abonnement-Logik, Abrechnung und Integration mit CRM, ERP oder Billing.

Dieser Artikel erklärt die Historie, die Unterschiede und die praktische Bedeutung für Unternehmen. Er zeigt auch, wann Salesforce CPQ ausreicht und wann ein modernerer Revenue-Stack oder ein externer 3D-Produktkonfigurator sinnvoll wird.

Was hinter den beiden Begriffen steht

SteelBrick CPQ und Salesforce CPQ beschreiben eng verwandte Lösungen. Der eine Begriff stammt aus der Zeit vor und kurz nach der Übernahme, der andere aus der späteren Salesforce-Welt.

Das klingt nach einer kleinen Namensfrage. In Projekten kann sie aber große Folgen haben. Wer mit falschen Begriffen arbeitet, sucht oft in der falschen Dokumentation, prüft alte Datenmodelle falsch oder übersieht moderne Produktoptionen.

SteelBrick CPQ als Ursprung der Lösung

SteelBrick war ein CPQ-Anbieter, der sich auf Configure, Price, Quote konzentrierte. Also auf das, was im deutschen Vertrieb oft als Produktkonfiguration, Preisfindung und Angebotserstellung beschrieben wird.

Die Lösung half Vertriebsteams, komplexe Produkte schneller und kontrollierter zu verkaufen. Statt Preise manuell in Excel zu berechnen, konnten Regeln, Bundles, Rabatte und Genehmigungen im System hinterlegt werden.

Nach der Übernahme durch Salesforce wurde SteelBrick CPQ Teil der Salesforce-Welt. Viele ältere Implementierungen tragen deshalb noch Spuren dieses Ursprungs: Paketnamen, Objektstrukturen, alte Schulungsunterlagen oder interne Begriffe.

Salesforce CPQ als weiterentwickeltes Managed Package

Salesforce CPQ ist die bekanntere spätere Bezeichnung. Technisch handelt es sich bei vielen Bestandsinstallationen um ein Managed Package auf der Salesforce-Plattform.

Das bedeutet: Die Lösung lebt im Salesforce-Ökosystem, nutzt Salesforce-Daten und verbindet sich eng mit Opportunities, Accounts, Produkten, Preisbüchern und Angebotsobjekten.

Salesforce beschreibt CPQ als Tool, das Unternehmen hilft, Preise auf Basis einer bestimmten Produktkonfiguration schnell und genau zu erstellen. Dabei werden optionale Features, Mengen, Anpassungen und Rabatte berücksichtigt.

Warum der Vergleich heute noch gesucht wird

Der Vergleich wird gesucht, weil Unternehmen mit alten und neuen Begriffen gleichzeitig arbeiten. In der Praxis treffen Legacy-Systeme, neue Salesforce-Roadmaps und gewachsene Vertriebsprozesse oft aufeinander.

Das passiert besonders häufig nach vielen Jahren Betrieb. Ein Unternehmen möchte modernisieren, aber niemand weiß mehr genau, ob intern von SteelBrick, Salesforce CPQ, Revenue Cloud oder einer stark angepassten Eigenlösung gesprochen wird.

Alte Dokumentation, Partnerseiten und interne Systemnamen

Viele Unternehmen haben CPQ-Projekte vor Jahren gestartet. Damals stand SteelBrick noch in Präsentationen, Projektplänen oder technischen Dokumenten.

Diese Unterlagen verschwinden nicht einfach. Sie bleiben in SharePoint-Ordnern, Confluence-Seiten, alten Tickets und Prozesshandbüchern. Auch Partner oder Implementierungsteams verwenden manchmal noch alte Begriffe, weil sie aus der ursprünglichen Projektphase stammen.

Das führt zu Verwirrung. Ein Fachbereich sagt „SteelBrick“, die IT spricht von „Salesforce CPQ“, und das Management fragt nach „Revenue Cloud“. Meist reden alle über denselben Kernprozess, aber aus unterschiedlichen Blickwinkeln.

Relevanz für Bestandskunden und Modernisierungsprojekte

Für Bestandskunden ist der Begriff SteelBrick weiterhin relevant, wenn ein Audit oder eine Migration ansteht. Alte Objektmodelle, Custom Code, Preislogik und Genehmigungsregeln müssen sauber verstanden werden.

Besonders kritisch wird es bei gewachsenen Installationen. Manche Teams haben über Jahre eigene Automatisierung, Workarounds, externe Tools und manuelle Schritte ergänzt.

Dann reicht es nicht, nur die Lizenz zu prüfen. Unternehmen müssen verstehen, wie tief CPQ in den Vertriebsprozess eingebettet ist. Dazu gehören Vertriebsdaten, Produktkataloge, Preisregeln, Rabattlogik, Angebotsvorlagen, Rollen und Schnittstellen.

SteelBrick CPQ vs. Salesforce CPQ: Welche Unterschiede gibt es im direkten Vergleich?

Der wichtigste Unterschied liegt im Namen, im Markenstatus und in der aktuellen Produktpositionierung. Funktional geht es oft um dieselbe Linie, aber Salesforce CPQ ist die richtige Bezeichnung für die spätere und weiterentwickelte Salesforce-Welt.

Produktname und Markenstatus

SteelBrick CPQ ist vor allem historisch relevant. Der Name kann in alten Verträgen, Schulungsunterlagen oder technischen Paketbezeichnungen auftauchen.

Salesforce CPQ ist die Bezeichnung, die Unternehmen in aktuellen Projektgesprächen meist verwenden sollten. Sie ist klarer, verständlicher und näher an der heutigen Salesforce-Dokumentation.

Für die Kommunikation mit Management und Fachbereichen kann es trotzdem sinnvoll sein, beide Begriffe einmal gemeinsam zu erklären. So vermeidet man Missverständnisse.

Plattformintegration und Datenmodell

Salesforce CPQ arbeitet eng mit Salesforce-Daten. Produkte, Accounts, Opportunities, Preisbücher, Angebote und Genehmigungen greifen ineinander.

Das ist ein großer Vorteil, wenn der Vertrieb stark in Salesforce arbeitet. Relevante Daten müssen nicht ständig kopiert werden. Der Vertriebsprozess wird dadurch transparenter.

Gleichzeitig entsteht Abhängigkeit vom Datenmodell. Wenn Produktdaten unsauber gepflegt sind, wird auch die beste CPQ-Logik schwer wartbar.

Funktionsumfang für Konfiguration, Preisfindung und Angebote

Im Zentrum stehen drei Fragen: Was darf verkauft werden? Zu welchem Preis? Und wie wird daraus ein korrektes Angebot?

Salesforce CPQ unterstützt Produktkonfiguration, Preisfindung und Angebotsdokumente. Dazu kommen Funktionen für Rabatte, Genehmigungen und geführte Verkaufsprozesse. Salesforce beschreibt unter anderem Guided Selling, automatisierte Approvals, Discounting Rules, Product Configurator und einen Pricing-Engine-Ansatz.

Für einfache Produktkataloge ist das oft mehr als genug. Bei sehr visuellen, variantenreichen oder technischen Produkten kann jedoch ein spezialisierter Produktkonfigurator zusätzlichen Wert bringen.

Anpassbarkeit, Automatisierung und Erweiterungen

Salesforce CPQ lässt sich anpassen. Unternehmen können Regeln, Workflows, Genehmigungen, Vorlagen und Automatisierung ergänzen.

Das ist nützlich, aber auch riskant. Zu viele Sonderregeln machen ein CPQ-System schwer verständlich. Dann weiß niemand mehr, warum ein Preis entsteht oder weshalb ein Angebot blockiert wird.

Gute CPQ-Architektur bleibt deshalb bewusst einfach. Regeln sollten lesbar, dokumentiert und fachlich nachvollziehbar sein.

Wartung, Support und Weiterentwicklung

Bei Salesforce CPQ geht es nicht nur um die Einführung. Der langfristige Betrieb ist genauso wichtig.

Produkte ändern sich. Preise ändern sich. Vertriebsmodelle ändern sich. Neue Länder, neue Währungen, neue Rabatte, neue Abonnements und neue Billing-Anforderungen kommen hinzu.

Deshalb sollte jedes CPQ-System regelmäßig geprüft werden. Nicht erst, wenn Angebote falsch sind oder der Vertrieb wieder Excel nutzt.

Wann der Begriff SteelBrick CPQ noch sinnvoll ist

SteelBrick CPQ ist sinnvoll, wenn Unternehmen historische Systeme, alte Dokumentation oder Legacy-Anpassungen untersuchen. Für neue strategische Entscheidungen ist der Begriff jedoch meist zu eng.

Er hilft vor allem beim Aufräumen. Wer weiß, dass SteelBrick der Ursprung vieler Salesforce-CPQ-Installationen ist, findet schneller die richtigen Spuren im System.

Recherche in Legacy-Systemen

In alten Salesforce-Organisationen können SteelBrick-Begriffe noch sichtbar sein. Sie tauchen in Paketnamen, Feldern, alten Release Notes, Kommentaren oder Integrationsbeschreibungen auf.

Für Entwickler und Administratoren ist das wichtig. Eine Suche nur nach „Salesforce CPQ“ findet möglicherweise nicht alles.

Auch bei einer Migration hilft der historische Begriff. Er zeigt, welche Systemteile aus der ursprünglichen CPQ-Implementierung stammen und welche später ergänzt wurden.

Audit von bestehenden Angebotsprozessen

Ein CPQ-Audit sollte immer den realen Angebotsprozess betrachten. Nicht nur die technische Installation.

Wie entsteht ein Angebot? Welche Daten nutzt der Vertrieb? Wo greift die Rabattlogik? Welche Preisregeln sind aktiv? Wann wird eine Genehmigung ausgelöst? Welche Schritte passieren außerhalb des Systems?

Wenn in diesem Prozess noch SteelBrick-Begriffe vorkommen, sollten sie dokumentiert werden. Das schafft Klarheit für IT, Vertrieb und externe Partner.

Kommunikation mit Fachbereichen und Implementierungspartnern

Manchmal ist SteelBrick der Begriff, den langjährige Mitarbeiter kennen. Dann sollte man ihn nicht einfach verbieten.

Besser ist eine kurze Übersetzung: „SteelBrick ist der alte Name. In unseren aktuellen Projektunterlagen sprechen wir von Salesforce CPQ.“

Das wirkt banal, spart aber viele Schleifen. Gerade in Workshops hilft eine gemeinsame Sprache enorm.

Wann Salesforce CPQ die richtige Bezeichnung ist

Salesforce CPQ ist die richtige Bezeichnung, wenn es um aktuelle Dokumentation, technische Spezifikation, Betrieb und Weiterentwicklung bestehender CPQ-Funktionen geht. Der Begriff ist präziser und anschlussfähiger.

Er passt auch besser zu Gesprächen mit Salesforce-Teams, Implementierungspartnern und internen Architekten. Hier zählt, welches Produkt heute betrieben wird und welche Roadmap dazu passt.

Produktdokumentation und technische Spezifikation

In technischen Konzepten sollte Salesforce CPQ stehen, wenn die aktuelle Managed-Package-Lösung gemeint ist.

Das macht Anforderungen klarer. Wer „SteelBrick“ schreibt, riskiert Rückfragen: Ist ein alter Projektname gemeint? Ein Paket? Eine Legacy-Anpassung? Oder einfach Salesforce CPQ?

Saubere Begriffe sind besonders wichtig bei Schnittstellen, Datenmodellen, User Stories und Testfällen.

Lizenzierung, Betrieb und Benutzerrollen

Bei Lizenzierung und Betrieb sollte die aktuelle Salesforce-Terminologie verwendet werden. Das betrifft Benutzerrollen, Berechtigungen, Supportfälle und Vertragsfragen.

Gerade bei großen Organisationen ist das wichtig. CPQ-Nutzer sitzen oft in mehreren Ländern, Rollen und Vertriebsteams.

Wenn Begriffe unsauber sind, entstehen falsche Annahmen. Zum Beispiel darüber, wer konfigurieren darf, wer Rabatte genehmigt oder wer Angebotsvorlagen ändern kann.

Integrationen mit CRM, ERP und Billing

Salesforce CPQ wird selten allein betrieben. Meist ist es mit CRM, ERP, Billing, Commerce, Vertragsmanagement oder Reporting verbunden.

Salesforce Billing ist laut Salesforce ein Add-on-Package, das wichtige Datensätze und Informationen von Salesforce CPQ übernimmt. Damit wird klar: CPQ ist oft nur ein Teil einer größeren Quote-to-Cash-Kette.

Für Unternehmen heißt das: Jede Integration muss sauber geprüft werden. Ein Fehler im Produktkatalog kann später in Auftrag, Abrechnung oder Umsatzreporting weiterwandern.

Welche Grenzen hat Salesforce CPQ im modernen Revenue-Stack?

Salesforce CPQ ist stark, aber nicht für jedes moderne Revenue-Szenario automatisch ausreichend. Grenzen zeigen sich vor allem bei sehr komplexen Produkten, visueller Variantenlogik und End-to-End-Prozessen über Billing, Subscription und Revenue Operations.

Das ist keine Schwäche im klassischen Sinn. CPQ wurde für bestimmte Aufgaben gebaut. Viele Unternehmen verlangen heute jedoch mehr als Configure, Price, Quote.

Komplexe Produktmodelle und Variantenlogik

Bei technischen Produkten kann die Konfiguration sehr anspruchsvoll werden. Ein Produkt besteht dann nicht nur aus Optionen, sondern aus Abhängigkeiten, Maßen, Materialien, Bauteilen, Regeln und visuellen Varianten.

Beispiele gibt es viele: Maschinen, Möbel, Fenster, Türen, Fahrzeuge, Industrieanlagen oder modulare Geräte.

Hier kann ein klassisches CPQ-Interface an Grenzen stoßen. Der Vertrieb braucht nicht nur Felder und Regeln, sondern ein klares visuelles Erlebnis. Kunden wollen sehen, was sie kaufen.

Abo-Modelle, Verlängerungen und Revenue Operations

Bei Abonnement-Modellen wird CPQ schnell komplexer. Es geht nicht nur um den Erstverkauf, sondern um Laufzeiten, Verlängerungen, Upgrades, Downgrades, Kündigungen, Verbrauch und Abrechnung.

Ein einfaches Angebot reicht dann nicht mehr. Das Unternehmen braucht Kontrolle über den gesamten Kundenlebenszyklus.

Salesforce beschreibt Quote-to-Cash als breiteren Prozess, der über CPQ hinausgeht und unter anderem Order Fulfillment, Billing und Accounts Receivable umfasst.

Skalierung bei Enterprise-Implementierungen

In Enterprise-Umgebungen wird CPQ oft schwer, weil viele Teams mitreden. Vertrieb, Finance, Produktmanagement, Legal, Operations und IT haben jeweils eigene Anforderungen.

Das Ergebnis kann ein System sein, das alles abbilden soll und dadurch unübersichtlich wird.

Skalierung gelingt besser, wenn Unternehmen Regeln vereinfachen, Datenqualität verbessern und klare Governance einführen. CPQ ist kein Ersatz für saubere Produkt- und Preisstrategie.

Welche Rolle spielt Revenue Cloud in einer modernen Quote-to-Cash-Architektur?

Revenue Cloud erweitert den Blick von CPQ auf den gesamten Umsatzprozess. Es geht nicht nur um Angebote, sondern um Produkte, Preise, Verträge, Orders, Subscriptions, Billing und Revenue-Daten.

Damit wird die Diskussion strategischer. Unternehmen fragen nicht mehr nur: „Wie erstellen wir schneller ein Angebot?“ Sie fragen: „Wie steuern wir Umsatz über den gesamten Lebenszyklus?“

Rolle von Revenue Cloud im aktuellen Salesforce-Ökosystem

Salesforce positioniert Revenue Cloud als Plattform für Revenue-Management und Quote-to-Cash. Aktuelle Pricing-Seiten beschreiben etwa Revenue Cloud Growth mit CPQ und Subscription Management sowie Revenue Cloud Advanced als vollständige Quote-to-Cash-Plattform für verschiedene Umsatzmodelle.

Das zeigt die Richtung. CPQ bleibt wichtig, ist aber eingebettet in größere Prozesse.

Für Unternehmen mit einfachen Vertriebsmodellen kann Salesforce CPQ ausreichend sein. Für komplexere Revenue-Modelle lohnt sich ein Blick auf die breitere Architektur.

Unterschied zwischen klassischem CPQ und End-to-End Revenue Lifecycle

Klassisches CPQ beantwortet drei Kernfragen: Welche Lösung wird konfiguriert? Welcher Preis gilt? Welches Angebot wird erstellt?

Ein End-to-End Revenue Lifecycle geht weiter. Er verbindet Angebot, Vertrag, Auftrag, Lieferung, Nutzung, Abrechnung, Verlängerung und Analyse.

Der Unterschied ist praktisch. Im klassischen CPQ-Projekt optimiert man den Vertrieb. In einem Revenue-Cloud-Projekt optimiert man den Umsatzfluss des Unternehmens.

Entscheidungskriterien für Bestandskunden

Bestandskunden sollten nicht automatisch migrieren. Sie sollten zuerst prüfen, wo der echte Engpass liegt.

Wenn die Angebotserstellung langsam ist, kann CPQ-Optimierung reichen. Wenn Abrechnung, Subscription Management und Revenue Reporting auseinanderlaufen, braucht es eine größere Lösung.

Die wichtigste Frage lautet: Ist das Problem im CPQ-Prozess — oder im gesamten Quote-to-Cash-Modell?

Welche Empfehlung lässt sich für Unternehmen ableiten?

Unternehmen sollten zuerst klären, welches System sie wirklich haben, wie kritisch es ist und welche Zukunftspläne bestehen. Danach lässt sich entscheiden, ob Optimierung, Upgrade, Ergänzung oder Replatforming sinnvoll ist.

Eine gute Entscheidung beginnt nicht mit Produktnamen. Sie beginnt mit Prozessen, Daten und Geschäftszielen.

Wenn ein bestehendes Salesforce CPQ-System ausreicht

Ein bestehendes Salesforce CPQ-System reicht oft aus, wenn Produkte, Preise und Angebotsprozesse stabil sind.

Das gilt besonders dann, wenn der Vertrieb gut damit arbeitet, Angebote korrekt sind und Integrationen zuverlässig laufen.

In diesem Fall ist ein großes Replatforming unnötig. Besser ist gezielte Pflege: Daten bereinigen, Regeln vereinfachen, Vorlagen aktualisieren, Schulungen verbessern und unnötige Anpassungen entfernen.

Wenn ein Upgrade oder Replatforming sinnvoll ist

Ein Upgrade oder Replatforming wird sinnvoll, wenn das aktuelle System den Vertrieb bremst oder moderne Geschäftsmodelle nicht mehr sauber abbildet.

Die folgende Tabelle hilft bei der ersten Einordnung:

Die beste Lösung ist nicht immer die größte. Manchmal genügt ein sauberer Audit. Manchmal braucht es ein neues Architekturkonzept.

Was CanvasLogic bietet

CanvasLogic hilft Unternehmen, komplexe Produkte verständlich, visuell und verkaufsfähig zu machen. Der Schwerpunkt liegt auf 3D-Produktkonfiguration, AR-Erlebnissen und CPQ-naher Vertriebsunterstützung.

Das ist besonders wertvoll, wenn Produkte nicht einfach aus einer Liste gewählt werden können. Manche Angebote müssen gesehen, gedreht, angepasst und verstanden werden.

CanvasLogic kann bestehende CPQ- und CRM-Landschaften sinnvoll ergänzen. Zum Beispiel, wenn Salesforce CPQ die kaufmännische Logik abbildet, aber der Vertrieb ein besseres Frontend für Kunden, Händler oder interne Teams braucht.

Fazit

SteelBrick CPQ vs. Salesforce CPQ ist heute vor allem eine Frage der Historie und der Sprache. SteelBrick ist der Ursprung. Salesforce CPQ ist die spätere und praktisch relevantere Bezeichnung für bestehende CPQ-Installationen im Salesforce-Ökosystem.

Für Unternehmen zählt aber mehr als der Name. Entscheidend ist, ob das System den heutigen Vertriebsprozess unterstützt. Stimmen Produktdaten, Preisfindung, Angebotserstellung, Automatisierung, Integration und Abrechnung noch zusammen?

Wenn ja, lohnt sich die Optimierung. Wenn nein, sollte die Architektur geprüft werden. Manchmal ist Salesforce CPQ weiterhin ausreichend. Manchmal braucht es Revenue Cloud, Billing, bessere Datenmodelle oder einen visuellen Produktkonfigurator.

Der beste nächste Schritt ist ein nüchterner Blick auf die Realität: Wie verkauft Ihr Team heute? Wo verliert es Zeit? Wo entstehen Fehler? Und welche Kundenerfahrung möchten Sie in Zukunft bieten?

Genau dort beginnt eine sinnvolle CPQ-Strategie.