Waarom pricing per seat groeiende Salesforce-teams afstraft

Kort antwoord: pricing per seat kost niet alleen geld, het verandert gedrag. Teams kopen minder seats dan ze mensen hebben, releases lopen door een of twee power users, en de wachtrij die ontstaat kost meer dan de licenties ooit bespaarden. Op Salesforce hakt dat harder in dan elders, omdat juist de mensen die je uitsluit om seats te besparen het werk doen.

Wat is DevOps-pricing per seat, en waarom is het de standaard?

Per seat betekent dat je per benoemde gebruiker met toegang betaalt. Het is de standaard in ontwikkeltooling omdat het makkelijk te begroten is en de omzet meegroeit met het personeelsbestand. De zwakte is goed gedocumenteerd: de kosten schalen met de omvang van je team in plaats van met de geleverde waarde, en waarde volgt zelden het aantal koppen (Schematic).

In Salesforce DevOps is die zwakte scherper, want het releaseproces is geen developeractiviteit alleen. Wie een wijziging terecht moet kunnen verplaatsen:

• Admins die declaratief bouwen en nooit een terminal openen.
• Consultants die in meerdere klantorgs werken.
• Testers die een deployment naar een QA-sandbox nodig hebben.
• Release managers die de kalender bezitten maar niet de code.
• Product owners die simpelweg willen weten wat er in de volgende release zit.

Wat gebeurt er echt als een team seats koopt?

Niemand licentieert iedereen. Er komt budget voor de twee meest technische mensen, en de rest routeert verzoeken via die twee. Daarna volgen drie dingen, in deze volgorde:

1. Er ontstaat een wachtrij. Deployments wachten nu op iemands agenda in plaats van op gereedheid.
2. Kennis concentreert. Die twee mensen zijn de enigen die de pipeline snappen, en dat is een personeelsrisico lang voordat het een kostenprobleem is.
3. Workarounds keren terug. Change sets en handmatige aanpassingen komen terug voor de "kleine" wijzigingen, en drift begint opnieuw.

De tool werd gekocht om een single point of failure in het releaseproces weg te nemen. Pricing per seat bouwt hem opnieuw op, en rekent je vervolgens geld om hem te verbreden.

Wat kost die bottleneck echt?

Reken met je eigen salariscijfers in plaats van die van een leverancier. De vorm van de berekening:

• Tel de mensen die aan een release raken. Developers, admins, consultants, testers, release manager. Acht is gebruikelijk voor een middelgroot Salesforce-team.
• Tel de seats die je echt zou kopen. Meestal twee of drie.
• Prijs het gat in tijd, niet in licenties. Besteedt een senior engineer twee dagen per week aan andermans deployments, dan gaat er ruwweg veertig procent van een seniorsalaris op aan wachtrijbeheer.
• Tel de vertraging erbij. Elke wijziging die drie dagen op een deployvenster wacht, is drie dagen niet geleverde waarde.

Naast elkaar gelegd lopen stacks per gebruiker en vaste tarieven snel uiteen naarmate het team groeit (de kostenanalyse van Hyperping). Maar het licentieverschil is de kleine helft van het argument. De dure helft is het gedrag dat het prijsmodel uitlokt.

Waarom raakt dit groeiende teams het hardst?

Drie factoren stapelen:

• Aantal medewerkers. Elke aanname is een nieuwe prijsbeslissing, dus groei wordt een terugkerend budgetgesprek over wie mag deployen.
• Aantal orgs. Consultancies en ISV's beheren meerdere orgs. Pricing die schaalt met gebruikers en orgs werkt precies tegen de bedrijven wier marge afhangt van veel klanten efficient bedienen.
• Verloop en inhuur. Korte opdrachten maken benoemde seats administratief duur, dus externen worden standaard uitgesloten en de bottleneck wordt strakker.

Per seat werkt prima voor een stabiel team van vijf. Het presteert het slechtst bij de groeiende, gemengde, multi-org teams die DevOps het hardst nodig hebben.

Waar moet je in plaats daarvan op letten?

• Onbeperkt aantal gebruikers. Is toegang een budgetbeslissing, dan wordt adoptie begrensd door finance in plaats van door behoefte.
• Prijs onafhankelijk van het aantal orgs. Meer orgs beheren hoort geen boete te zijn.
• Transparante metering. Vaste toegang met verbruiksmeting is eerlijk, zolang de meter zichtbaar is en de eenheid uit te leggen.
• Een gratis laag die echt een laag is. Geen aftelklok tot een verkoopgesprek.

Zo is Serpent geprijsd. Scale kost 699 dollar per bedrijf per maand met onbeperkt gebruikers, ongeacht hoeveel orgs je draait, met 0 dollar setup en maandelijks opzegbaar. Verbruik wordt gemeten in credits (300 per maand op Scale, bijkopen voor 1 dollar per credit), zodat de meter zichtbaar blijft in plaats van verstopt in een aantal seats. Essentials is echt gratis met 30 credits per maand, zonder creditcard en zonder tijdslimiet, zodat het hele team er vanaf dag een in zit. Bekijk hoe Serpent het prijst.

FAQ

Is pricing per seat altijd het verkeerde model?

Nee. Voor een klein, stabiel team waarin iedereen die de tool aanraakt een fulltime gebruiker is, is het redelijk. Het verouderd zodra admins, testers en consultants deel uitmaken van je releaseproces.

Is vaste pricing niet gewoon per seat met extra stappen?

Alleen als de leverancier gebruikers in de kleine lettertjes begrenst. Vaste pricing die echt onbeperkte gebruikers toestaat, verandert wie er mag deployen, en dat is het hele punt.

En credits dan? Is dat niet gewoon een andere meter?

Het is een meter, en zo hoort het ook genoemd te worden. Het verschil zit in wat er gemeten wordt: verbruik dat je kunt plannen en zien, in plaats van koppen, wat samenwerking afstraft.

Hoe onderbouw ik dit intern?

Presenteer het niet als licentievergelijking. Tel de deployments die op de agenda van een persoon wachten en zet daar een salarisbedrag tegenover.