Das Margenproblem der Preise pro Org im Salesforce DevOps

Kurz gesagt: Die meisten Salesforce-DevOps-Tools rechnen pro Seat oder pro verbundener Org ab. Fuer einen Endkunden mit einer Produktions-Org ist das fair, fuer eine Beratung mit zehn oder zwanzig Kunden-Orgs ist es still bestrafend, weil jeder neue Kunde Lizenzkosten verursacht, bevor er eine abrechenbare Stunde bringt. Ein Pipeline-Standard, dessen Preis nicht mit der Zahl der Orgs waechst, macht aus variablen Werkzeugkosten fixe, und das ist zuerst eine Margenentscheidung und erst danach eine Qualitaetsentscheidung.

Warum trifft die Abrechnung pro Seat und pro Org Beratungen am haertesten?

Ein Endkunde waechst entlang einer Achse: Menschen. Eine Produktions-Org, ein paar Sandboxes, ein Team, das langsam groesser wird. Ein Tool pro Seat bildet dieses Wachstum ehrlich ab.

Ein Boutique-Integrator waechst entlang einer anderen Achse: Orgs. Zehn Kunden bedeuten zehn Produktions-Orgs, deren Sandboxes und meist noch Scratch Orgs obendrauf. Der Zaehler laeuft genau auf der Achse, auf der das Geschaeft waechst, und dieses Wachstum ist fuer sich genommen nicht abrechenbar. Daraus folgen drei strukturelle Probleme.

• Die Kosten kommen vor dem Umsatz. Sie verbinden und konfigurieren eine Kunden-Org im Onboarding, das meist pauschal oder gar nicht bezahlt wird.
• Abwanderung ist asymmetrisch. Der Kunde geht, die Vertragslaufzeit bleibt.
• Weiterbelasten ist schwer. Kunden finanzieren Lizenzen, die sie in ihrer eigenen Org sehen. Ihre eigenen deutlich weniger gern.

Was messen die veroeffentlichten Preislisten wirklich?

Es lohnt sich, die Seiten der Anbieter selbst zu lesen statt der Zusammenfassungen. Gearset veroeffentlicht Listenpreise: das Kern-Deployment wird pro Gearset-Nutzer und Monat berechnet, waehrend Automation und CI/CD separat pro Team verkauft werden, wobei jede Stufe eine feste Zahl von CI/CD-Ziel-Orgs enthaelt. Die Org-Achse existiert also, sie steckt nur in der Automation-Zeile und nicht im Schlagzeilenpreis.

Copado veroeffentlicht keine Listenpreise. Essentials startet kostenlos, die Enterprise-Stufe fuehrt zu einem Beratungsgespraech. Fuer einen Partner ist das selbst ein Kostenfaktor: eine Bruttomarge laesst sich nicht auf einer Zahl modellieren, die man erst verhandeln muss.

Keines der beiden Modelle ist unehrlich. Beide wurden fuer einen Kunden entworfen, dem die Orgs gehoeren. Ein Partner, der sie nur leiht, ist in diesem Entwurf ein Randfall.

Was macht die Org-Achse mit einem wachsenden Kundenstamm?

Modellieren Sie die Form, nicht die Zahlen. Sobald eine Zeile Ihrer Rechnung mit verbundenen Orgs waechst, waechst die Werkzeugkost mit der Kundenliste, waehrend der Umsatz mit abrechenbaren Stunden waechst. Diese beiden Linien laufen jedes Mal auseinander, wenn Sie Arbeit gewinnen, die Sie nicht sofort besetzen koennen.

Weh tun die Stufenspruenge. Enthaelt eine Automation-Stufe fuenf Ziel-Orgs und die naechste fuenfzehn, kann der sechste Kunde eine ganze Stufe mehr kosten als der fuenfte. Dieser Sprung sagt nichts ueber den Aufwand des sechsten Projekts und stand nicht im bereits unterschriebenen Angebot.

Ist ein Pipeline-Standard eine Qualitaets- oder eine Margenentscheidung?

Verkauft wird er meist als Qualitaet: weniger fehlgeschlagene Deployments, ein echter Audit-Trail, ein Rollback, das man in einen Rahmenvertrag schreiben kann. Alles richtig. Die groessere Zahl steht auf der Kostenseite.

Pipelines pro Kunde bedeuten Wissen pro Kunde. Wer das Branching-Modell eines Kunden gebaut hat, ist der Einzige, der fuer ihn releasen kann, die Auslastung haengt an Personen und Urlaube werden zum Lieferrisiko. Eine gemeinsame Pipeline-Form aendert drei Dinge.

• Kunden-Onboarding wird Konfiguration statt Projekt.
• Jeder Berater kann jeden Account uebernehmen, die Auslastung haengt nicht mehr an einer Person.
• Release-Nachweise sehen fuer jeden Kunden gleich aus, was Audits und Reviews billig macht.

Standardisieren heisst nicht, dass alle Kunden identisch arbeiten. Es heisst, dass die Stufen feststehen (Ticket, Branch, Validierung, Freigabe, Deployment, Rollback) und nur die Konfiguration variiert.

Was pruefen Sie vor der Unterschrift unter einen DevOps-Vertrag?

1. Waechst eine Zeile des Preises mit verbundenen Orgs? Fragen Sie nach dem Betrag fuer Ihren heutigen Kundenstamm und fuer den doppelten.
2. Waechst er mit Seats, und kann ein Ansprechpartner beim Kunden ein Release freigeben, ohne einen zu kaufen?
3. Was passiert, wenn ein Kunde mitten in der Laufzeit geht?
4. Kann ein Berater ohne Git-Kenntnisse ein Release allein fahren?
5. Installiert das Tool etwas in der Kunden-Org? Ein Managed Package bedeutet jedes Mal Freigabe beim Start und Deinstallation beim Abschied.
6. Falls ein Kunde ISV ist: deckt dieselbe Pipeline 1GP- und 2GP-Paket-Workflows ab, oder ist das ein separater Kauf?

Was aendert ein fester Preis pro Unternehmen?

Serpent rechnet pro Unternehmen ab, nicht pro Seat und nicht pro Org. Scale kostet 699 $ pro Unternehmen und Monat mit unbegrenzten Nutzern und 0 $ Einrichtung, und der Preis bleibt gleich, ob Sie drei Kunden-Orgs verbinden oder dreissig. Eine kostenlose Essentials-Stufe mit 30 Credits pro Monat gibt es, wenn Sie zuerst einen einzelnen Account durchspielen wollen.

Ehrlich zur Messung: der Verbrauch laeuft ueber Credits, der Zaehler misst also Arbeit statt Kunden. Ein Feature-Deployment kostet einen Credit, ein Release in die Produktion zwei, eine KI-Aktion einen zusaetzlich, eine Datenoperation vier, und Scale enthaelt 300 pro Monat. Das ist eine Groesse, die Ihr Liefervolumen steuert, nicht eine, die Ihr Vertrieb mit jedem neuen Logo erzeugt.

Zwei Punkte zaehlen im Partnergeschaeft besonders. Serpent installiert nichts in der Kunden-Org und verbindet sich ueber Standard-APIs, das Onboarding braucht also keine Paketfreigabe und das Offboarding keine Deinstallation. Und weil der Ablauf ticketbasiert ist und Git im Hintergrund laeuft, muss der Berater, der einen Account uebernimmt, nicht derjenige sein, der ihn aufgesetzt hat.

FAQ

Ist die Abrechnung pro Seat immer schlechter fuer eine Beratung?

Nein. Vier Berater, die zwanzig Kunden-Orgs betreuen, koennen pro Seat guenstiger fahren als pro Org. Das Problem ist, dass die meisten Vertraege beides messen, Sie zahlen also auf der Achse, die zuerst waechst.

Koennen wir DevOps-Werkzeuge an den Kunden weiterbelasten?

Manchmal, als Position in einem Managed-Service-Retainer. Bei Festpreis-Implementierungen ist es deutlich schwerer, und genau dort liegt der Grossteil des Umsatzes von Boutique-Integratoren.

Bedeutet eine Standardpipeline dasselbe Branching-Modell fuer alle Kunden?

Nein. Halten Sie die Stufen identisch und lassen Sie Branching, Umgebungen und Freigaben Konfiguration pro Kunde bleiben.

Und Kunden, die selbst ISV sind?

Pruefen Sie, ob Paket-Workflows enthalten und kein Add-on sind. Serpent deckt 1GP-, 2GP- und AppExchange-Release-Workflows in jedem Plan ab, auch im kostenlosen.

Wie lange dauert der Umzug eines Kunden auf die gemeinsame Pipeline?

Serpent ist pro Workspace in unter 15 Minuten eingerichtet und die Onboarding-Sitzungen sind kostenlos, die Bremse ist also meist das Change-Fenster des Kunden, nicht das Werkzeug.