Dela via

Prismodeller för en lösning med flera klientorganisationer

  • Artikel

En bra prismodell säkerställer att du förblir lönsam 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 klienter är hur du utformar prismodeller för din produkt. I den här artikeln ger vi vägledning till tekniska beslutsfattare om vilka prismodeller du kan tänka på och vilka kompromisser som är inblandade.

Förstå lönsamhet

När du fastställer prismodellen för din produkt måste du balansera avkastningen på värdet (ROV) för dina kunder med kostnaden för sålda varor (COGS) för att leverera tjänsten. Att erbjuda mer flexibla kommersiella modeller kan öka ROV för kunder, men det kan också öka lösningens arkitektoniska och kommersiella komplexitet och därmed också öka din COGS.

När du utvecklar prismodeller för din lösning bör du tänka på följande frågor:

  • Kommer KSG:erna att vara högre än den vinst du tjänar på lösningen? En olönsam prismodellmetod kan fungera under en tid, men den är ohållbar på lång sikt.
  • Kan KSG:er ändras över tid, baserat på ökning av användare eller ändringar i användningsmönster? Modellera din KSG och tillväxt för att förstå om din COGS gör din lösning olönsam när du växer.
  • Hur svårt är det att mäta och registrera den information som krävs för att driva prismodellen? Om du till exempel planerar att fakturera dina kunder baserat på antalet API-anrop de gör är det viktigt att identifiera hur du mäter API-anropen som görs av varje kund.
  • Avråder din prismodell från att använda din produkt? Undvik situationer där din prismodell minskar det potentiella värde som en kund kan uppnå från produkten, till exempel genom att göra vanliga aktiviteter mycket kostsamma. Den här strukturen skapar felaktiga incitament och kan leda till blandade signaler till kunder.
  • Om en kund överanvänder lösningen, betyder det att du inte längre är lönsam? Om du är orolig för missbruk, sätt skyddsräcken på plats som hastighetsbegränsningar.

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

  • Prissättningsmodeller för Azure-tjänster. Prismodellerna för De Azure- eller tredjepartstjänster som utgör din lösning kan påverka vilka modeller som är lönsamma.

  • Användningsmönster för tjänsten. Användare kanske bara behöver komma åt din lösning under arbetstid eller kanske bara har en liten andel av högvolymsanvändare. Kan du minska din KSG genom att minska den outnyttjade kapaciteten när användningen är låg?

  • Lagringstillvä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 din lönsamhet per klientorganisation. Kan du ange lagringskvoter eller framtvinga en kvarhållningsperiod för data?

  • Klientisolering. Den innehavarmodell som du använder påverkar den isoleringsnivå som du har mellan dina klienter. Om du delar dina resurser måste du fundera över hur klientorganisationer kan överbegripa eller missbruka tjänsten? Hur påverkar nivån av klientisolering din KSG och prestanda för alla?

    Vissa prismodeller ä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 fast prismodell hållbar.

  • Klientorganisationens livscykel. Till exempel kan lösningar med höga kundomsättningsgrader eller tjänster som kräver större arbete vid ombordstigning 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 servicenivåer kan innebära att din lösning inte längre är lönsam. 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. Överväg att använda olika prisnivåer för kunder med olika servicenivåkrav.

Vanliga prismodeller

Det finns många vanliga prismodeller som ofta används med lösningar för flera klientorganisationer. Var och en av dessa prismodeller har tillhörande kommersiella fördelar och risker och kräver ytterligare arkitektoniska överväganden. Det är viktigt att förstå skillnaderna mellan dessa prismodeller, så att du kan se till att din lösning förblir lönsam allt eftersom den utvecklas.

Kommentar

Du kan erbjuda flera modeller för en lösning eller kombinera modeller tillsammans. Du kan till exempel ange en modell per användare för dina kunder som har ganska stabila användarnummer, och du kan även erbjuda en förbrukningsmodell för kunder som har varierande användningsmönster.

När du väljer en prismodell bör du tänka på vad som är vettigt ur kundernas perspektiv. Om din prismodell är för komplex eller abstrakt kan de ha svårt att uppskatta sina kostnader. Sikta på att koppla prissättningen till dina klientorganisationers affärskonstruktioner.

Förbrukningsbaserad prissättning

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

Diagram som visar intäktsökning i takt med att förbrukningsnivån ökar.

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 har många fördelar, men de kan vara svåra att implementera i en lösning med flera klientorganisationer.

Fördelar: Från dina kunders perspektiv finns det minimala förskottsinvesteringar som krävs för att använda din lösning, så att den här modellen har ett lågt inträdeshinder. Från ditt perspektiv som tjänstoperatör ökar dina värd- och hanteringskostnader i takt med att kundernas användning och dina intäkter ökar. Den här ökningen kan göra den till en mycket skalbar prismodell. Prismodeller för förbrukning fungerar särskilt bra när de Azure-tjänster som används i lösningen också är förbrukningsbaserade.

Komplexitet och driftskostnad: Förbrukningsmodeller förlitar sig på korrekta mått på användning och på att dela upp den här användningen efter klientorganisation. Detta kan vara en utmaning, särskilt i en lösning med många distribuerade komponenter. Du måste ha detaljerade förbrukningsposter för fakturering och granskning samt tillhandahålla metoder för att kunder ska få åtkomst till sina förbrukningsdata.

Risker: Förbrukningspriser 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örväg. Som tjänstleverantö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.

Kommentar

Implementering och stöd för kapacitetsreservationer kan öka komplexiteten i faktureringsprocesserna i ditt program. Du kan också behöva överväga hur kunder får återbetalningar eller byter kapacitetsreservationer, och dessa processer kan också lägga till kommersiella och operativa utmaningar.

Priser per användare

En prismodell per användare innebär att du debiterar dina kunder baserat på antalet personer som använder din tjänst:

Diagram som visar att intäkterna ökar i takt med att antalet användare ökar.

Prismodeller per användare är mycket vanliga eftersom de är enkla att implementera i en lösning med flera klientorganisationer. De är dock kopplade till flera kommersiella risker.

Fördelar: När du fakturerar dina kunder för varje användare är det enkelt att beräkna och prognostisera din intäktsström. Dessutom, förutsatt att du har ganska konsekventa användningsmönster för varje användare, ökar intäkterna i samma takt som tjänstimplementeringen, vilket gör den här modellen skalbar när du växer.

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 KSG:erna 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 driftskomplexitet.

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 inte den faktiska avkastningen på värdet (ROV) för lösningen av det faktiska antalet köpta användarlicenser. Om din lösning innehåller funktioner som inte är direkt relaterade till användare, till exempel att skicka e-postmeddelanden till ett stort antal mottagare, kanske dina intäkter inte ökar i takt med att din KSG ökar.

Priser per aktiv användare

Den här modellen liknar priser per användare, men i stället för att kräva ett förskottså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:

Diagram som visar att intäkterna ökar i takt med att antalet aktiva användare ökar och inte när antalet användare ökar.

Du kan mäta detta under vilken period som helst. Månadsperioder ä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 avfall. Oanvända licenser kan inte faktureras. Detta gör den särskilt attraktiv 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 DIN ROV mer exakt för kunden av antalet månatliga aktiva användare.

Komplexitet och driftskostnad: Per aktiv användarmodell 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 upprätthålls med KSG för en enskild användare, men återigen krävs ytterligare arbete för att mäta förbrukningen för varje användare.

Risker: Precis som priser per användare finns det en risk att de olika förbrukningsmönstren för enskilda användare kan påverka din lönsamhet. Jämfört med priser per användare har per aktiv användarmodell en mindre förutsägbar intäktsström. Dessutom ger rabattpriser inte ett användbart sätt att stimulera tillväxten.

Priser per enhet

I många system är antalet användare inte det element som har störst effekt på den övergripande KSV:en. I enhetsorienterade lösningar, som även kallas sakernas Internet eller IoT, har antalet enheter ofta störst inverkan på KSG. 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.

Diagram som visar intäktsökning när antalet enheter ökar.

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 säljs till fysiska återförsäljare kan till exempel en prismodell per butik vara lämplig oavsett hur många användare som finns i varje butik.

Fördelar: I system där enskilda användare inte har någon betydande effekt på KSG är prissättning per enhet ett bättre sätt att representera verkligheten för hur systemet skalar och den resulterande effekten på KSG. 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 lösningens tillväxt.

Komplexitet och driftskostnader: I allmänhet är prissättning per enhet lätt att implementera och har en ganska låg driftskostnad. Driftskostnaderna kan dock bli högre om du behöver särskilja och spåra användningen av enskilda enheter, till exempel enheter eller butiker. Genom att mäta förbrukningen per enhet kan du se till att lönsamheten bibehålls, eftersom du kan fastställa KSG för en enda enhet.

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

Prissättning på funktions- och servicenivå

Du kan välja att erbjuda din lösning med olika funktionsnivåer till olika prispunkter. Du kan till exempel tillhandahålla tre månatliga fasta priser eller priser per enhet, två som tillhandahåller grundläggande erbjudanden med en delmängd av tillgängliga funktioner och den tredje presenterar den omfattande uppsättningen av lösningens funktioner:

Diagram som visar att intäkterna ökar i steg mellan tre nivåer.

Den här modellen kan också erbjuda olika serviceavtal för olika nivåer. Din grundläggande nivå kan till exempel 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 högre tillgänglighetsmål.

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

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

Komplexitet och driftskostnader: Funktionsbaserade prismodeller 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å. Funktionsväxlingar 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 funktionsväxlingarna omkostnaderna för att säkerställa hög kvalitet, eftersom det kommer att finnas fler kodsökvägar att testa. Att aktivera mål för högre tjänsttillgänglighet 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 prismodeller kan bli komplicerade och förvirrande om det finns för många nivåer eller alternativ. Dessutom kan de omkostnader som ingår i dynamiskt växlande funktioner göra det långsammare 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å servicenivå. Sedan kan du erbjuda en separat betald nivå med ytterligare funktioner och ett formellt serviceavtal (som visas i följande diagram).

Diagram som visar intäkter som ökar från noll, på en kostnadsfri nivå, till ett högre belopp på en betald nivå.

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

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

Komplexitet och driftskostnader: Alla problem med komplexitet och driftskostnader gäller från den funktionsbaserade prismodellen. Du måste också ta hänsyn till driftskostnaderna för att hantera kostnadsfria klienter. Du kan behöva se till att inaktuella klienter är avregistrerade eller borttagna, och du måste ha en tydlig kvarhållningsprincip, särskilt för kostnadsfria klienter. När du flyttar en klientorganisation till en betald nivå kan du behöva migrera klientorganisationens data eller arbetsbelastning mellan Azure-tjänster för att få högre serviceavtal. Det är också viktigt att behålla klientorganisationens data och konfiguration när du flyttar till en betald nivå.

Risker: Du måste se till att du tillhandahåller en tillräckligt hög ROV för att klientorganisationer ska kunna ö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 täckas av vinstmarginalen från dem som är på betalda nivåer.

Pris för sålda varor

Du kan välja att prissätta din lösning så att varje klient endast betalar kostnaden för att driva sin del av de komponenter som utgör din lösning, utan någon extra vinstmarginal. Den här modellen – även kallad direktpris eller återbetalning – används ibland för lösningar med flera klienter som inte är avsedda att vara ett vinstcenter.

Diagram som visar intäkter som varierar över tid och hur mycket användning som ändras för att matcha.

Kostnaden för sålda varor är en bra passform för internt riktade lösningar för flera klientorganisationer. Varje organisationsenhet motsvarar en klientorganisation och kostnaderna för dina Azure-resurser måste fördelas mellan dem. Det kan också vara lämpligt när intäkter härleds från försäljning av andra produkter och tjänster som använder eller utökar lösningen för flera klientorganisationer.

Fördelar: Eftersom den här modellen inte innehåller någon extra vinstmarginal blir kostnaden för klientorganisationer lägre.

Komplexitet och driftskostnad: På samma sätt som förbrukningsmodellen förlitar sig kostnaden för sålda varor på korrekta användningsmätningar och på att dela den här användningen efter klientorganisation. Det kan vara svårt att spåra förbrukningen, särskilt i en lösning med många distribuerade komponenter. Du måste ha detaljerade förbrukningsposter för fakturering och granskning samt tillhandahålla metoder för att kunder ska få åtkomst till sina förbrukningsdata.

För internt riktade lösningar för flera klienter kan klienter acceptera ungefärliga kostnadsuppskattningar och ha mer avslappnade krav på faktureringsgranskning. Dessa avslappnade krav minskar komplexiteten och kostnaden för att använda din lösning.

Risker: Kostnaden för sålda varor kan motivera dina klienter att minska sin användning av systemet för att minska sina kostnader. Men eftersom den här modellen används för program som inte är vinstcenter kanske det inte är något problem.

Prissättning med fast pris

I den här modellen debiterar du en fast avgift 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 något annat mått.

Diagram som visar intäkter som förblir konsekventa, oavsett användningsmängd.

Det här är den enklaste modellen att implementera och för kunder att förstå, och den efterfrågas ofta av företagskunder. Det kan dock lätt bli olönsamt om du behöver fortsätta att lägga till nya funktioner eller om klientorganisationens förbrukning ökar utan ytterligare intäkter.

Fördelar: Fasta priser är lätta att sälja, och det är enkelt för dina kunder att förstå och budgetera för.

Komplexitet och driftskostnad: Fasta prismodeller kan vara enkla att implementera eftersom faktureringskunder inte kräver någon förbrukning för mätning eller spårning. Men även om det inte är nödvändigt är det lämpligt att mäta förbrukningen per klientorganisation för att säkerställa att du mäter KSG korrekt och för att säkerställa att din lönsamhet 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.

Rabatterade priser

När du har definierat din prismodell kan du välja att implementera kommersiella strategier för att stimulera tillväxt genom rabattpriser. Rabattpriser kan användas med prismodeller för förbrukning, per användare och per enhet.

Kommentar

Rabattpriser kräver vanligtvis inte arkitektoniska överväganden, förutom att lägga till stöd för en mer komplex faktureringsstruktur. En fullständig diskussion om de kommersiella fördelarna med rabatter ligger utanför den här artikelns omfång.

Vanliga prismönster för rabatter är:

  • Fasta priser. Du har samma kostnad för varje användare, enhet eller mängd förbrukning, 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.
  • Digressiv prissättning. När kunderna köper eller förbrukar fler enheter minskar du kostnaden per enhet. Detta är mer kommersiellt attraktivt för kunderna.
  • Stegprissättning. När kunderna köper mer minskar du kostnaden per enhet. Men du gör det i stegändringar, baserat på fördefinierade kvantitetsintervall. 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:a till 200:e användaren och sedan ett lägre pris igen efter det. Den här metoden kan vara mer lönsam än olika priser.

Följande diagram illustrerar dessa prismönster.

Diagram som visar de olika rabatter som kan tillämpas på en prismodell.

Miljörabatter som inte är produktionsbaserade

I många fall kräver kunderna åtkomst till en icke-produktionsmiljö som de kan använda för testning, träning eller för att skapa sin egen interna dokumentation. Icke-produktionsmiljöer har vanligtvis lägre förbrukningskrav och kostnader för drift. 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å Azure-tjänster som stöder icke-produktionsarbetsbelastningar.

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

  • Erbjud en freemium-nivå, 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, vilket förbrukar ytterligare resurser för att fungera.

    Kommentar

    Tidsbegränsade utvärderingsversioner med freemium-nivåer är vanligtvis inte lämpliga för test- och träningsmiljöer. Kunder behöver vanligtvis sina icke-produktionsmiljöer för att vara tillgängliga under produktionstjänstens livslängd.

  • Erbjud 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.
  • Erbjud rabatterade priser per användare, per aktiv användare eller per enhet för icke-produktionsklienter, med ett lägre eller inget serviceavtal.
  • För klienter som använder fasta priser kan icke-produktionsmiljöer förhandlas fram som en del av avtalet.

Kommentar

Funktionsbaserad prissättning är vanligtvis inte ett bra alternativ för miljöer som inte är produktionsmiljöer, såvida inte de funktioner som erbjuds är desamma som produktionsmiljön erbjuder. Detta beror på att klienter vanligtvis vill testa och tillhandahålla utbildning om alla samma funktioner som är tillgängliga för dem i produktion.

Olönsamma prismodeller

En olönsam prismodell kostar dig mer att leverera tjänsten än de intäkter du tjänar. Du kan till exempel debitera ett fast pris per klientorganisation utan några begränsningar för din tjänst, men sedan skapar du din tjänst med förbrukningsbaserade Azure-resurser och utan användningsgränser per klientorganisation. I den här situationen kan du riskera att dina klienter överanvänder tjänsten 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.
  • Att vara värd för en specifik klientorganisation ger ett annat kommersiellt värde, till exempel att använda dem som en ankarklient på en ny marknad.

Om du oavsiktligt skapar en olönsam prismodell finns det några sätt att minimera riskerna med dem, inklusive:

  • Begränsa användningen av tjänsten via användningsgränser.
  • Kräv användning av kapacitetsreservationer.
  • Begär att klientorganisationen flyttas till en högre funktions- eller tjänstnivå. Överväg att göra nya funktioner exklusivt tillgängliga på en lönsam tjänstnivå för att uppmuntra klienter att flytta.

Riskfyllda prismodeller

När du implementerar en prismodell för en lösning måste du vanligtvis göra antaganden om hur den ska användas. Om dessa antaganden visar sig vara felaktiga eller om användningsmönstren ändras över tid kan din prismodell bli olönsam. Prismodeller som riskerar att bli olönsamma kallas riskfyllda prismodeller . Om du till exempel använder en prismodell som förväntar dig att användarna själv begränsar hur mycket de använder din lösning kan du ha implementerat en riskfylld prismodell.

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

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, kan du överväga om du kan minska prisrisken med hjälp av en kombination av användningsgränser och prissättning på funktions- och servicenivå.

Användningsgränser

Med användningsgränser kan du begränsa användningen av tjänsten för att förhindra att dina prismodeller blir olönsamma eller för att förhindra att en enskild klientorganisation förbrukar en oproportionerlig mängd av tjänstens kapacitet. Detta kan vara särskilt viktigt i tjänster med flera klienter, där en enskild klientorganisation kan påverka andra klientorganisationers upplevelse genom överförbrukning av resurser.

Kommentar

Det är viktigt att göra dina kunder medvetna om att du tillämpar användningsgränser. Om du implementerar användningsgränser utan att göra dina kunder medvetna om gränsen kommer det att leda till kundernas missnöje. Det innebär att det är viktigt att identifiera och planera användningsgränser i förväg. Målet bör vara att planera för gränsen och sedan kommunicera gränserna till kunderna innan de blir nödvändiga.

Användningsgränser används ofta i kombination med priser på funktions- och servicenivå för att ge en högre mängd användning på högre nivåer. Gränser används också ofta för att skydda kärnkomponenter som orsakar systemflaskhalsar 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 hastighetsgränser för 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 returnerar ett HTTP 429-fel om det anropas oftare än så.

Följande scenarier omfattar ofta hastighetsbegränsningar:

  • REST-API:er.
  • Asynkrona uppgifter.
  • Uppgifter som inte är tidskänsliga.
  • Åtgärder som medför en hög kostnad att kö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 principer för hastighetsbegränsning.

Livscykel för prismodell

Precis som andra delar av din lösning har prismodeller en livscykel. När ditt program utvecklas över tid kan du behöva ändra dina prismodeller. Detta kan bero på ändrade kundbehov, kommersiella krav eller ändringar av funktioner i ditt program. Några vanliga ändringar i prissättningens livscykel omfattar följande:

  • Lägga till en helt ny prismodell. Du kan till exempel lägga till en prismodell för förbrukning i en lösning som för närvarande erbjuder en fast prismodell.
  • Dra tillbaka en befintlig prismodell.
  • Lägga till en nivå i en befintlig prismodell.
  • Dra tillbaka en nivå i en befintlig prismodell.
  • Ändra användningsgränser för en funktion i en prismodell.
  • Lägga till eller ta bort funktioner från en funktion och prismodell på servicenivå.
  • Byta från en kommersiell modell från 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 komplext att implementera och hantera många olika prismodeller 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.

Kommentar

Prismodeller och faktureringsfunktioner bör testas, helst med automatiserad testning, precis som alla andra delar av systemet. Ju mer komplexa prismodellerna är, desto mer testning krävs, så kostnaden för utveckling och driftskomplexitet kommer att öka.

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

  • Avtalsmässiga konsekvenser. Om klientorganisationer har signerade kontrakt baserat på en specifik prismodell kontrollerar du att du inte av misstag bryter mot dessa avtal.
  • Önskvärdheten. Kommunicera ROV för nya prismodeller tydligt till dina befintliga klienter. Se till att du gör den nya modellen tillräckligt attraktiv så att klientorganisationer vill migrera till den nya modellen. Bestäm hur du ska avskräcka klienter från att använda äldre prismodeller som du planerar att dra tillbaka.
  • Tidslinje. Ge klienterna gott om varsel om eventuella ändringar så att de kan förbereda sig.
  • Migreringsprocess. Gör det enkelt för klientorganisationer att migrera till den nya modellen.
  • Minska prisriskerna. Utvärdera varje ny prismodell för att förstå om den är riskfylld. Var till exempel försiktig när du tar bort hastighetsgränser som för närvarande skyddar kritiska resurser från överanvändning. Under hela ändringen övervakar du prestanda och användning av dina tjänster så att du kan säkerställa fortsatt tillfredsställelse och lönsamhet.
  • Minska risken för fakturachocker. Ändringar i prismodellen kan leda till fakturachock, vilket är en negativ reaktion på en oväntad faktura. Kommunicera prismodelländringar tydligt och proaktivt. Beräkna eller simulera varje klientorganisations faktura före och efter ändringen så att du kan identifiera situationer där en klientorganisation betalar betydligt mer efter ändringen.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

Övriga medarbetare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

Fundera på hur du ska mäta klientorganisationens förbrukning i din lösning.