Het margeprobleem van prijzen per org in Salesforce DevOps

Kort gezegd: de meeste Salesforce DevOps-tools rekenen af per seat of per gekoppelde org. Dat is redelijk voor een eindklant met een productie-org, maar stilletjes bestraffend voor een consultancy met tien of twintig client-orgs, omdat elke nieuwe klant licentiekosten toevoegt voordat er een declarabel uur tegenover staat. Standaardiseren op een pipeline waarvan de prijs niet meebeweegt met het aantal orgs maakt van tooling een vaste in plaats van een variabele kost, en dat is eerst een margebeslissing en pas daarna een kwaliteitsbeslissing.

Waarom raakt prijzen per seat en per org juist consultancies het hardst?

Een eindklant groeit langs een as: mensen. Er is een productie-org, een paar sandboxes en een team dat langzaam groter wordt. Een tool per seat volgt die groei eerlijk.

Een boutique SI groeit langs een andere as: orgs. Tien klanten betekent tien productie-orgs, hun sandboxes en meestal ook nog scratch orgs. De teller loopt precies op de as waarop het bedrijf uitbreidt, en die uitbreiding is op zichzelf niet declarabel. Daaruit volgen drie structurele problemen.

• De kosten komen voor de omzet. Je koppelt en configureert een client-org tijdens onboarding, en dat is meestal fixed fee of onbetaald.
• Verloop is asymmetrisch. De klant vertrekt, de contracttermijn niet.
• Doorbelasten is lastig. Klanten betalen licenties die ze in hun eigen org zien staan. De jouwe veel minder graag.

Waar rekenen de gepubliceerde prijslijsten eigenlijk op af?

Lees de pagina's van de leveranciers zelf in plaats van de samenvattingen. Gearset publiceert lijstprijzen: kern-deployment wordt per Gearset-gebruiker per maand gerekend, terwijl automation en CI/CD apart per team worden verkocht, waarbij elke tier een vast aantal CI/CD-doel-orgs bevat. De org-as bestaat dus wel degelijk, hij zit alleen in de automation-regel en niet in het kopcijfer.

Copado publiceert geen lijstprijzen. Essentials begint gratis en de enterprise-tier leidt naar een gesprek. Voor een partner is dat op zichzelf een kost: je kunt geen brutomarge modelleren op een bedrag dat je eerst moet onderhandelen.

Geen van beide modellen is oneerlijk. Beide zijn ontworpen voor een klant die de orgs zelf bezit. Een partner die ze slechts leent is in dat ontwerp een uitzonderingsgeval.

Wat doet de org-as met een groeiende klantenportefeuille?

Modelleer de vorm, niet de getallen. Zodra een regel op je factuur meebeweegt met gekoppelde orgs, groeit je toolingkost mee met je klantenlijst terwijl je omzet meegroeit met declarabele uren. Die twee lijnen lopen uiteen elke keer dat je werk wint dat je niet meteen kunt bemensen.

De sprongen doen het meeste pijn. Als een automation-tier vijf doel-orgs bevat en de volgende vijftien, kan je zesde klant een hele tier duurder uitvallen dan je vijfde. Die sprong zegt niets over de inspanning van die zesde opdracht, en stond niet in het voorstel dat je al had getekend.

Is een pipeline standaardiseren een kwaliteits- of een margebeslissing?

Het wordt meestal verkocht als kwaliteit: minder mislukte deploys, een echt audittrail, een rollback die je in een MSA durft te zetten. Allemaal waar. Het grotere getal staat aan de kostenkant.

Pipelines per klant betekenen kennis per klant. De consultant die het branching-model van een klant heeft gebouwd, is de enige die voor die klant kan releasen, dus bezettingsgraad hangt aan personen en vakanties worden leveringsrisico. Een gedeelde pipelinevorm verandert drie dingen.

• Een klant onboarden wordt configuratie in plaats van een project.
• Elke consultant kan elk account overnemen, dus bezetting hangt niet meer aan een persoon.
• Releasebewijs ziet er voor elke klant hetzelfde uit, wat audits en QBR's goedkoop maakt.

Standaardiseren betekent niet dat elke klant identiek werkt. Het betekent dat de stappen vastliggen (ticket, branch, validatie, goedkeuring, deploy, rollback) en alleen de configuratie verschilt.

Wat moet je controleren voordat je een DevOps-contract tekent?

1. Beweegt een regel van de prijs mee met gekoppelde orgs? Vraag het bedrag bij je huidige portefeuille en bij het dubbele.
2. Beweegt hij mee met seats, en kan een stakeholder bij de klant een release goedkeuren zonder er een te kopen?
3. Wat gebeurt er als een klant halverwege de termijn vertrekt?
4. Kan een consultant die geen Git gebruikt zelfstandig een release draaien?
5. Installeert de tool iets in de org van de klant? Een managed package betekent elke keer goedkeuring bij binnenkomst en een uninstall bij vertrek.
6. Als een klant ISV is, dekt dezelfde pipeline dan 1GP- en 2GP-packageworkflows, of is dat een aparte aankoop?

Wat verandert er bij een vaste prijs per bedrijf?

Serpent rekent per bedrijf af in plaats van per seat of per org. Scale kost $699 per bedrijf per maand met onbeperkte gebruikers en $0 setup, en de prijs beweegt niet mee of je nu drie client-orgs koppelt of dertig. Er is een gratis Essentials-tier met 30 credits per maand als je er eerst een enkel account doorheen wilt draaien.

Eerlijk over de meter: het verbruik loopt op credits, dus de teller volgt werk in plaats van klanten. Een feature-deployment is een credit, een release naar productie twee, een AI-actie telt er een bij, een data-operatie is vier, en Scale bevat er 300 per maand. Dat is een variabele die je leveringsvolume bepaalt, niet een die je salesteam creeert door een klant binnen te halen.

Twee details tellen extra voor partnerwerk. Serpent installeert niets in de org van de klant en werkt via standaard-API's, dus onboarding vraagt geen package-goedkeuring en offboarding geen uninstall. En omdat de workflow ticketgestuurd is met Git op de achtergrond, hoeft de consultant die een account overneemt niet degene te zijn die het heeft opgezet.

FAQ

Is prijzen per seat altijd slechter voor een consultancy?

Nee. Vier consultants die twintig client-orgs bedienen kunnen per seat goedkoper uit zijn dan per org. Het probleem is dat de meeste contracten beide meten, dus je betaalt op de as die het eerst groeit.

Kunnen we DevOps-tooling doorbelasten aan de klant?

Soms, als regel in een managed service-retainer. Bij fixed-fee implementatiewerk is het veel lastiger, en daar zit het grootste deel van de omzet van een boutique SI.

Betekent een standaardpipeline dat elke klant hetzelfde branching-model krijgt?

Nee. Houd de stappen identiek en laat branching, omgevingen en goedkeuringspoorten configuratie per klant blijven.

En klanten die zelf ISV zijn?

Controleer of packageworkflows inbegrepen zijn en geen add-on. Serpent dekt 1GP, 2GP en AppExchange-releaseworkflows op elk plan, ook het gratis plan.

Hoe lang duurt het om een klant naar een gedeelde pipeline te verhuizen?

Serpent is per workspace in minder dan 15 minuten opgezet en de onboardingsessies zijn gratis, dus de beperking is meestal het changevenster van de klant, niet de tooling.