Das Margenproblem der Preise pro Org im Salesforce DevOps

Kurz gesagt: Die meisten Salesforce-DevOps-Tools rechnen pro Seat oder pro verbundener Org ab. Für einen Endkunden mit einer Produktions-Org ist das fair, für 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 wächst, macht aus variablen Werkzeugkosten fixe, und das ist zuerst eine Margenentscheidung und erst danach eine Qualitätsentscheidung.

Warum trifft die Abrechnung pro Seat und pro Org Beratungen am härtesten?

Ein Endkunde wächst entlang einer Achse: Menschen. Eine Produktions-Org, ein paar Sandboxes, ein Team, das langsam größer wird. Ein Tool pro Seat bildet dieses Wachstum ehrlich ab.

Ein Boutique-Integrator wächst entlang einer anderen Achse: Orgs. Zehn Kunden bedeuten zehn Produktions-Orgs, deren Sandboxes und meist noch Scratch Orgs obendrauf. Der Zähler läuft genau auf der Achse, auf der das Geschäft wächst, und dieses Wachstum ist für 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 veröffentlichten Preislisten wirklich?

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

Copado veröffentlicht keine Listenpreise. Essentials startet kostenlos, die Enterprise-Stufe führt zu einem Beratungsgespräch. Für einen Partner ist das selbst ein Kostenfaktor: eine Bruttomarge lässt sich nicht auf einer Zahl modellieren, die man erst verhandeln muss.

Keines der beiden Modelle ist unehrlich. Beide wurden für einen Kunden entworfen, dem die Orgs gehören. 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 wächst, wächst die Werkzeugkost mit der Kundenliste, während der Umsatz mit abrechenbaren Stunden wächst. Diese beiden Linien laufen jedes Mal auseinander, wenn Sie Arbeit gewinnen, die Sie nicht sofort besetzen können.

Weh tun die Stufensprünge. Enthält eine Automation-Stufe fünf Ziel-Orgs und die nächste fünfzehn, kann der sechste Kunde eine ganze Stufe mehr kosten als der fünfte. Dieser Sprung sagt nichts über den Aufwand des sechsten Projekts und stand nicht im bereits unterschriebenen Angebot.

Ist ein Pipeline-Standard eine Qualitäts- oder eine Margenentscheidung?

Verkauft wird er meist als Qualität: weniger fehlgeschlagene Deployments, ein echter Audit-Trail, ein Rollback, das man in einen Rahmenvertrag schreiben kann. Alles richtig. Die größere Zahl steht auf der Kostenseite.

Pipelines pro Kunde bedeuten Wissen pro Kunde. Wer das Branching-Modell eines Kunden gebaut hat, ist der Einzige, der für ihn releasen kann, die Auslastung hängt an Personen und Urlaube werden zum Lieferrisiko. Eine gemeinsame Pipeline-Form ändert drei Dinge.

• Kunden-Onboarding wird Konfiguration statt Projekt.
• Jeder Berater kann jeden Account übernehmen, die Auslastung hängt nicht mehr an einer Person.
• Release-Nachweise sehen für jeden Kunden gleich aus, was Audits und Reviews billig macht.

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

Was prüfen Sie vor der Unterschrift unter einen DevOps-Vertrag?

1. Wächst eine Zeile des Preises mit verbundenen Orgs? Fragen Sie nach dem Betrag für Ihren heutigen Kundenstamm und für den doppelten.
2. Wächst 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 ändert 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 dreißig. Eine kostenlose Essentials-Stufe mit 30 Credits pro Monat gibt es, wenn Sie zuerst einen einzelnen Account durchspielen wollen.

Ehrlich zur Messung: der Verbrauch läuft über Credits, der Zähler misst also Arbeit statt Kunden. Ein Feature-Deployment kostet einen Credit, ein Release in die Produktion zwei, eine KI-Aktion einen zusätzlich, eine Datenoperation vier, und Scale enthält 300 pro Monat. Das ist eine Größe, die Ihr Liefervolumen steuert, nicht eine, die Ihr Vertrieb mit jedem neuen Logo erzeugt.

Zwei Punkte zählen im Partnergeschäft besonders. Serpent installiert nichts in der Kunden-Org und verbindet sich über Standard-APIs, das Onboarding braucht also keine Paketfreigabe und das Offboarding keine Deinstallation. Und weil der Ablauf ticketbasiert ist und Git im Hintergrund läuft, muss der Berater, der einen Account übernimmt, nicht derjenige sein, der ihn aufgesetzt hat.

FAQ

Ist die Abrechnung pro Seat immer schlechter für eine Beratung?

Nein. Vier Berater, die zwanzig Kunden-Orgs betreuen, können pro Seat günstiger fahren als pro Org. Das Problem ist, dass die meisten Verträge beides messen, Sie zahlen also auf der Achse, die zuerst wächst.

Können 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 Großteil des Umsatzes von Boutique-Integratoren.

Bedeutet eine Standardpipeline dasselbe Branching-Modell für 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?

Prüfen 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.