Prijsmodellen

Een goed prijsmodel zorgt ervoor dat u stabiel blijft naarmate het aantal tenants groeit en wanneer u nieuwe functies toevoegt. Een belangrijke overweging bij het ontwikkelen van een commerciële multitenant-oplossing is het ontwerpen van prijsmodellen voor uw product.

Wanneer u het prijsmodel voor uw product bepaalt, moet u het rendement op waarde (ROV) voor uw klanten in balans brengen met de kosten van verkochte goederen (COGS) om de service te leveren. Het aanbieden van flexibelere commerciële modellen (voor een oplossing) kan de ROV voor klanten verhogen, maar het kan ook de architectuur en commerciële complexiteit van de oplossing verhogen (en dus ook uw COGS verhogen).

Enkele belangrijke overwegingen waar u rekening mee moet houden bij het ontwikkelen van prijsmodellen voor een oplossing zijn als volgt:

• Is de COGS hoger dan de winst die u met de oplossing verdient?
• Kan de COGS na een bepaalde periode veranderen op basis van groei in gebruikers of wijzigingen in gebruikspatronen?
• Hoe moeilijk is het om de informatie te meten en vast te nemen die nodig is om het prijsmodel te gebruiken? Als u bijvoorbeeld van plan bent om uw klanten te factureren op basis van het aantal API-aanroepen dat ze maken, hebt u dan vastgesteld hoe u de API-aanroepen meet die door elke klant worden gemaakt?
• Is uw winstgevendheid afhankelijk van de garantie dat klanten uw oplossing op een beperkte manier gebruiken?
• Als een klant de oplossing te veel gebruikt, betekent dit dan dat u niet langer onrendelijk bent?

Er zijn enkele belangrijke factoren die van invloed zijn op uw winstgevendheid:

• Prijsmodellen voor Azure-service. De prijsmodellen van de Azure- of services van derden waaruit uw oplossing is gemaakt, kunnen van invloed zijn op welke modellen voordelig zijn.
• Servicegebruikspatronen. Gebruikers hebben mogelijk alleen toegang nodig tot uw oplossing tijdens hun werkuren of hebben mogelijk slechts een klein percentage gebruikers met een hoog volume. Kunt u uw COGS verminderen door de ongebruikte capaciteit te verminderen wanneer uw gebruik laag is?
• Storage groei. De meeste oplossingen verzamelen gegevens in de tijd. Meer gegevens betekent hogere kosten voor het opslaan en beveiligen ervan, waardoor uw winstgevendheid per tenant wordt verkleind. Kunt u opslagquota instellen of een gegevensretentieperiode afdwingen?
• Isolatie van tenants. Het tenancymodel dat u gebruikt, is van invloed op het isolatieniveau tussen uw tenants. Als u uw resources deelt, moet u dan overwegen hoe tenants de service mogelijk te veel gebruiken of misbruiken? Wat is de invloed op uw COGS en prestaties voor iedereen? Sommige prijsmodellen zijn niet rendabel zonder extra besturingselementen voor resourcetoewijzing. U moet bijvoorbeeld servicebeperking implementeren om een model met een vast tarief duurzaam te maken.
• Levenscyclus van tenants. Oplossingen met een hoog klantverloop of services waarvoor meer bij de ingebruik nemen is vereist, kunnen bijvoorbeeld een lagere winstgevendheid hebben, met name als ze zijn geprijsd met behulp van een model op basis van verbruik.
• Vereisten voor serviceniveau. Tenants die hogere serviceniveaus nodig hebben, kunnen betekenen dat uw oplossing niet meer rendabel is. Het is essentieel dat u duidelijk bent over de verwachtingen op serviceniveau van uw klanten en eventuele verplichtingen die u hebt, zodat u uw prijsmodellen dienovereenkomstig kunt plannen.

Algemene prijsmodellen

Er zijn een aantal algemene prijsmodellen die vaak worden gebruikt met oplossingen voor meerderetenant. Elk van deze prijsmodellen heeft commerciële voordelen en risico's met zich mee gebracht en vereist aanvullende architecturale overwegingen. Het is belangrijk om de verschillen tussen deze prijsmodellen te begrijpen, zodat u ervoor kunt zorgen dat uw oplossing ondoordrijf blijft naarmate deze zich verder ontwikkelt.

Prijzen op basis van verbruik

Een verbruiksmodel wordt ook wel pay-as-you-go of PAYG genoemd. Naarmate het gebruik van uw service toeneemt, neemt uw omzet toe:

Wanneer u het verbruik meet, kunt u eenvoudige factoren overwegen, zoals de hoeveelheid gegevens die aan de oplossing wordt toegevoegd. U kunt ook een combinatie van gebruikskenmerken samen overwegen. Verbruiksmodellen bieden een aantal voordelen, maar kunnen lastig te implementeren zijn in een multitenant-oplossing.

Voordelen: Vanuit het perspectief van uw klanten is er een minimale investering vooraf vereist om uw oplossing te gebruiken, zodat dit model een lage drempel voor toegang heeft. Vanuit uw perspectief als serviceoperator nemen uw hosting- en beheerkosten toe naarmate het gebruik van uw klanten en uw omzet toeneemt. Door deze toename kan het een zeer schaalbaar prijsmodel worden. Prijsmodellen voor verbruik werken vooral goed wanneer de Azure-services die in de oplossing worden gebruikt, ook op basis van verbruik zijn.

Complexiteit en operationele kosten: Verbruiksmodellen zijn afhankelijk van nauwkeurige metingen van het gebruik en van het splitsen van dit gebruik per tenant. Dit kan lastig zijn, met name in een oplossing met veel gedistribueerde onderdelen. U moet gedetailleerde verbruiksrecords bewaren voor facturering en controle.

Risico's: Prijzen voor verbruik kunnen uw klanten stimuleren om hun gebruik van uw systeem te verminderen om hun kosten te verlagen. Daarnaast leiden verbruiksmodellen tot onvoorspelbare inkomstenstromen. U kunt dit verhelpen door capaciteitsreserveringen aan te bieden, waarbij klanten vooraf betalen voor een bepaalde mate van verbruik. Als serviceprovider kunt u deze omzet gebruiken om te investeren in verbeteringen in de oplossing, om de operationele kosten te verlagen of om het rendement op de waarde te verhogen door functies toe te voegen.

Prijzen per gebruiker

Een prijsmodel per gebruiker omvat het in rekening brengen van kosten voor uw klanten op basis van het aantal personen dat uw service gebruikt, zoals wordt gedemonstreerd in het volgende diagram.

Prijsmodellen per gebruiker zijn zeer gebruikelijk, vanwege hun eenvoud bij het implementeren in een multitenant-oplossing. Ze zijn echter gekoppeld aan verschillende commerciële risico's.

Voordelen: Wanneer u uw klanten voor elke gebruiker facturziet, is het eenvoudig om uw omzetstroom te berekenen en te voorspellen. Als u bovendien redelijk consistente gebruikspatronen voor elke gebruiker hebt, neemt de omzet toe met hetzelfde tarief als bij de acceptatie van de service, waardoor dit een schaalbaar model wordt.

Complexiteit en operationele kosten: Modellen per gebruiker zijn vaak eenvoudig te implementeren. In sommige gevallen moet u echter het verbruik per gebruiker meten, wat u kan helpen om ervoor te zorgen dat de COGS voor één gebruiker niet te hoog is. Door het verbruik te meten en aan een bepaalde gebruiker te koppelen, kunt u de operationele complexiteit van uw oplossing verhogen.

Risico's: Verschillende verbruikspatronen van gebruikers kunnen leiden tot een verminderde winstgevendheid. Zware gebruikers van de oplossing kunnen bijvoorbeeld meer kosten om te bedienen dan lichte gebruikers. Bovendien wordt het werkelijke rendement op de waarde (ROV) voor de oplossing niet weerspiegeld door het werkelijke aantal aangeschafte gebruikerslicenties.

Prijzen per actieve gebruiker

Dit model is vergelijkbaar met de prijzen pergebruiker, maar in plaats van dat de klant vooraf een toezegging moet doen voor het aantal verwachte gebruikers, worden er alleen kosten in rekening gebracht voor gebruikers die zich daadwerkelijk aanmelden bij en de oplossing gebruiken gedurende een bepaalde periode (zoals wordt weergegeven in het volgende diagram).

U kunt dit meten in elke zinnige periode. Maandelijkse perioden komen veel voor en vervolgens wordt deze metrische gegevens vaak vastgelegd als maandelijks actieve gebruikers of MAU.

Voordelen: Vanuit het perspectief van uw klanten vereist dit model een lage investering en een laag risico, omdat er weinig verspilling is; ongebruikte licenties zijn niet factureerbaar. Dit maakt het bijzonder aantrekkelijk wanneer u de oplossing marketingt of de oplossing voor grotere zakelijke klanten groeit. Vanuit uw perspectief als de service-eigenaar wordt uw ROV nauwkeuriger weergegeven aan de klant door het aantal maandelijks actieve gebruikers.

Complexiteit en operationele kosten: Voor modellen per actieve gebruiker moet u het werkelijke gebruik registreren en het beschikbaar maken voor een klant als onderdeel van de factuur. Het meten van het verbruik per gebruiker helpt om ervoor te zorgen dat de winstgevendheid van de cogs voor één gebruiker wordt gehandhaafd, maar ook hier is extra werk nodig om het verbruik voor elke gebruiker te meten.

Risico's: Net als bij prijzen per gebruiker bestaat het risico dat de verschillende verbruikspatronen van afzonderlijke gebruikers van invloed kunnen zijn op uw winstgevendheid. Vergeleken met prijzen per gebruiker hebben modellen voor gebruikers per actieve gebruiker een minder voorspelbare omzetstroom. Bovendien bieden kortingsprijzen geen handige manier om groei te stimuleren.

Prijzen per eenheid

In veel systemen is het aantal gebruikers niet het element dat het grootste effect heeft op de algehele cogs. In apparaatgeoriënteerde oplossingen, ook wel internet of things of IoT genoemd, heeft het aantal apparaten vaak de grootste impact op cogs. In deze systemen kan een prijsmodel per eenheid worden gebruikt, waarbij u definieert wat een eenheid is, zoals een apparaat. Zie het volgende diagram.

Daarnaast hebben sommige oplossingen zeer variabele gebruikspatronen, waarbij een klein aantal gebruikers een onevenredige invloed heeft op de COGS. In een oplossing die bijvoorbeeld wordt verkocht aan fysieke detailhandelaren, is een prijsmodel per winkel mogelijk geschikt.

Voordelen: In systemen waarbij afzonderlijke gebruikers geen significant effect hebben op cogs, is prijs per eenheid een betere manier om de realiteit weer te geven van hoe het systeem wordt geschaald en wat de resulterende impact op cogs is. Het kan ook de afstemming op de werkelijke gebruikspatronen voor een klant verbeteren. Voor veel IoT-oplossingen, waarbij elk apparaat een voorspelbare en constante hoeveelheid verbruik genereert, kan dit een effectief model zijn om de groei van uw oplossing te schalen.

Complexiteit en operationele kosten: Over het algemeen zijn prijzen per eenheid eenvoudig te implementeren en zijn de operationele kosten redelijk laag. De operationele kosten kunnen echter hoger worden als u het gebruik wilt onderscheiden en bijhouden op basis van afzonderlijke eenheden, zoals apparaten of winkels. Door het verbruik per eenheid te meten, kunt u ervoor zorgen dat uw winstgevendheid behouden blijft, omdat u de COGS voor één eenheid kunt bepalen.

Risico's: De risico's van een prijsmodel per eenheid zijn vergelijkbaar met de prijzen per gebruiker. Verschillende verbruikspatronen voor sommige eenheden kunnen betekenen dat u een verminderde winstgevendheid hebt, bijvoorbeeld als sommige apparaten of winkels veel zwaardere gebruikers van de oplossing zijn dan andere.

Prijzen op basis van functies en serviceniveau

U kunt ervoor kiezen om uw oplossing aan te bieden met verschillende functionaliteitsniveaus op verschillende prijspunten. U kunt bijvoorbeeld twee maandelijkse vaste tarieven of prijzen per eenheid bieden, een basisaanbieding met een subset van beschikbare functies en de andere met de uitgebreide set functies van uw oplossing. Zie het volgende diagram.

Dit model kan ook verschillende serviceovereenkomsten bieden voor verschillende lagen. Uw basislaag kan bijvoorbeeld een uptime van 99,9% bieden, terwijl een Premium-laag 99,99% kan bieden. De hogere SLA (Service Level Agreement) kan worden geïmplementeerd met behulp van services en functies die hogere beschikbaarheidsdoelen mogelijk maken.

Hoewel dit model commercieel voordelig kan zijn, zijn er wel goed ontwikkelde engineeringsmethoden nodig. Met een zorgvuldige overweging kan dit model zeer effectief zijn.

Voordelen: Prijzen op basis van functies zijn vaak aantrekkelijk voor klanten, omdat ze een laag kunnen selecteren op basis van de functieset of het serviceniveau dat ze nodig hebben. Het biedt u ook een duidelijk pad voor het upsellen van uw klanten met nieuwe functies of hogere tolerantie voor degenen die dit nodig hebben.

Complexiteit en operationele kosten: Prijsmodellen op basis van functies kunnen complex zijn om te implementeren, omdat uw oplossing op de hoogte moet zijn van de functies die beschikbaar zijn in elke prijscategorie. Functie-schakelaars kunnen een effectieve manier zijn om toegang te bieden tot bepaalde subsets van functionaliteit, maar hiervoor is doorlopend onderhoud vereist. Schakelknopen verhogen ook de overhead om een hoge kwaliteit te garanderen, omdat er meer codepaden zijn om te testen. Het inschakelen van hogere servicebeschikbaarheidsdoelen in sommige lagen kan extra complexiteit van de architectuur vereisen, om ervoor te zorgen dat de juiste set infrastructuur wordt gebruikt voor elke laag, en dit proces kan de operationele kosten van de oplossing verhogen.

Risico's: Prijsmodellen op basis van functies kunnen ingewikkeld en verwarrend zijn als er te veel lagen of opties zijn. Bovendien kan de overhead bij dynamisch schakelende functies de snelheid vertragen waarmee u aanvullende functies levert.

Freemium-prijzen

U kunt ervoor kiezen om een gratis laag van uw service aan te bieden, met basisfunctionaliteit en geen garanties op serviceniveau. Vervolgens kunt u een afzonderlijke betaalde laag aanbieden, met extra functies en een formele service level agreement (zoals weergegeven in het volgende diagram).

De gratis laag kan ook worden aangeboden als een proefversie met beperkte tijd, en tijdens de proefversie hebben uw klanten mogelijk volledige of beperkte functionaliteit beschikbaar. Dit wordt aangeduid als een freemium-model, dat in grote getale een uitbreiding is van het prijsmodel op basis van functies.

Voordelen: Het is heel eenvoudig om een oplossing op de markt te brengen wanneer deze gratis is.

Complexiteit en operationele kosten: Alle complexiteits- en operationele kosten zijn van toepassing op basis van het prijsmodel op basis van functies. U moet echter ook rekening houden met de operationele kosten voor het beheren van gratis tenants. Mogelijk moet u ervoor zorgen dat verouderde tenants worden ge-offboard of verwijderd en moet u een duidelijk retentiebeleid hebben, met name voor gratis tenants. Wanneer u een tenant naar een betaalde laag promovert, moet u de tenant mogelijk tussen Azure-services verplaatsen om hogere SLA's te verkrijgen.

Risico's: U moet ervoor zorgen dat u een ROV biedt die hoog genoeg is voor tenants om over te schakelen naar een betaalde laag. Daarnaast moeten de kosten voor het leveren van uw oplossing aan klanten in de gratis laag worden gedekt door de winstmarge van degenen die in betaalde lagen zitten.

Vast tarief

In dit model gaat u een vast tarief in rekening brengen voor een tenant voor toegang tot uw oplossing, voor een bepaalde periode. Dezelfde prijzen zijn van toepassing, ongeacht hoeveel ze de service gebruiken, het aantal gebruikers, het aantal apparaten dat ze verbinden of andere metrische gegevens. Zie het volgende diagram.

Dit is het eenvoudigste model voor het implementeren en voor klanten om te begrijpen, en dit wordt vaak aangevraagd door zakelijke klanten. Het kan echter eenvoudig onbruikbaar worden als u nieuwe functies wilt blijven toevoegen of als het verbruik van tenants toeneemt zonder extra omzet.

Voordelen: Vasttarieven zijn eenvoudig te verkopen en het is eenvoudig voor uw klanten om inzicht te krijgen in en budgetten voor te stellen.

Complexiteit en operationele kosten: Prijsmodellen met een vast tarief kunnen eenvoudig worden geïmplementeerd omdat factureringsklanten geen meting of traceringsverbruik nodig hebben. Hoewel dit niet essentieel is, is het raadzaam om het verbruik per tenant te meten om ervoor te zorgen dat u DEG's nauwkeurig meet en om ervoor te zorgen dat uw winstgevendheid behouden blijft.

Risico's: Als u tenants hebt die uw oplossing intensief gebruiken, is het eenvoudig om dit prijsmodel onprofiteerbaar te maken.

Kortingsprijzen

Zodra u uw prijsmodel hebt gedefinieerd, kunt u ervoor kiezen om commerciële strategieën te implementeren om groei te stimuleren met kortingsprijzen. Kortingsprijzen kunnen worden gebruikt met prijsmodellen voor verbruik, per gebruiker en per eenheid.

Veelvoorkomende prijspatronen voor korting zijn onder andere:

• Vaste prijzen. U hebt dezelfde kosten voor elke gebruiker, eenheid of hoeveelheid verbruik, ongeacht hoeveel er is gekocht of verbruikt. Dit is de eenvoudigste aanpak. Klanten die uw oplossing intensief gebruiken, kunnen echter het gevoel hebben dat ze kunnen profiteren van schaalvoordelen door korting te krijgen.
• Digressieve prijzen. Wanneer klanten meer eenheden kopen of verbruiken, verlaagt u de kosten per eenheid. Dit is commercieel aantrekkelijker voor klanten.
• Prijzen voor stappen. U verlaagt de kosten per eenheid, omdat klanten meer kopen. U doet dit echter in stapwijzigingen, op basis van vooraf gedefinieerde hoeveelheidsbereiken. U kunt bijvoorbeeld een hogere prijs in rekening brengen voor de eerste 100 gebruikers, vervolgens een lagere prijs voor de 101e tot 200e gebruiker en daarna weer een lagere prijs. Dit kan efficiënter zijn.

Het volgende diagram illustreert deze prijspatronen.

Kortingen voor niet-productieomgevingen

In veel gevallen hebben klanten toegang nodig tot een niet-productieomgeving die ze kunnen gebruiken voor testen, training of voor het maken van hun eigen interne documentatie. Niet-productieomgevingen hebben doorgaans lagere verbruiksvereisten en lagere operationele kosten. Niet-productieomgevingen zijn bijvoorbeeld vaak niet onderworpen aan serviceovereenkomsten (SLA's) en tarieflimieten kunnen worden ingesteld op lagere waarden. U kunt ook agressiever automatisch schalen overwegen voor uw Azure-services.

Klanten verwachten ook vaak dat niet-productieomgevingen aanzienlijk goedkoper zijn dan hun productieomgevingen. Er zijn verschillende alternatieven die mogelijk geschikt zijn wanneer u niet-productieomgevingen biedt:

• Bied een freemium-laagaan, zoals u dat mogelijk al doet voor betaalde klanten. Dit moet zorgvuldig worden bewaakt, omdat sommige organisaties veel test- en trainingsomgevingen kunnen maken, die extra resources verbruiken om te werken.

  Notitie

  Tijdelijke proefversies met freemium-lagen zijn doorgaans niet geschikt voor test- en trainingsomgevingen. Klanten hebben meestal hun niet-productieomgevingen nodig om beschikbaar te zijn voor de levensduur van de productieservice.

• Bied een test- of trainingslaag van uw service aan, met lagere gebruikslimieten. U kunt ervoor kiezen om de beschikbaarheid van deze laag te beperken tot klanten die een bestaande betaalde tenant hebben.
• Bied een korting per gebruiker, per actievegebruiker of per eenheid voor niet-productieten tenants, met een lagere of geen service level agreement.
• Voor tenants die gebruikmaken van een vast tarief,kunnen niet-productieomgevingen worden onderhandeld als onderdeel van de overeenkomst.

Niet-rendabele prijsmodellen

Een niet-rendabel prijsmodel kost u meer om de service te leveren dan de omzet die u verdient. U kunt bijvoorbeeld een vast tarief per tenant in rekening brengen zonder limieten voor uw service, maar vervolgens bouwt u uw service met Op verbruik gebaseerde Azure-resources en zonder gebruikslimieten per tenant. In dit geval loopt u mogelijk het risico dat uw tenants uw service te veel gebruiken, waardoor het niet rendabel is om ze te bedienen.

Over het algemeen wilt u niet-rendabele prijsmodellen voorkomen. Er zijn echter situaties waarin u ervoor kunt kiezen om een niet-rendabel prijsmodel te gebruiken, waaronder:

• Er wordt een gratis service aangeboden om groei mogelijk te maken.
• Extra inkomstenstromen worden geleverd door services of invoegfuncties.
• Het hosten van een specifieke tenant biedt een andere commerciële waarde, zoals het gebruik ervan als anker-tenant in een nieuwe markt.

In het geval dat u per ongeluk een niet-rendabel prijsmodel maakt, zijn er enkele manieren om de risico's die ermee gepaard gaan te beperken, waaronder:

• Beperk het gebruik van de service via gebruikslimieten.
• Het gebruik van capaciteitsreserveringen vereisen.
• Vraag de tenant om over te gaan naar een hogere functie- of servicelaag.

Riskante prijsmodellen

Wanneer u een prijsmodel voor een oplossing implementeert, moet u meestal veronderstellingen doen over hoe het wordt gebruikt. Als deze veronderstellingen onjuist blijken te zijn of als de gebruikspatronen na een bepaalde periode veranderen, is uw prijsmodel mogelijk niet meer geschikt. Prijsmodellen die het risico lopen onrendabel te worden, worden riskante prijsmodellen genoemd. Als u bijvoorbeeld een prijsmodel gebruikt dat verwacht dat gebruikers zelf de hoeveelheid die ze van uw oplossing gebruiken, zelf zullen beperken, hebt u mogelijk een riskant prijsmodel geïmplementeerd.

De meeste SaaS-oplossingen voegen regelmatig nieuwe functies toe. Dit verhoogt de ROV voor gebruikers, wat ook kan leiden tot een toename van de hoeveelheid die de oplossing wordt gebruikt. Dit kan leiden tot een oplossing die onprofiteerbaar wordt als het gebruik van nieuwe functies het gebruik aandrijft, maar het prijsmodel hier geen rekening mee houdt.

Als u bijvoorbeeld een nieuwe functie voor het uploaden van video's in uw oplossing introduceert, die gebruikmaakt van een resource op basis van verbruik en de gebruikersopname van de functie hoger is dan verwacht, kunt u een combinatie van gebruikslimieten en prijzen voor functies en serviceniveauoverwegen.

Gebruiksbeperkingen

Met gebruikslimieten kunt u het gebruik van uw service beperken om te voorkomen dat uw prijsmodellen onprofiteerbaar worden of om te voorkomen dat één tenant een onevenredige hoeveelheid capaciteit van uw service verbruikt. Dit kan met name belangrijk zijn in multitenant-services, waarbij één tenant invloed kan hebben op de ervaring van andere tenants door te veel resources te gebruiken.

Gebruikslimieten worden vaak gebruikt in combinatie met prijzen op functie- en serviceniveauom een hoger gebruik in hogere lagen te bieden. Limieten worden ook vaak gebruikt om kernonderdelen te beschermen die systeemknelpunten of prestatieproblemen veroorzaken als ze te veel worden gebruikt.

Frequentielimieten

Een veelgebruikte manier om een gebruikslimiet toe te passen, is door snelheidslimieten toe te voegen aan API's of aan specifieke toepassingsfuncties. Dit wordt ook wel beperking genoemd. Snelheidslimieten voorkomen continu overmatig gebruik. Ze worden vaak gebruikt om het aantal aanroepen naar een API te beperken gedurende een gedefinieerde periode. Zo kan een API bijvoorbeeld slechts 20 keer per minuut worden aangeroepen en wordt er een HTTP 429-fout weergegeven als deze vaker wordt aangeroepen.

In sommige gevallen, waarbij vaak een snelheidsbeperking wordt gebruikt, gaat het volgende:

• REST API's.
• Asynchrone taken.
• Taken die niet tijdgevoelig zijn.
• Acties die hoge kosten met zich mee moeten nemen om uit te voeren.
• Rapportgeneratie.

Het implementeren van snelheidsbeperking kan de complexiteit van de oplossing verhogen, maar services zoals Azure API Management kunnen dit eenvoudiger maken door beleidsregels voor snelheidslimieten toe te passen.

Levenscyclus van prijsmodel

Net als elk ander deel van uw oplossing hebben prijsmodellen een levenscyclus. Naarmate uw toepassing zich in de loop van de tijd verder ontwikkelt, moet u mogelijk uw prijsmodellen wijzigen. Dit kan worden aangestuurd door het wijzigen van de behoeften van klanten, commerciële vereisten of wijzigingen in de functionaliteit in uw toepassing. Enkele algemene wijzigingen in de levenscyclus van prijzen zijn onder andere:

• Een volledig nieuw prijsmodel toevoegen. U kunt bijvoorbeeld een prijsmodel voor verbruik toevoegen aan een oplossing die momenteel een model met een vast tarief biedt.
• Een bestaand prijsmodel wordt niet meer gebruikt.
• Een laag toevoegen aan een bestaand prijsmodel.
• Een laag in een bestaand prijsmodel wordt niet meer gebruikt.
• Het wijzigen van de gebruikslimieten voor een functie in een prijsmodel.
• Functies toevoegen aan of verwijderen uit een functie en prijsmodel op serviceniveau.
• Van een commercieel model voor business-to-consumer (B2C) naar een commercieel model (Business-to-Business) (B2B). Deze wijziging vereist vervolgens nieuwe prijsstructuren voor uw zakelijke klanten.

Het is meestal complex om veel verschillende prijsmodellen tegelijk te implementeren en te beheren. Het is ook verwarrend voor uw klanten. Het is dus beter om slechts één of twee modellen te implementeren, met een klein aantal lagen. Dit maakt uw oplossing toegankelijker en gemakkelijker te beheren.

Bij het wijzigen van prijsmodellen moet u rekening houden met de volgende factoren:

• Willen tenants migreren naar het nieuwe model?
• Kunnen tenants eenvoudig migreren naar het nieuwe model?
• Lopen nieuwe prijsmodellen risico op uw service? Verwijdert u bijvoorbeeld de snelheidslimieten die momenteel kritieke resources beschermen tegen overmatig gebruik?
• Hebben tenants een duidelijk pad voor migratie naar het nieuwe prijsmodel?
• Hoe voorkomt u dat tenants oudere prijsmodellen gebruiken, zodat u ze kunt stoppen?
• Zullen tenants waarschijnlijk een factuur krijgen (een negatieve reactie op een onverwachte factuur) bij het wijzigen van prijsmodellen?
• Controleert u de prestaties en het gebruik van uw services op nieuwe of gewijzigde prijsmodellen, zodat u kunt zorgen voor een voortdurende winstgevendheid?
• Kunt u de ROV voor nieuwe prijsmodellen duidelijk communiceren met uw bestaande tenants?

Volgende stappen

Denk na over hoe u het verbruik door tenants in uw oplossing gaat meten.