Prissättningsmodeller för en lösning för flera entenant

En bra prismodell säkerställer att du fortsätter att vara lönsamma när antalet klienter växer och när du lägger till nya funktioner. En viktig faktor när du utvecklar en kommersiell lösning för flera olika tjänster är hur du utformar prismodeller för din produkt. På den här sidan ger vi vägledning till tekniska beslutsfattare om de prissättningsmodeller som du kan överväga och de kompromisser som ingår.

När du fastställer prismodellen för din produkt måste du balansera returen på värdet (UGG) för dina kunder med kostnaden för sålda varor (KSV) för att kunna leverera tjänsten. Om du erbjuder mer flexibla kommersiella modeller (för en lösning) kan du öka kundernas LACK, men det kan också öka lösningens arkitektur och kommersiella komplexitet (och därmed även öka din KSV).

Några viktiga överväganden som du bör tänka på när du utvecklar prissättningsmodeller för en lösning är följande:

• Kommer cogs vara högre än den vinst du tjänar på lösningen?
• Kan cogs ändras med tiden, baserat på ökning av användare eller ändringar i användningsmönster?
• Hur svårt är det att mäta och registrera den information som krävs för att använda prismodellen? Om du till exempel planerar att fakturera dina kunder baserat på antalet API-anrop, har du identifierat hur du mäter API-anropen som görs av varje kund?
• Är din lönsamhet beroende av att se till att kunderna använder din lösning på ett begränsat sätt?
• Om en kund överanvänder lösningen, betyder det då att du inte längre är lönsamma?

Det finns några viktiga faktorer som påverkar lönsamheten:

• Prismodeller för Azure-tjänster. Prissättningsmodellerna för De Azure- eller tredjepartstjänster som utgör din lösning kan påverka vilka modeller som kommer att vara lönsamma.
• Användningsmönster för tjänsten. Användarna kanske bara behöver komma åt din lösning under arbetstid eller kanske bara har en liten procentandel högvolymanvändare. Kan du minska KSV genom att minska den outnyttjade kapaciteten när användningen är låg?
• Storage tillväxt. De flesta lösningar ackumulerar data över tid. Mer data innebär en högre kostnad för att lagra och skydda dem, vilket minskar lönsamheten per klientorganisation. Kan du ange lagringskvoter eller framtvinga en datalagringsperiod?
• Klientisolering. Innehavarmodellen som du använder påverkar den isoleringsnivå som du har mellan dina klienter. Om du delar dina resurser, behöver du fundera på hur klienter kan överanvändning eller missbruk av tjänsten? Hur påverkar detta dina cogs och prestanda för alla? Vissa prissättningsmodeller är inte lönsamma utan ytterligare kontroller kring resursallokering. Du kan till exempel behöva implementera tjänstbegränsning för att göra en prismodell med fast pris hållbar.
• Klientlivscykel. Lösningar med höga kundomsättningsfrekvenser eller tjänster som kräver större arbete vid inpassning kan till exempel drabbas av lägre lönsamhet, särskilt om de prissätts med hjälp av en förbrukningsbaserad modell.
• Servicenivåkrav. Klienter som kräver högre tjänstnivåer kan innebära att din lösning inte längre är lönsamma. Det är viktigt att du är tydlig med dina kunders förväntningar på servicenivå och eventuella skyldigheter som du har, så att du kan planera dina prismodeller i enlighet med detta.

Vanliga prissättningsmodeller

Det finns ett antal vanliga prismodeller som ofta används med lösningar för flera olika tjänster. Var och en av dessa prissättningsmodeller har associerade kommersiella fördelar och risker och kräver ytterligare arkitekturöverväganden. Det är viktigt att förstå skillnaderna mellan dessa prissättningsmodeller, så att du kan se till att din lösning förblir lönsamma när den utvecklas.

Förbrukningsbaserad prissättning

En förbrukningsmodell kallas ibland betala per användningeller PAYG. När användningen av din tjänst ökar ökar dina intäkter:

När du mäter förbrukning kan du överväga enkla faktorer, till exempel mängden data som läggs till i lösningen. Du kan också överväga en kombination av användningsattribut tillsammans. Förbrukningsmodeller erbjuder ett antal fördelar, men de kan vara svåra att implementera i en lösning för flera olika kunder.

Fördelar: Från dina kunders perspektiv krävs minimal startinvestering för att använda din lösning, så att den här modellen har ett lågt ingångsbarriärer. Från ditt perspektiv som tjänstoperatör ökar dina värd- och hanteringskostnader när kundernas användning och dina intäkter ökar. Den här ökningen kan göra det till en mycket skalbar prismodell. Förbrukningsprismodeller fungerar särskilt bra när även de Azure-tjänster som används i lösningen är förbrukningsbaserade.

Komplexitet och driftskostnader: Förbrukningsmodeller förlitar sig på korrekta mätningar av användning och på att dela upp användningen efter klientorganisation. Detta kan vara svårt, särskilt i en lösning med många distribuerade komponenter. Du måste ha detaljerade förbrukningsposter för fakturering och granskning.

Risker: Prissättningen för förbrukning kan motivera dina kunder att minska sin användning av systemet för att minska sina kostnader. Dessutom resulterar förbrukningsmodeller i oförutsägbara intäktsströmmar. Du kan minska detta genom att erbjuda kapacitetsreservationer,där kunderna betalar för en viss förbrukningsnivå i förskott. Som tjänsteleverantör kan du använda dessa intäkter för att investera i förbättringar i lösningen, minska driftskostnaderna eller öka avkastningen på värdet genom att lägga till funktioner.

Prissättning per användare

En prismodell per användare innebär att debitera dina kunder baserat på antalet personer som använder din tjänst, vilket visas i följande diagram.

Prissättningsmodeller per användare är mycket vanliga eftersom de är enkla att implementera i en lösning för flera användare. De är dock associerade med flera kommersiella risker.

Fördelar: När du fakturerar dina kunder för varje användare är det enkelt att beräkna och göra prognoser för intäktsströmmen. Om du antar att du har ganska konsekventa användningsmönster för varje användare ökar dessutom intäkterna med samma hastighet som tjänsteintagandet, vilket gör detta till en skalbar modell.

Komplexitet och driftskostnader: Modeller per användare brukar vara enkla att implementera. I vissa situationer måste du dock mäta förbrukningen per användare, vilket kan hjälpa dig att se till att cogs för en enskild användare förblir lönsamma. Genom att mäta förbrukningen och associera den med en viss användare kan du öka lösningens operativa komplexitet.

Risker: Olika användarförbrukningsmönster kan leda till minskad lönsamhet. Till exempel kan tunga användare av lösningen kosta mer att betjäna än lätta användare. Dessutom återspeglas den faktiska returen på värdet (ANTAL) för lösningen inte av det faktiska antalet användarlicenser som köpts.

Prissättning per aktiv användare

Den här modellen liknar prissättning peranvändare, men i stället för att kräva ett förskottsbetalningsåtagande från kunden för antalet förväntade användare debiteras kunden endast för användare som faktiskt loggar in på och använder lösningen under en period (som visas i följande diagram).

Du kan mäta detta inom vilken period som helst. Månatliga perioder är vanliga och sedan registreras det här måttet ofta som månatliga aktiva användare eller MAU.

Fördelar: Från dina kunders perspektiv kräver den här modellen en låg investering och risk, eftersom det finns minimalt med spill. oanvända licenser är inte fakturerbara. Detta gör det särskilt attraktivt när du marknadsför lösningen eller växer lösningen för större företagskunder. Från ditt perspektiv som tjänstägare återspeglas ditt ANTAL på ett mer korrekt sätt för kunden av antalet månatliga aktiva användare.

Komplexitet och driftskostnader: Användarmodeller per aktiv kräver att du registrerar faktisk användning och gör den tillgänglig för en kund som en del av fakturan. Mätning av förbrukning per användare bidrar till att säkerställa att lönsamheten bibehålls med cogs för en enskild användare, men det krävs återigen ytterligare arbete för att mäta förbrukningen för varje användare.

Risker: Precis som per användare finns det en risk att de olika förbrukningsmönstren för enskilda användare kan påverka lönsamheten. Jämfört med prissättning per användare har användarmodeller per aktiv en mindre förutsägbar intäktsström. Dessutom är rabattpris inte ett användbart sätt att främja tillväxt.

Priser per enhet

I många system är antalet användare inte det element som har störst inverkan på den övergripande cogs-gsen. I enhetsorienterade lösningar, som även kallas sakernas Internet eller IoT,har till exempel antalet enheter ofta störst inverkan på COGS. I dessa system kan en prismodell per enhet användas, där du definierar vad en enhet är, till exempel en enhet. Se följande diagram.

Dessutom har vissa lösningar mycket varierande användningsmönster, där ett litet antal användare har en oproportionerlig inverkan på cogs. I en lösning som till exempel säljs till fysiska återförsäljare kan en prismodell per butik vara lämplig.

Fördelar: I system där enskilda användare inte har någon betydande inverkan på cogs är prissättning per enhet ett bättre sätt att representera verkligheten för hur systemet skalar och den resulterande påverkan på COGS. Det kan också förbättra anpassningen till de faktiska användningsmönstren för en kund. För många IoT-lösningar, där varje enhet genererar en förutsägbar och konstant mängd förbrukning, kan detta vara en effektiv modell för att skala din lösnings tillväxt.

Komplexitet och driftskostnader: Prissättning per enhet är i allmänhet enkelt att implementera och har en ganska låg driftskostnader. Driftskostnaderna kan dock bli högre om du behöver särskilja och spåra användning efter enskilda enheter, till exempel enheter eller butiker. Genom att mäta förbrukning per enhet kan du säkerställa att lönsamheten upprätthålls, eftersom du kan fastställa COGS för en enda enhet.

Risker: Riskerna med en prismodell per enhet liknar prissättningen per användare. Olika förbrukningsmönster för vissa enheter kan innebära att du har minskat lönsamheten, till exempel om vissa enheter eller butiker är mycket tyngre användare av lösningen än andra.

Prissättning baserad på funktion och tjänstnivå

Du kan välja att erbjuda din lösning med olika funktionsnivåer till olika prisnivåer. Du kan till exempel ange två månatliga fasta priser eller priser per enhet, där det ena är ett grundläggande erbjudande med en delmängd av tillgängliga funktioner och en som visar den omfattande uppsättningen funktioner i din lösning. Se följande diagram.

Den här modellen kan också erbjuda olika serviceavtal för olika nivåer. Till exempel kan din basic-nivå erbjuda 99,9 % drifttid, medan en premiumnivå kan erbjuda 99,99 %. Det högre serviceavtalet (SLA) kan implementeras med hjälp av tjänster och funktioner som möjliggör mål för högre tillgänglighet.

Även om den här modellen kan vara kommersiellt fördelaktig kräver den mogna tekniska metoder för att göra bra. Med försiktighet kan den här modellen vara mycket effektiv.

Fördelar: Funktionsbaserad prissättning är ofta attraktivt för kunder, eftersom de kan välja en nivå baserat på den funktionsuppsättning eller tjänstnivå som de behöver. Det ger dig också en tydlig väg för att sälja nya funktioner till dina kunder med nya funktioner eller högre återhämtning för dem som behöver det.

Komplexitet och driftskostnader: Funktionsbaserade prissättningsmodeller kan vara komplexa att implementera, eftersom de kräver att din lösning är medveten om de funktioner som är tillgängliga på varje prisnivå. Funktionsreglage kan vara ett effektivt sätt att ge åtkomst till vissa delmängder av funktioner, men detta kräver löpande underhåll. Dessutom ökar växlingsreglage omkostnaderna för att säkerställa hög kvalitet, eftersom det kommer att finnas fler kodsökvägar att testa. Att aktivera högre tjänsttillgänglighetsmål på vissa nivåer kan kräva ytterligare arkitekturkomplexitet för att säkerställa att rätt uppsättning infrastruktur används för varje nivå, och den här processen kan öka driftkostnaden för lösningen.

Risker: Funktionsbaserade prissättningsmodeller kan bli komplicerade och förvirrande om det finns för många nivåer eller alternativ. Dessutom kan kostnaderna för att dynamiskt växla funktioner göra att du kan sänka hastigheten för att leverera ytterligare funktioner.

Prissättning för Freemium

Du kan välja att erbjuda en kostnadsfri nivå av din tjänst, med grundläggande funktioner och inga garantier på tjänstnivå. Du kan sedan erbjuda en separat betalnivå med ytterligare funktioner och ett formellt serviceavtal (som du ser i följande diagram).

Den kostnadsfria nivån kan också erbjudas som en tidsbegränsad utvärderingsversion, och under utvärderingsperioden kan dina kunder ha fullständiga eller begränsade funktioner tillgängliga. Detta kallas för en freemium-modell, vilket i praktiken är en utökning av den funktionsbaserade prismodellen.

Fördelar: Det är mycket enkelt att marknadsföra en lösning när den är kostnadsfri.

Komplexitet och driftskostnader: Alla problem med komplexitet och driftskostnader gäller från den funktionsbaserade prismodellen. Du måste dock också ta hänsyn till driftskostnaderna som ingår i hanteringen av kostnadsfria klienter. Du kan behöva se till att inaktuella klienter avboarderas eller tas bort, och du måste ha en tydlig bevarandeprincip, särskilt för kostnadsfria klienter. När du befordrar en klient till en betald nivå kan du behöva flytta klientorganisationen mellan Azure-tjänster för att få högre serviceavtal.

Risker: Du måste se till att du tillhandahåller en tillräckligt hög SKIKT för klienter för att överväga att byta till en betald nivå. Dessutom måste kostnaden för att tillhandahålla din lösning till kunder på den kostnadsfria nivån omfattas av vinstmarginalen från dem som är på betalnivåer.

Priser för fast pris

I den här modellen debiterar du ett fast pris till en klientorganisation för åtkomst till din lösning under en viss tidsperiod. Samma priser gäller oavsett hur mycket de använder tjänsten, antalet användare, antalet enheter som de ansluter eller andra mått. Se följande diagram.

Det här är den enklaste modellen att implementera och för kunder att förstå, och det begärs ofta av företagskunder. Det kan dock enkelt bli olönsamt om du behöver fortsätta att lägga till nya funktioner eller om klientanvändningen ökar utan ytterligare intäkter.

Fördelar: Fast prissättning är lätt att sälja och det är enkelt för dina kunder att förstå och budgetera för.

Komplexitet och driftskostnader: Prismodeller med fast pris kan vara enkla att implementera eftersom faktureringskunder inte behöver någon mätning eller spårning av förbrukning. Även om det inte är nödvändigt är det dock lämpligt att mäta förbrukningen per klientorganisation för att säkerställa att du mäter COGS korrekt och ser till att lönsamheten bibehålls.

Risker: Om du har klienter som använder din lösning mycket är det enkelt för den här prismodellen att bli olönsam.

Prissättning för rabatter

När du har definierat din prismodell kan du välja att implementera kommersiella strategier för att ge incitament till tillväxt genom rabatterade priser. Rabatter kan användas med förbruknings-, per-användare- och per enhet-prismodeller.

Här är några vanliga prismönster för rabatter:

• Fast prissättning. Du har samma kostnad för varje användare, enhet eller förbrukningsbelopp, oavsett hur mycket som köps eller förbrukas. Det här är den enklaste metoden. Kunder som använder din lösning mycket kan dock känna att de bör dra nytta av stordriftsfördelar genom att få rabatt.
• Prissättning för digressiv. När kunderna köper eller förbrukar fler enheter minskar du kostnaden per enhet. Detta är mer kommersiellt attraktivt för kunder.
• Stegpriser. Du minskar kostnaden per enhet när kunderna köper mer. Men du gör det i stegändringar baserat på fördefinierade intervall av kvantitet. Du kan till exempel debitera ett högre pris för de första 100 användarna, sedan ett lägre pris för den 101:e till den 200:e användaren och sedan ett lägre pris igen efter det. Detta kan vara mer lönsamt.

Följande diagram illustrerar dessa prismönster.

Rabatter för icke-produktionsmiljöer

I många fall behöver kunder åtkomst till en icke-produktionsmiljö som de kan använda för testning, utbildning eller för att skapa sin egen interna dokumentation. Icke-produktionsmiljöer har vanligtvis lägre förbrukningskrav och kostnader att använda. Till exempel omfattas icke-produktionsmiljöer ofta inte av serviceavtal (SLA) och hastighetsbegränsningar kan anges till lägre värden. Du kan också överväga mer aggressiv autoskalning på dina Azure-tjänster.

På samma sätt förväntar sig kunderna ofta att icke-produktionsmiljöer är betydligt billigare än produktionsmiljöerna. Det finns flera alternativ som kan vara lämpliga när du tillhandahåller icke-produktionsmiljöer:

• Erbjuda en freemium-nivå,precis som du kanske redan gör för betalda kunder. Detta bör övervakas noggrant, eftersom vissa organisationer kan skapa många test- och träningsmiljöer som förbrukar ytterligare resurser för att fungera.

  Anteckning

  Tidsbegränsade utvärderingsversioner med freemium-nivåer lämpar sig vanligtvis inte för testnings- och träningsmiljöer. Kunder behöver vanligtvis ha sina icke-produktionsmiljöer tillgängliga under hela produktionstjänstens livslängd.

• Erbjuda en test- eller träningsnivå för din tjänst, med lägre användningsgränser. Du kan välja att begränsa tillgängligheten för den här nivån till kunder som har en befintlig betald klientorganisation.
• Erbjuda rabatterade priser per användare,peraktiv användare eller per enhet för icke-produktionsklienter, med ett lägre eller inget serviceavtal.
• För klienter som använder fast prissättning kanicke-produktionsmiljöer förhandlas som en del av avtalet.

Olönsamma prissättningsmodeller

En olönsam prismodell kostar dig mer för att leverera tjänsten än de intäkter du får. Du kan till exempel debitera ett fast pris per klientorganisation utan begränsningar för din tjänst, men sedan skapar du tjänsten med förbrukningsbaserade Azure-resurser och utan användningsgränser per klientorganisation. I den här situationen kan du vara i riskzonen för att dina klienter överanvänder din tjänst och därmed göra det olönsamt att betjäna dem.

I allmänhet vill du undvika olönsamma prismodeller. Det finns dock situationer där du kan välja att införa en olönsam prismodell, inklusive:

• En kostnadsfri tjänst erbjuds för att möjliggöra tillväxt.
• Ytterligare intäktsströmmar tillhandahålls av tjänster eller tilläggsfunktioner.
• Värdtjänster för en specifik klientorganisation ger ett annat kommersiellt värde, till exempel att använda dem som en fästpunktsklient på en ny marknad.

Om du oavsiktligt skapar en olönsam prismodell finns det några sätt att minska de risker som är associerade med dem, inklusive:

• Begränsa användningen av tjänsten via användningsbegränsningar.
• Kräv användning av kapacitetsreservationer.
• Begär att klientorganisationen flyttar till en högre funktion eller tjänstnivå.

Riskfyllda prissättningsmodeller

När du implementerar en prismodell för en lösning måste du vanligtvis göra antaganden om hur den kommer att användas. Om dessa antaganden visa sig vara felaktiga eller användningsmönstren ändras med tiden, kan din prismodell bli olönsam. Prissättningsmodeller som riskerar att bli olönsamma kallas riskfyllda prismodeller. Om du till exempel använder en prismodell som förväntar sig att användarna själv begränsar hur mycket de använder din lösning kan du ha implementerat en riskabel prismodell.

De flesta SaaS-lösningar lägger till nya funktioner regelbundet. Detta ökar ANTALET till användare, vilket också kan leda till att mängden som lösningen används ökar. Detta kan resultera i en lösning som blir olönsam om användningen av nya funktioner driver användningen, men prismodellen inte tar med detta i faktorer.

Om du till exempel introducerar en ny videouppladdningsfunktion i din lösning, som använder en förbrukningsbaserad resurs och användaranvändningen av funktionen är högre än förväntat, bör du överväga en kombination av användningsgränser och prissättning för funktioner och servicenivå.

Användningsgränser

Med användningsbegränsningar kan du begränsa användningen av din tjänst för att förhindra att dina prissättningsmodeller blir olönsamma, eller för att förhindra att en enskild klientorganisation förbrukar en oproportionerlig mängd kapacitet för din tjänst. Detta kan vara särskilt viktigt i tjänster för flera innehavare, där en enda klientorganisation kan påverka upplevelsen av andra klienter genom att överanvändningen av resurser.

Användningsbegränsningar används ofta i kombination med prissättning på funktion ochtjänstnivå för att ge en högre användningsnivå. Gränser används också ofta för att skydda kärnkomponenter som orsakar flaskhalsar i systemet eller prestandaproblem, om de är överförbrukning.

Hastighetsbegränsningar

Ett vanligt sätt att tillämpa en användningsgräns är att lägga till hastighetsbegränsningar till API:er eller till specifika programfunktioner. Detta kallas även för begränsning. Hastighetsbegränsningar förhindrar kontinuerlig överanvändning. De används ofta för att begränsa antalet anrop till ett API under en definierad tidsperiod. Ett API kan till exempel bara anropas 20 gånger per minut, och det returnerar ett HTTP 429-fel om det anropas oftare än så.

Vissa situationer där frekvensbegränsning ofta används är följande:

• REST-API:er.
• Asynkrona uppgifter.
• Uppgifter som inte är tidskänsliga.
• Åtgärder som medför en hög kostnad att utföra.
• Rapportgenerering.

Implementering av hastighetsbegränsning kan öka lösningens komplexitet, men tjänster som Azure API Management kan göra detta enklare genom att tillämpa hastighetsbegränsningsprinciper.

Livscykel för prismodell

Precis som andra delar av din lösning har prissättningsmodeller en livscykel. Allt eftersom ditt program utvecklas med tiden kan du behöva ändra dina prismodeller. Detta kan drivas av ändrade kundbehov, kommersiella krav eller ändringar av funktioner i ditt program. Några vanliga ändringar i prissättningslivscykeln är följande:

• Lägga till en helt ny prismodell. Du kan till exempel lägga till en förbrukningsprismodell i en lösning som för närvarande erbjuder en fast prismodell.
• Ta bort en befintlig prismodell.
• Lägga till en nivå i en befintlig prismodell.
• Ta bort en nivå i en befintlig prismodell.
• Ändra användningsbegränsningar för en funktion i en prismodell.
• Lägga till eller ta bort funktioner från en funktion och en prismodell på tjänstnivå.
• Byta från en kommersiell modell för företag till konsument (B2C) till en kommersiell modell för företag till företag (B2B). Den här ändringen kräver sedan nya prisstrukturer för dina företagskunder.

Det är vanligtvis komplicerat att implementera och hantera många olika prissättningsmodeller samtidigt. Det är också förvirrande för dina kunder. Därför är det bättre att bara implementera en eller två modeller med ett litet antal nivåer. Detta gör din lösning mer tillgänglig och enklare att hantera.

När du ändrar prismodeller måste du tänka på följande faktorer:

• Vill klienterna migrera till den nya modellen?
• Är det enkelt för klienter att migrera till den nya modellen?
• Kommer nya prismodeller att exponera din tjänst för risk? Tar du till exempel bort hastighetsbegränsningar som för närvarande skyddar viktiga resurser från överanvändning?
• Har klienter en tydlig väg för att migrera till den nya prismodellen?
• Hur förhindrar du att klienter använder äldre prismodeller, så att du kan dra tillbaka dem?
• Är det troligt att klienterna får fakturasnockar (en negativ reaktion på en oväntad faktura) när de ändrar prismodeller?
• Övervakar du prestanda och användning av dina tjänster för nya eller ändrade prismodeller, så att du kan säkerställa fortsatt lönsamhet?
• Kan du tydligt kommunicera MÄRKNING för nya prismodeller till dina befintliga klienter?

Nästa steg

Fundera över hur du mäter förbrukning efter klientorganisation i din lösning.