Bij traditionele software bestaat de prijs meestal uit een eenmalig licentiebedrag en een bedrag voor onderhoud en ondersteuning. De initiële kosten zijn vaak hoog maar redelijk doorzichtig. Bij SaaS wordt er meestal een jaarlijks of maandelijks bedrag betaald afhankelijk van het gebruik. Je kan met veel lagere kosten beginnen maar de werkelijke kosten op lange termijn zijn soms onduidelijk. Dit komt doordat het prijsmodel vaak complex is en het gebruik vooraf moeilijk is in te schatten.
Het idee achter betalen op basis van gebruik is te rechtvaardigen voor zowel klant als leverancier. Voor de klant betekent dit dat er een directere relatie is tussen de kosten en toegevoegde waarde. Als je het systeem nog niet zo veel gebruikt heb je er dus nog niet zo veel aan en betaal je minder. Als het gebruik toeneemt heeft het systeem zich in de praktijk bewezen en kunnen extra kosten ook gerechtvaardigd worden.
Vanuit de leverancier gezien kosten klanten die het systeem meer gebruiken meer bandbreedte, opslag, hardware en technische ondersteuning. De grootste kostenpost voor de leverancier is de productontwikkeling. Klanten die de SaaS meer gebruiken leveren meer omzet om de ontwikkeling te financieren. Prijs per gebruik lijkt dus een goed idee maar hoe ga je het gebruik meten?
Object: Gebruikers van een SaaS maken objecten aan zoals bijvoorbeeld een factuur, project of urenstaat. Voor elk type object kan een prijs worden bepaald in analogie van een prijs per sms bij een telecom provider. Er is hier dus een directe relatie met gebruik. Een probleem is dat klanten vooraf moeilijk een inschatting kunnen maken. Het is ook de vraag of er een aparte prijs moet komen voor gearchiveerde of afgesloten objecten.
Transactie: Bij een SaaS voor bijvoorbeeld betalingen of boekhouden kan een prijs per transactie of boeking worden afgesproken. Het maakt dan niet uit welk type objecten en hoeveel objecten er intern aangemaakt worden. Prijs per transactie is minder geschikt voor geïntegreerde applicaties waarbij veel soorten transacties plaatsvinden en toepassingen voor beheer van informatie waarbij relatief weinig transacties plaatsvinden.
Opslag: De data opslag per klant wordt bepaald door het aantal objecten in de database en bestanden die geupload zijn. Data opslag als enige parameter voor meten van gebruik is goed voor file sharing of backup toepassingen maar niet voor de meeste SaaS oplossingen. Er is vaak geen directe relatie tussen de grootte van een bestand en de waarde voor de klant. De benodigde opslag voor objecten in de database hangt af van technische factoren als meta-data, efficiëntie en redundantie en zijn voor de klant moeilijk in te schatten.
Gebruiker: De meeste SaaS aanbieders rekenen een bedrag per gebruiker. Het voordeel is dat het aantal gebruikers vooraf goed is in te schatten en klanten dit al gewend zijn bij traditionele software. Een nadeel van een vast bedrag per gebruiker is er bij uitbreiding van SaaS naar de extended enterprise, zoals leveranciers, klanten en thuiswerkers. Voor externe gebruikers die af en toe een melding, order of urenstaat indienen zal een andere prijs gelden dan voor interne medewerkers die er de hele dag mee werken.
Module: De meeste SaaS platforms hebben verschillende modules en er kan een prijs per module bepaald worden. Bij een vaste prijs per module is er geen directe relatie met intensiviteit van gebruik dus er zal een combinatie gemaakt moeten worden met prijs per gebruiker. Dit levert extra complexiteit op en het vormt een belemmering voor klanten om het systeem breder in te zetten. Als er meer modules gebruikt worden zal het aantal gebruikers ook toenemen dus een prijs per module is dan ook niet nodig.
Het is in de praktijk bijna onmogelijk om een prijsmodel aan te bieden met slechts één parameter. Een prijs per gebruiker is in de meeste gevallen een goede optie maar dan nog zullen er ten minste een aantal 'fair use'-parameters bepaald moeten worden ter voorkoming van misbruik. Deze parameters hebben geen directe invloed op de prijs maar bepalen het kader van het gebruik, zoals bijvoorbeeld een maximale opslag capaciteit en/of aantal objecten. Een goed prijsmodel is eenvoudig, voorspelbaar, voorkomt misbruik en nodigt uit om de SaaS steeds verder in te zetten.
Helder artikel en kan de problematiek onderschrijven. Per gebruiker is makkelijk, maar stel dat je een e-HRM hebt. 1 Persoon kan dan een organisatie van 200 mensen bedienen en bovendien kunnen ze de credentials van die gebruiker onderling delen (met andere P&O mensen). Elke medewerker van een organisatie een account geven is dan ook niet realistisch (of de prijs met gebruiker moet dan drastisch omlaag).
Dan lijkt een prijs voor elke persooneelslid in dienst een idee. Maarja, stel dat je een CRM module aanbied… et cetera.
SaaS in de vorm van een applicatie kan best een lastig verdienmodel hebben.
Het delen van een gebruikersaccount door verschillende personen zal door veel klanten als ongewenst beschouwd worden. Je wilt vaak taken aan personen toekennen en bijhouden wie welke acties uitgevoerd heeft. Daarnaast hebben verschillende personen meestal verschillende rollen en authorisaties. Het is meestal niet gewenst dat iedereen offertes kan goedkeuren of personeelsgegevens kan inzien. Klanten hebben er zelf dus belang bij om gebruikers op naam te registreren. Daarbij moet er in het prijsmodel wel rekening gehouden worden met het soort gebruikers, bijvoorbeeld een lage prijs per gebruiker die af en toe een urenstaat indient of een bestelling plaatst en een hogere prijs voor gebruikers van een servicedesk die de processen afhandelen.
Het onderschrijft in ieder geval dit artikel dat een prijsmodel lastig is, en niet eenvoudig (ook niet om te begrijpen of te vergelijken).
Zoals ik dit lees, is het produkt “SAAS” zo onrijp dat je je als klant heel goed moet realiseren dat dit misschien toch te duur wordt, en je beter je software in huis houdt. Een eigen server met remote service heeft waarschijnlijk een beter voorspelbaar kostenplaatje.
Complex betekent niet automatisch onrijp. Bij een eigen server heb je veel verborgen kosten zoals interne uren voor installatie en beheer van hardware en software, maken van backups, oplossen van storingen, synchronisatie met een disaster recovery omgeving, installeren van patches. Bij een SaaS met een duidelijk prijsmodel weet je vooraf precies wat de kosten zijn.
Hoezo “verborgen kosten”? Patches, Synchonisatie, Backup horen bij een normaal beheerskontrakt, de installatie bij de aanschaf.
Dat wordt al 25 jaar met vergelijkbare kontrakten geregeld, dat soort prijsmodellen zijn al heel lang bekend i.t.t. die voor Saas, zoals in het artikel aangegeven wordt.