Prismodeller för en lösning med flera klientorganisationer

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. På den här sidan ger vi vägledning till tekniska beslutsfattare om vilka prismodeller du kan tänka på och vilka kompromisser som är inblandade.

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 (för en lösning) kan öka ROV för kunder, men det kan också öka lösningens arkitektoniska och kommersiella komplexitet (och därmed även öka din COGS).

Några viktiga överväganden som du bör ta hänsyn till när du utvecklar prismodeller för en lösning är följande:

• Kommer KSG:erna att vara högre än den vinst du tjänar på lösningen?
• Kan KSG:er ändras över tid, 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 driva prismodellen? Om du till exempel planerar att fakturera dina kunder baserat på antalet API-anrop som de gör, har du identifierat hur du mäter API-anropen som görs av varje kund?
• Är din lönsamhet beroende av att kunderna använder din lösning på ett begränsat sätt?
• Om en kund överanvänder lösningen, betyder det att du inte längre är lönsam?

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ättningsfrekvenser eller tjänster som kräver en större on-boarding-insats 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.

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.

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:

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.

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, vilket visas i följande diagram.

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 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 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.

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 (som visas i följande diagram).

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.

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 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 två månatliga fasta priser eller priser per enhet, en som är ett grundläggande erbjudande med en delmängd av tillgängliga funktioner och den andra presenterar den omfattande uppsättningen av lösningens funktioner. Se följande diagram.

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).

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. Men 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 befordrar en klientorganisation till en betald nivå kan du behöva flytta klientorganisationen 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 andel av Azure-tjänsterna, utan någon extra vinstmarginal. Den här modellen – även kallad pass through cost or pricing – används ibland för lösningar med flera klientorganisationer som inte är avsedda att vara ett vinstcenter.

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. Se följande diagram.

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.

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. Du minskar kostnaden per enhet i takt med att kunderna köper mer. 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. Detta kan vara mer lönsamt.

Följande diagram illustrerar dessa prismönster.

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å dina Azure-tjänster.

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.

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å.

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, bör du överväga en kombination av användningsgränser och priser 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.

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å.

Vissa situationer, där hastighetsbegränsning ofta används, omfattar följande:

• 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 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 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.

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

• Vill klientorganisationer migrera till den nya modellen?
• Är det enkelt för klienter att migrera till den nya modellen?
• Kommer nya prismodeller att utsätta din tjänst för risker? Tar du till exempel bort hastighetsgränser som för närvarande skyddar kritiska 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?
• Kommer klienter sannolikt att få fakturachock (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 ROV för nya prismodeller till dina befintliga klienter?

Deltagare

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

Huvudförfattare:

• Daniel Scott-Raynsford | Partnerteknikstrateg

Övriga medarbetare:

• Bohdan Cherchyk | Senior kundtekniker, FastTrack för Azure
• John Downs | Huvudprogramtekniker
• Chad Kittel | Huvudprogramtekniker
• Paolo Salvatori | Huvudkundtekniker, FastTrack för Azure
• Arsen Vladimirskiy | Huvudkundtekniker, FastTrack för Azure

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.