Prijsmodellen voor een multitenant-oplossing

Een goed prijsmodel zorgt ervoor dat u winstgevend 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. Op deze pagina bieden we richtlijnen voor technische besluitvormers over de prijsmodellen die u kunt overwegen en de betrokken compromissen.

Wanneer u het prijsmodel voor uw product bepaalt, moet u het rendement op waarde (ROV) voor uw klanten afwegen 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 waarmee u rekening moet houden bij het ontwikkelen van prijsmodellen voor een oplossing, zijn als volgt:

• Is de COGS hoger dan de winst die u verdient van de oplossing?
• Kan de COGS in de loop van de tijd veranderen op basis van de groei van gebruikers of veranderingen in gebruikspatronen?
• Hoe moeilijk is het om de gegevens te meten en vast te leggen die nodig zijn 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 vastgesteld hoe u de API-aanroepen van elke klant meet?
• Is uw winstgevendheid afhankelijk van het garanderen dat klanten uw oplossing op een beperkte manier gebruiken?
• Als een klant de oplossing overleeft, betekent dit dan dat dat u niet meer winstgevend bent?

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

• Prijsmodellen voor Azure-services. De prijsmodellen van de Azure- of services van derden waaruit uw oplossing bestaat, kunnen van invloed zijn op welke modellen winstgevend zijn.
• Gebruikspatronen voor services. Gebruikers hoeven mogelijk alleen toegang te krijgen 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?
• Opslaggroei. De meeste oplossingen verzamelen gegevens in de loop van de tijd. Meer gegevens betekenen een hogere kosten om deze op te slaan en te beschermen, waardoor uw winstgevendheid per tenant wordt verminderd. Kunt u opslagquota instellen of een bewaarperiode voor gegevens afdwingen?
• Tenantisolatie. Het tenancymodel dat u gebruikt, is van invloed op het isolatieniveau tussen uw tenants. Als u uw resources deelt, moet u overwegen hoe tenants de service te veel kunnen gebruiken of misbruiken? Hoe is het niveau van tenantisolatie van invloed op uw COGS en prestaties voor iedereen? Sommige prijsmodellen zijn niet winstgevend zonder extra controles voor resourcetoewijzing. U moet bijvoorbeeld servicebeperking implementeren om een vast prijsmodel duurzaam te maken.
• Levenscyclus van tenants. Oplossingen met een hoog klantverloop of services waarvoor een grotere on-onboarding is vereist, kunnen bijvoorbeeld lagere winstgevendheid hebben, vooral als ze zijn geprijsd met een model op basis van verbruik.
• Vereisten voor serviceniveau. Tenants die hogere serviceniveaus vereisen, kunnen betekenen dat uw oplossing niet meer winstgevend 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 veel algemene prijsmodellen die vaak worden gebruikt met multitenant-oplossingen. Elk van deze prijsmodellen heeft commerciële voordelen en risico's met zich meegenomen en vereist aanvullende overwegingen voor de architectuur. Het is belangrijk om inzicht te hebben in de verschillen tussen deze prijsmodellen, zodat u ervoor kunt zorgen dat uw oplossing winstgevend blijft naarmate deze zich ontwikkelt.

Notitie

U kunt meerdere modellen voor een oplossing aanbieden of modellen combineren. U kunt bijvoorbeeld een model per gebruiker opgeven voor uw klanten met redelijk stabiele gebruikersnummers en u kunt ook een verbruiksmodel aanbieden voor klanten met fluctuerende gebruikspatronen.

Prijzen op basis van verbruik

Een verbruiksmodel wordt soms ook wel betalen per gebruik 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 veel voordelen, maar ze kunnen moeilijk te implementeren zijn in een multitenant-oplossing.

Voordelen: Vanuit het perspectief van uw klanten is er minimale investering vooraf vereist voor het gebruik van uw oplossing, zodat dit model een lage drempel heeft voor toegang. Vanuit uw perspectief als serviceoperator nemen uw hosting- en beheerkosten toe naarmate het gebruik van uw klanten toeneemt en uw omzet toeneemt. Deze toename kan een zeer schaalbaar prijsmodel maken. 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 het splitsen van dit gebruik per tenant. Dit kan lastig zijn, met name in een oplossing met veel gedistribueerde onderdelen. U moet gedetailleerde verbruiksrecords voor facturering en controle bewaren en klanten methoden bieden om toegang te krijgen tot hun verbruiksgegevens.

Risico's: De prijzen van verbruik kunnen uw klanten motiveren om hun gebruik van uw systeem te verminderen om hun kosten te verlagen. Daarnaast resulteren verbruiksmodellen in onvoorspelbare omzetstromen. U kunt dit beperken door capaciteitsreserveringen aan te bieden, waarbij klanten vooraf betalen voor een bepaald verbruiksniveau. U kunt als serviceprovider deze omzet gebruiken om te investeren in verbeteringen in de oplossing, om de operationele kosten te verlagen of om het rendement op waarde te verhogen door functies toe te voegen.

Notitie

Het implementeren en ondersteunen van capaciteitsreserveringen kan de complexiteit van de factureringsprocessen in uw toepassing verhogen. Mogelijk moet u ook overwegen hoe klanten restituties krijgen of hun capaciteitsreservering inwisselen, en deze processen kunnen ook commerciële en operationele uitdagingen opleveren.

Prijzen per gebruiker

Een prijsmodel per gebruiker omvat het opladen van uw klanten op basis van het aantal personen dat uw service gebruikt, zoals wordt weergegeven in het volgende diagram.

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

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

Complexiteit en operationele kosten: modellen per gebruiker zijn meestal eenvoudig te implementeren. In sommige situaties moet u echter het verbruik per gebruiker meten, wat u kan helpen ervoor te zorgen dat de COGS voor één gebruiker winstgevend blijft. Door het verbruik te meten en te koppelen aan een bepaalde gebruiker, kunt u de operationele complexiteit van uw oplossing verhogen.

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

Prijzen per actieve gebruiker

Dit model is vergelijkbaar met prijzen per gebruiker, maar in plaats van vooraf een toezegging van de klant op het aantal verwachte gebruikers te vereisen, wordt de klant alleen in rekening gebracht voor gebruikers die zich daadwerkelijk aanmelden en de oplossing gedurende een periode gebruiken (zoals in het volgende diagram wordt weergegeven).

U kunt dit meten in welke periode dan ook. Maandelijkse perioden zijn gebruikelijk en deze metrische gegevens worden vaak geregistreerd als maandelijks actieve gebruikers of MAU.

Voordelen: Vanuit het perspectief van uw klanten is voor dit model een lage investering en risico vereist, omdat er minimaal verspilling is; ongebruikte licenties kunnen niet worden gefactureerd. Dit maakt het bijzonder aantrekkelijk bij het marketingen van de oplossing of het vergroten van de oplossing voor grotere zakelijke klanten. Vanuit uw perspectief als service-eigenaar is uw ROV nauwkeuriger zichtbaar voor de klant door het aantal maandelijkse actieve gebruikers.

Complexiteit en operationele kosten: voor gebruikersmodellen per actieve gebruiker moet u het werkelijke gebruik vastleggen en deze beschikbaar maken voor een klant als onderdeel van de factuur. Het meten van verbruik per gebruiker helpt ervoor te zorgen dat de winstgevendheid wordt gehandhaafd met de COGS voor één gebruiker, maar nogmaals vereist extra werk om het verbruik voor elke gebruiker te meten.

Risico's: Net als prijzen per gebruiker is er een risico dat de verschillende verbruikspatronen van afzonderlijke gebruikers van invloed kunnen zijn op uw winstgevendheid. Vergeleken met prijzen per gebruiker hebben per actieve gebruikersmodellen een minder voorspelbare omzetstroom. Bovendien biedt 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 algemene COGS. In apparaatgerichte 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 wordt verkocht aan fysieke detailhandelaren, is een prijsmodel per winkel mogelijk geschikt.

Voordelen: In systemen waar individuele gebruikers geen significant effect hebben op COGS, is prijzen per eenheid een betere manier om de realiteit weer te geven van de schaal van het systeem en de resulterende impact op COGS. 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 hebben een redelijk lage operationele kosten. De operationele kosten kunnen echter hoger worden als u het gebruik van afzonderlijke eenheden, zoals apparaten of winkels, moet onderscheiden en bijhouden. Door het meten van verbruik per eenheid 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 prijzen per gebruiker. Verschillende verbruikspatronen in sommige eenheden kunnen betekenen dat u minder winstgevendheid hebt, bijvoorbeeld als sommige apparaten of winkels veel zwaardere gebruikers van de oplossing zijn dan andere.

Prijzen op basis van functies en services

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

Dit model kan ook verschillende serviceovereenkomsten bieden voor verschillende lagen. Uw basic-laag kan bijvoorbeeld 99,9% uptime 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 nuttig kan zijn, is het wel vereist dat de technische procedures goed presteren. Met zorgvuldige overwegingen 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 om uw klanten te upsellen met extra functies of een hogere tolerantie voor degenen die dit nodig hebben.

Complexiteit en operationele kosten: prijsmodellen op basis van functies kunnen complex zijn om te implementeren, omdat ze vereisen dat uw oplossing op de hoogte is van de functies die beschikbaar zijn voor elke prijscategorie. Functieknoppen kunnen een effectieve manier zijn om toegang te bieden tot bepaalde subsets van functionaliteit, maar dit vereist doorlopend onderhoud. Bovendien verhogen functieknoppen de overhead om een hoge kwaliteit te garanderen, omdat er meer codepaden worden getest. Het inschakelen van hogere servicebeschikbaarheidsdoelen in sommige lagen vereist mogelijk extra architectuurcomplexiteit, om ervoor te zorgen dat de juiste set infrastructuur voor elke laag wordt gebruikt. Dit proces kan de operationele kosten van de oplossing verhogen.

Risico's: prijsmodellen op basis van functies kunnen ingewikkeld en verwarrend worden als er te veel lagen of opties zijn. Bovendien kan de overhead die betrokken is bij het dynamisch in-/uitschakelen van functies, de snelheid vertragen waarmee u extra 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 tijdslimiet voor een proefversie en tijdens de proefversie hebben uw klanten mogelijk volledige of beperkte functionaliteit beschikbaar. Dit wordt een freemium-model genoemd, dat in feite een uitbreiding is van het prijsmodel op basis van functies.

Voordelen: Het is heel eenvoudig om een oplossing te marketen wanneer deze gratis is.

Complexiteit en operationele kosten: alle complexiteit 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 offboarded of verwijderd zijn en u moet een duidelijk bewaarbeleid hebben, met name voor gratis tenants. Bij het promoveren van een tenant naar een betaalde laag moet u de tenant mogelijk verplaatsen tussen Azure-services om hogere SLA's te verkrijgen. Het is ook belangrijk om de gegevens en configuratie van de tenant te behouden wanneer u overstapt op een betaalde laag.

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

Kosten van verkochte goederen

U kunt ervoor kiezen om uw oplossing te prijzen, zodat elke tenant alleen de kosten betaalt voor het uitvoeren van hun aandeel van de Azure-services, zonder extra winstmarge. Dit model, ook wel pass through-kosten of -prijzen genoemd, wordt soms gebruikt voor multitenant-oplossingen die niet bedoeld zijn om een winstcentrum te zijn.

De kosten van het verkochte model van goederen zijn geschikt voor intern gerichte multitenant oplossingen. Elke organisatie-eenheid komt overeen met een tenant en de kosten van uw Azure-resources moeten tussen deze resources worden verdeeld. Het kan ook geschikt zijn wanneer de omzet wordt afgeleid van de verkoop van andere producten en services die de multitenant-oplossing verbruiken of uitbreiden.

Voordelen: Omdat dit model geen extra marge voor winst bevat, zijn de kosten voor tenants lager.

Complexiteit en operationele kosten: vergelijkbaar met het verbruiksmodel, zijn de kosten van verkochte goederen afhankelijk van nauwkeurige metingen van het gebruik en het splitsen van dit gebruik per tenant. Het bijhouden van verbruik kan lastig zijn, met name in een oplossing met veel gedistribueerde onderdelen. U moet gedetailleerde verbruiksrecords voor facturering en controle bewaren en klanten methoden bieden om toegang te krijgen tot hun verbruiksgegevens.

Voor intern gerichte multitenant-oplossingen kunnen tenants schattingen van geschatte kosten accepteren en hebben ze meer soepele factureringscontrolevereisten. Deze ontspannen vereisten verminderen de complexiteit en kosten van het gebruik van uw oplossing.

Risico's: de kosten van verkochte goederen kunnen uw huurders motiveren om hun gebruik van uw systeem te verminderen, om hun kosten te verlagen. Omdat dit model echter wordt gebruikt voor toepassingen die geen winstcentra zijn, is dit mogelijk geen probleem.

Vaste prijzen

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

Dit is het eenvoudigste model dat klanten kunnen implementeren en begrijpen, en het wordt vaak aangevraagd door zakelijke klanten. Het kan echter eenvoudig onprofiteerbaar worden als u nieuwe functies wilt blijven toevoegen of als het tenantverbruik toeneemt zonder extra inkomsten.

Voordelen: prijsstelling tegen vaste tarieven is eenvoudig te verkopen en het is eenvoudig voor uw klanten om te begrijpen en budget te behalen.

Complexiteit en operationele kosten: prijsmodellen met een vast tarief kunnen eenvoudig worden geïmplementeerd omdat factureringsklanten geen verbruik voor meting of tracering vereisen. Hoewel dit niet essentieel is, is het echter raadzaam om het verbruik per tenant te meten om ervoor te zorgen dat u COGS nauwkeurig meet en om ervoor te zorgen dat uw winstgevendheid behouden blijft.

Risico's: Als u tenants hebt die intensief gebruikmaken van uw oplossing, is het eenvoudig voor dit prijsmodel om onfiteerbaar te worden.

Kortingsprijzen

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

Notitie

Voor kortingsprijzen zijn doorgaans geen architectuuroverwegingen vereist, behalve het toevoegen van ondersteuning voor een complexere factureringsstructuur. Een volledige bespreking van de commerciële voordelen van korting valt buiten het bereik van dit document.

Veelvoorkomende prijspatronen voor korting zijn onder andere:

• Vaste prijzen. U hebt dezelfde kosten voor elke gebruiker, eenheid of hoeveelheid verbruik, ongeacht hoeveel er wordt gekocht of verbruikt. Dit is de eenvoudigste aanpak. Klanten die intensief gebruikmaken van uw oplossing, kunnen er echter voor zorgen dat ze baat hebben bij 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.
• Stapprijzen. U verlaagt de kosten per eenheid, omdat klanten meer kopen. U doet dit echter in stapwijzigingen, op basis van vooraf gedefinieerde bereiken van hoeveelheid. 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 een lagere prijs. Dit kan winstgevender zijn.

In het volgende diagram ziet u deze prijspatronen.

Kortingen voor niet-productieomgeving

In veel gevallen hebben klanten toegang nodig tot een niet-productieomgeving die ze kunnen gebruiken voor testen, trainen of voor het maken van hun eigen interne documentatie. Niet-productieomgevingen hebben meestal lagere verbruiksvereisten en kosten om te werken. Niet-productieomgevingen zijn bijvoorbeeld vaak niet onderworpen aan serviceovereenkomsten (SLA's) en frequentielimieten kunnen worden ingesteld op lagere waarden. U kunt ook overwegen om agressievere automatische schaalaanpassing toe te passen op 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 levert:

• Bied een freemium-laag aan, zoals u mogelijk al doet voor betaalde klanten. Dit moet zorgvuldig worden bewaakt, omdat sommige organisaties mogelijk veel test- en trainingsomgevingen maken, waardoor extra resources worden gebruikt om te werken.

  Notitie

  Tijdgebonden proefversies met behulp van freemium-lagen zijn meestal 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 met een bestaande betaalde tenant.
• Bied een korting per gebruiker, per actieve gebruiker of prijs per eenheid voor niet-productietenants, met een lagere of geen service level agreement.
• Voor tenants die vaste prijzen gebruiken, kunnen niet-productieomgevingen worden onderhandeld als onderdeel van de overeenkomst.

Notitie

Prijzen op basis van functies zijn meestal geen goede optie voor niet-productieomgevingen, tenzij de aangeboden functies hetzelfde zijn als wat de productieomgeving biedt. Dit komt doordat tenants meestal willen testen en training willen geven over alle functies die beschikbaar zijn in productie.

Onaanbeschikbare prijsmodellen

Een onbetaalbaar 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 azure-resources op basis van verbruik en zonder gebruikslimieten per tenant. In deze situatie loopt u mogelijk het risico dat uw tenants uw service overbelasten en daardoor onprofiteerbaar zijn om ze te bedienen.

Over het algemeen wilt u onaanbeschikbare prijsmodellen vermijden. Er zijn echter situaties waarin u ervoor kunt kiezen om een onfiteerbaar prijsmodel aan te nemen, waaronder:

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

In het geval dat u per ongeluk een onprofiteerbaar prijsmodel maakt, zijn er enkele manieren om de risico's te beperken die eraan zijn gekoppeld, waaronder:

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

Riskante prijsmodellen

Wanneer u een prijsmodel voor een oplossing implementeert, moet u meestal veronderstellingen maken over hoe het wordt gebruikt. Als deze veronderstellingen onjuist blijken te zijn of de gebruikspatronen na verloop van tijd veranderen, kan uw prijsmodel onprofiteerbaar worden. Prijsmodellen die risico lopen om onprofiteerbaar te worden, worden riskante prijsmodellen genoemd. Als u bijvoorbeeld een prijsmodel gebruikt dat verwacht dat gebruikers zelf het bedrag beperken dat ze uw oplossing gebruiken, 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 onaanbedeelbaar wordt, als het gebruik van nieuwe functies het gebruik aanstuurt, maar het prijsmodel dit niet in rekening brengt.

Als u bijvoorbeeld een nieuwe functie voor het uploaden van video's introduceert in uw oplossing, 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 op serviceniveau overwegen.

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 van de capaciteit van uw service verbruikt. Dit kan met name belangrijk zijn in multitenant-services, waarbij één tenant de ervaring van andere tenants kan beïnvloeden door te veel resources te verbruiken.

Notitie

Het is belangrijk om uw klanten te laten weten dat u gebruikslimieten toepast. Als u gebruikslimieten implementeert zonder uw klanten bewust te maken van de limiet, leidt dit tot ontevredenheid van klanten. Dit betekent dat het belangrijk is om gebruikslimieten van tevoren te identificeren en te plannen. Het doel moet zijn om de limiet te plannen en vervolgens de limieten aan klanten te communiceren voordat ze nodig zijn.

Gebruikslimieten worden vaak gebruikt in combinatie met prijzen op functie- en serviceniveau om een hogere hoeveelheid gebruik op hogere lagen te bieden. Limieten worden ook vaak gebruikt om kernonderdelen te beveiligen die systeemknelpunten of prestatieproblemen veroorzaken, als ze te veel worden verbruikt.

Frequentielimieten

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

In sommige situaties, waarbij frequentiebeperking vaak wordt gebruikt, zijn onder andere het volgende:

• REST API's.
• Asynchrone taken.
• Taken die niet tijdgevoelig zijn.
• Acties waarvoor hoge kosten in rekening worden gebracht 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 beleid voor frequentielimieten 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 ontwikkelt, moet u mogelijk uw prijsmodellen wijzigen. Dit kan worden veroorzaakt door veranderende behoeften van klanten, commerciële vereisten of wijzigingen in functionaliteit binnen uw toepassing. Enkele veelvoorkomende 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 vast tariefmodel biedt.
• Een bestaand prijsmodel buiten gebruik stellen.
• Een laag toevoegen aan een bestaand prijsmodel.
• Een laag buiten gebruik stellen in een bestaand prijsmodel.
• Gebruikslimieten voor een functie in een prijsmodel wijzigen.
• Functies toevoegen aan of verwijderen uit een prijsmodel op serviceniveau.
• Overstappen van een commercieel B2C-model (business-to-consumer) naar een business-to-business-model (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. Hierdoor is uw oplossing toegankelijker en eenvoudiger te beheren.

Notitie

Prijsmodellen en factureringsfuncties moeten worden getest, in het ideale geval met behulp van geautomatiseerde tests, net als elk ander deel van uw systeem. Hoe complexer de prijsmodellen, hoe meer testen vereist zijn, en de kosten van ontwikkeling en nieuwe functies zullen toenemen.

Wanneer u prijsmodellen wijzigt, moet u rekening houden met de volgende factoren:

• Willen tenants migreren naar het nieuwe model?
• Is het eenvoudig voor tenants om te migreren naar het nieuwe model?
• Komen nieuwe prijsmodellen uw service bloot aan risico's? Verwijdert u bijvoorbeeld frequentielimieten die momenteel kritieke resources beschermen tegen overgebruik?
• Hebben tenants een duidelijk pad voor migratie naar het nieuwe prijsmodel?
• Hoe voorkomt u dat tenants oudere prijsmodellen gebruiken, zodat u ze buiten gebruik kunt stellen?
• Ontvangen tenants waarschijnlijk een factuurschok (een negatieve reactie op een onverwachte factuur) bij het wijzigen van prijsmodellen?
• Controleert u de prestaties en het gebruik van uw services, voor nieuwe of gewijzigde prijsmodellen, zodat u de winstgevendheid kunt blijven garanderen?
• Kunt u de ROV voor nieuwe prijsmodellen duidelijk communiceren met uw bestaande tenants?

Bijdragers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

• Daniel Scott-Raynsford | PartnerTechnologie Strategist

Andere Inzenders:

• Bohdan Cherchyk | Senior klanttechnicus, FastTrack voor Azure
• John Downs | Principal Customer Engineer, FastTrack voor Azure
• Chad Kittel | Principal Software Engineer
• Paulo Salvatori | Principal Customer Engineer, FastTrack voor Azure
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack voor Azure

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

Bedenk hoe u het verbruik meet door tenants in uw oplossing.