Több-bérlős megoldások díjszabási modelljei

A jó díjszabási modell biztosítja, hogy a bérlők számának növekedésével és új funkciók hozzáadásával nyereséges maradjon. A kereskedelmi több-bérlős megoldások fejlesztésekor fontos szempont, hogy hogyan tervezzen díjszabási modelleket a termékhez. Ezen az oldalon útmutatást nyújtunk a műszaki döntéshozóknak az ön által megfontolható díjszabási modellekről és az érintett kompromisszumokről.

Amikor meghatározza a termék díjszabási modelljét, ki kell egyensúlyoznia az ügyfelek számára az értékvisszatérést (ROV) a szolgáltatás nyújtásához eladott áruk költségével (COGS). A rugalmasabb kereskedelmi modellek (megoldáshoz) használata növelheti a ROV-t az ügyfelek számára, de növelheti a megoldás architekturális és kereskedelmi összetettségét is (és ezáltal növelheti a COGS-t is).

Néhány fontos szempont, amelyet figyelembe kell vennie egy megoldás díjszabási modelljeinek fejlesztésekor, a következők:

• A COGS magasabb lesz, mint a megoldásból származó nyereség?
• Változhat-e a COGS az idő múlásával a felhasználók növekedése vagy a használati minták változása alapján?
• Mennyire nehéz mérni és rögzíteni a díjszabási modell működtetéséhez szükséges információkat? Ha például az általuk kezdeményezett API-hívások száma alapján tervezi számlázni az ügyfeleket, azonosította, hogyan méri az egyes ügyfelek által indított API-hívásokat?
• A jövedelmezőség attól függ, hogy az ügyfelek korlátozott módon használják-e a megoldást?
• Ha egy ügyfél túlhasználja a megoldást, az azt jelenti, hogy már nem nyereséges?

Vannak olyan kulcsfontosságú tényezők, amelyek befolyásolják a jövedelmezőséget:

• Azure-szolgáltatások díjszabási modelljei. A megoldást alkotó Azure- vagy külső szolgáltatások díjszabási modelljei hatással lehetnek a nyereséges modellekre.
• Szolgáltatáshasználati minták. Előfordulhat, hogy a felhasználóknak csak munkaidőben kell hozzáférniük a megoldáshoz, vagy csak kis százalékban rendelkeznek nagy mennyiségű felhasználóval. Csökkentheti a COGS-t azáltal, hogy csökkenti a kihasználatlan kapacitást, ha a használat alacsony?
• A tárterület növekedése. A legtöbb megoldás idővel összegyűjti az adatokat. A több adat magasabb tárolási és védelmi költséget jelent, ami csökkenti a bérlőnkénti jövedelmezőséget. Beállíthat tárolási kvótákat, vagy kikényszerítheti az adatmegőrzési időszakot?
• Bérlői elkülönítés. A használt bérleti modell hatással van a bérlők közötti elkülönítés szintjére. Ha megosztja az erőforrásait, gondolja át, hogy a bérlők hogyan használhatják túl vagy használják vissza a szolgáltatást? Hogyan befolyásolja a bérlői elkülönítés szintje a COGS-t és a teljesítményt mindenki számára? Egyes tarifamodellek nem nyereségesek az erőforrás-kiosztással kapcsolatos további vezérlők nélkül. Előfordulhat például, hogy szolgáltatásszabályozást kell implementálnia az átalánydíjas díjszabási modell fenntarthatóvá tétele érdekében.
• Bérlői életciklus. Előfordulhat például, hogy a magas ügyfélforgalommal rendelkező megoldások vagy a nagyobb előkészítési erőfeszítést igénylő szolgáltatások alacsonyabb jövedelmezőséget szenvednek el – különösen akkor, ha fogyasztásalapú modellel árazzák őket.
• Szolgáltatásiszint-követelmények. A magasabb szolgáltatási szintet igénylő bérlők azt jelenthetik, hogy a megoldás már nem nyereséges. Kritikus fontosságú, hogy tisztában legyen az ügyfelek szolgáltatásiszint-elvárásaival és a fennálló kötelezettségeikkel, hogy ennek megfelelően tervezhesse meg a tarifamodelleket.

Gyakori díjszabási modellek

Számos gyakori díjszabási modell létezik, amelyeket gyakran használnak több-bérlős megoldásokhoz. Az egyes tarifamodellek kereskedelmi előnyökkel és kockázatokkal járnak, és további architekturális szempontokat igényelnek. Fontos tisztában lenni a tarifamodellek közötti különbségekkel, hogy a megoldás folyamatosan nyereséges maradjon.

Megjegyzés:

Több modellt is kínálhat egy megoldáshoz, vagy kombinálhatja a modelleket. Megadhat például egy felhasználónkénti modellt azoknak az ügyfeleknek, akik meglehetősen stabil felhasználói számokkal rendelkeznek, és fogyasztási modellt is kínálhat azoknak az ügyfeleknek, akik ingadozó használati mintákkal rendelkeznek.

Fogyasztásalapú díjszabás

A használati modellt használatalapú fizetésnek vagy PAYG-nek is nevezik. A szolgáltatás használatának növekedésével a bevétele nő:

A felhasználás mérése során figyelembe vehet egyszerű tényezőket, például a megoldáshoz hozzáadott adatok mennyiségét. Másik lehetőségként megfontolhatja a használati attribútumok kombinációját is. A fogyasztási modellek számos előnnyel járnak, de több-bérlős megoldásban nehéz lehet implementálni őket.

Előnyök: Az ügyfelek szempontjából minimális kezdeti befektetésre van szükség a megoldás használatához, hogy ez a modell alacsony belépési korlátot biztosítson. A szolgáltató szempontjából az üzemeltetési és felügyeleti költségek az ügyfelek használatával és a bevétel növekedésével nőnek. Ez a növekedés nagymértékben skálázható díjszabási modell lehet. A használati díjszabási modellek különösen jól működnek, ha a megoldásban használt Azure-szolgáltatások is használatalapúak.

Összetettség és üzemeltetési költségek: A használati modellek a használat pontos mérésén és a használat bérlőnkénti felosztásán alapulnak. Ez kihívást jelenthet, különösen a sok elosztott összetevőt tartalmazó megoldások esetében. Meg kell őriznie a számlázás és a naplózás részletes fogyasztási rekordjait, valamint olyan módszereket kell nyújtania az ügyfeleknek, amelyek hozzáférést kapnak a fogyasztási adataikhoz.

Kockázatok: A fogyasztás díjszabása arra ösztönözheti az ügyfeleket, hogy csökkentsék a rendszerhasználatukat a költségeik csökkentése érdekében. Emellett a fogyasztási modellek kiszámíthatatlan bevételi adatfolyamokat eredményeznek. Ezt csökkentheti kapacitásfoglalások felajánlásával, ahol az ügyfelek előre fizetnek bizonyos szintű használatért. Ön, mint szolgáltató, ezt a bevételt felhasználhatja a megoldás fejlesztéseibe való befektetésre, a működési költségek csökkentésére vagy az érték megtérülésének növelésére funkciók hozzáadásával.

Megjegyzés:

A kapacitásfoglalások megvalósítása és támogatása növelheti az alkalmazáson belüli számlázási folyamatok összetettségét. Előfordulhat, hogy figyelembe kell vennie, hogy az ügyfelek hogyan kapnak visszatérítést vagy cserélhetik ki kapacitásfoglalásaikat, és ezek a folyamatok kereskedelmi és üzemeltetési kihívásokat is jelenthetnek.

Felhasználónkénti díjszabás

A felhasználónkénti díjszabási modell magában foglalja az ügyfelek díjfizetését a szolgáltatást használó személyek száma alapján, ahogyan az az alábbi ábrán is látható.

A felhasználónkénti díjszabási modellek nagyon gyakoriak, mivel egyszerűek egy több-bérlős megoldásban implementálni. Ezek azonban számos kereskedelmi kockázattal járnak.

Előnyök: Ha minden felhasználónak kiszámlázzuk az ügyfeleket, könnyen kiszámíthatja és előrejelezheti a bevételi adatfolyamot. Emellett, ha feltételezzük, hogy az egyes felhasználókhoz viszonylag konzisztens használati minták tartoznak, akkor a bevétel a szolgáltatás bevezetésével azonos ütemben nő, így ez egy méretezhető modell.

Összetettség és üzemeltetési költségek: A felhasználónkénti modellek általában könnyen implementálhatók. Bizonyos esetekben azonban meg kell mérnie a felhasználónkénti fogyasztást, ami segíthet annak biztosításában, hogy az egyetlen felhasználóra vonatkozó COGS nyereséges maradjon. A fogyasztás mérésével és egy adott felhasználóval való társításával növelheti a megoldás működési összetettségét.

Kockázatok: A különböző felhasználói fogyasztási minták alacsonyabb jövedelmezőséget eredményezhetnek. A megoldás nehéz felhasználói például többe kerülhetnek, mint a könnyű felhasználók. Emellett a megoldás tényleges értékének (ROV) megtérülését nem tükrözi a megvásárolt felhasználói licencek tényleges száma.

Aktív felhasználónkénti díjszabás

Ez a modell hasonló a felhasználónkénti díjszabáshoz, de ahelyett, hogy előzetes kötelezettségvállalást igényel az ügyféltől a várható felhasználók számával kapcsolatban, az ügyfél csak azoknak a felhasználóknak számít fel díjat, amelyek ténylegesen bejelentkeznek és használják a megoldást egy adott időszakban (ahogy az az alábbi ábrán látható).

Ezt bármilyen időszakban megmérheti. A havi időszakok gyakoriak, és ezt a metrikát gyakran havi aktív felhasználóként vagy MAU-ként rögzítik.

Előnyök: Az ügyfelek szempontjából ez a modell alacsony befektetést és kockázatot igényel, mivel minimális a hulladék; a fel nem használt licencek nem számlázhatók. Ez különösen vonzóvá teszi a megoldás marketingje vagy a nagyobb nagyvállalati ügyfelek számára történő növelése során. A szolgáltatás tulajdonosaként az ROV pontosabban tükrözi az ügyfelet a havi aktív felhasználók száma alapján.

Összetettség és üzemeltetési költség: Az aktív felhasználói modellekhez rögzíteni kell a tényleges használatot, és elérhetővé kell tenni az ügyfél számára a számla részeként. A felhasználónkénti fogyasztás mérése segít biztosítani, hogy a jövedelmezőség megmaradjon a COGS-ben egyetlen felhasználó esetében, de ismét további munkát igényel az egyes felhasználók fogyasztásának méréséhez.

Kockázatok: A felhasználónkénti díjszabáshoz hasonlóan fennáll annak a kockázata, hogy az egyes felhasználók különböző fogyasztási mintái hatással lehetnek a jövedelmezőségre. A felhasználónkénti díjszabáshoz képest az aktív felhasználói modellek kevésbé kiszámítható bevételi adatfolyamkal rendelkeznek. Emellett a kedvezményes díjszabás nem nyújt hasznos módot a növekedés ösztönzésére.

Egységenkénti díjszabás

Sok rendszerben nem a felhasználók száma az az elem, amely a legnagyobb hatással van a teljes COGS-ra. Például az eszközorientált megoldásokban, más néven a dolgok internetes hálózatában vagy az IoT-ben az eszközök száma gyakran a legnagyobb hatással van a COGS-ekre. Ezekben a rendszerekben egy egységenkénti díjszabási modell használható, ahol meghatározhatja, hogy mi az egység , például egy eszköz. Lásd az alábbi diagramot.

Emellett egyes megoldások rendkívül változó használati mintákkal rendelkeznek, ahol a felhasználók kis száma aránytalan hatással van a COGS-ekre. Például egy tégla- és habarcskereskedőknek értékesített megoldásban egy üzletenkénti díjszabási modell megfelelő lehet.

Előnyök: Azokban a rendszerekben, ahol az egyes felhasználók nem gyakorolnak jelentős hatást a COGS-re, az egységenkénti díjszabás jobb módja annak, hogy a rendszer skálázásának valóságát és az ebből eredő hatást a COGS-re képviselje. Emellett javíthatja az ügyfél tényleges használati mintáihoz való igazítást is. Számos IoT-megoldás esetében, ahol minden eszköz kiszámítható és állandó fogyasztást hoz létre, ez hatékony modell lehet a megoldás növekedésének skálázásához.

Összetettség és üzemeltetési költség: Általában az egységenkénti díjszabás könnyen implementálható, és meglehetősen alacsony üzemeltetési költséggel rendelkezik. Az üzemeltetési költségek azonban magasabbak lehetnek, ha meg kell különböztetnie és nyomon kell követnie a használatot az egyes egységek, például az eszközök vagy a kiskereskedelmi üzletek szerint. Az egységenkénti fogyasztás mérése segít biztosítani a jövedelmezőség fenntartását, mivel egyetlen egységre vonatkozóan meghatározhatja a COGS-t.

Kockázatok: Az egységenkénti díjszabási modell kockázatai hasonlóak a felhasználónkénti díjszabáshoz. Egyes egységek eltérő fogyasztási mintái azt jelenthetik, hogy csökkent a jövedelmezőség, például ha egyes eszközök vagy üzletek sokkal nehezebb felhasználók a megoldásnak, mint mások.

Szolgáltatás- és szolgáltatásszintű díjszabás

Dönthet úgy, hogy különböző szolgáltatási szinteket kínál a megoldásnak különböző árpontokon. Megadhat például két havi átalány- vagy egységárat, az egyik egy alapszintű ajánlat, amely a rendelkezésre álló funkciók egy részhalmazát tartalmazza, a másik pedig a megoldás funkcióinak átfogó készletét mutatja be. Lásd az alábbi diagramot.

Ez a modell különböző szolgáltatási szintű szerződéseket is kínálhat a különböző szintekhez. Az alapszint például 99,9%-os üzemidőt kínálhat, míg a prémium szint 99,99%-ot. A magasabb szolgáltatási szintű szerződés (SLA) olyan szolgáltatások és szolgáltatások használatával valósítható meg, amelyek magasabb rendelkezésre állási célokat tesznek lehetővé.

Bár ez a modell kereskedelmi szempontból előnyös lehet, érett mérnöki gyakorlatokra van szükség. Körültekintően, ez a modell nagyon hatékony lehet.

Előnyök: A funkcióalapú díjszabás gyakran vonzó az ügyfelek számára, mivel a szükséges szolgáltatáskészlet vagy szolgáltatási szint alapján választhatnak egy szintet. Emellett egyértelmű utat biztosít az ügyfelek további funkciókkal való értékesítéséhez, vagy nagyobb rugalmasságot biztosít azoknak, akik igénylik.

Összetettség és üzemeltetési költségek: A funkcióalapú díjszabási modellek megvalósítása összetett lehet, mivel a megoldásnak tisztában kell lennie az egyes árszinteken elérhető funkciókkal. A funkcióváltók hatékonyan biztosíthatják a funkciók bizonyos részhalmazaihoz való hozzáférést, de ez folyamatos karbantartást igényel. Emellett a funkcióváltók növelik a többletterhelést a magas minőség biztosítása érdekében, mivel több kódútvonalat kell tesztelni. A magasabb szolgáltatási rendelkezésre állási célok egyes szinteken való engedélyezéséhez további architektúra-összetettség szükséges, hogy az egyes szintekhez megfelelő infrastruktúra legyen használatban, és ez a folyamat növelheti a megoldás üzemeltetési költségeit.

Kockázatok: A funkcióalapú díjszabási modellek bonyolulttá és zavaróvá válhatnak, ha túl sok szint vagy lehetőség van. Emellett a funkciók dinamikus összevonásával járó többletterhelés lelassíthatja a további funkciók nyújtásának sebességét.

Freemium díjszabás

Dönthet úgy, hogy ingyenes szolgáltatási szintet kínál, alapszintű funkciókkal és szolgáltatásszintű garanciával. Ezután külön fizetős szintet kínálhat további funkciókkal és formális szolgáltatásiszint-szerződéssel (az alábbi ábrán látható módon).

Előfordulhat, hogy az ingyenes szint korlátozott próbaverzióként is elérhető, és a próbaverzió során az ügyfelek teljes vagy korlátozott funkciókkal rendelkezhetnek. Ezt freemium modellnek nevezzük, amely gyakorlatilag a funkcióalapú díjszabási modell kiterjesztése.

Előnyök: Nagyon könnyű piacra adni egy megoldást, ha ingyenes.

Összetettség és üzemeltetési költség: A szolgáltatásalapú díjszabási modell minden összetettségi és üzemeltetési költségére vonatkozik. Figyelembe kell azonban vennie az ingyenes bérlők kezelésével kapcsolatos üzemeltetési költségeket is. Előfordulhat, hogy gondoskodnia kell arról, hogy az elavult bérlők ki legyenek vonva vagy el legyenek távolítva, és egyértelmű megőrzési szabályzattal kell rendelkeznie, különösen az ingyenes bérlők esetében. A bérlő fizetős szintre való előléptetésekor előfordulhat, hogy a bérlőt át kell helyeznie az Azure-szolgáltatások között a magasabb SLA-k beszerzéséhez. A bérlő adatainak és konfigurációjának megőrzése a fizetős szintre való áttéréskor is fontos.

Kockázatok: Gondoskodnia kell arról, hogy elegendő magas ROV-t biztosítson a bérlők számára, hogy megfontolják a fizetős szintre való váltást. Emellett az ingyenes szinten lévő ügyfeleknek nyújtott megoldás költségeit a fizetős szinteken lévők nyereségmarzsának kell fedeznie.

Eladott áruk ára

Dönthet úgy, hogy a megoldás árát úgy szeretné megfizetni, hogy minden bérlő csak az Azure-szolgáltatásokból való részesedésük üzemeltetési költségeit fizesse ki, hozzáadott haszonkulcs nélkül. Ezt a modellt - más néven átmenő költségeket vagy díjszabást - néha olyan több-bérlős megoldásokhoz használják, amelyek nem profitközpontnak készültek.

Az értékesített áruk költsége jól illeszkedik a belsőleg több-bérlős megoldásokhoz. Minden szervezeti egység egy bérlőnek felel meg, és az Azure-erőforrások költségeit el kell osztani közöttük. Az is helyénvaló lehet, ha a bevétel más termékek és szolgáltatások értékesítéséből származik, amelyek a több-bérlős megoldást használják fel vagy bővítik.

Előnyök: Mivel ez a modell nem tartalmaz hozzáadott haszonkulcsot, a bérlők költségei alacsonyabbak lesznek.

Összetettség és üzemeltetési költség: A fogyasztási modellhez hasonlóan az értékesített áruk ára a használat pontos mérésén és a használat bérlőnkénti felosztásán alapul. A használat nyomon követése kihívást jelenthet, különösen a sok elosztott összetevőt tartalmazó megoldások esetében. Meg kell őriznie a számlázás és a naplózás részletes fogyasztási rekordjait, valamint olyan módszereket kell nyújtania az ügyfeleknek, amelyek hozzáférést kapnak a fogyasztási adataikhoz.

A belsőleg több-bérlős megoldások esetében a bérlők hozzávetőleges költségbecsléseket fogadhatnak el, és nyugodtabb számlázási naplózási követelményekkel rendelkezhetnek. Ezek a nyugodt követelmények csökkentik a megoldás összetettségét és költségeit.

Kockázatok: Az értékesített áruk ára motiválhatja a bérlőket a rendszer használatának csökkentésére a költségek csökkentése érdekében. Mivel azonban ezt a modellt olyan alkalmazásokhoz használják, amelyek nem profitközpontok, ez nem feltétlenül jelent problémát.

Átalánydíjas díjszabás

Ebben a modellben átalánydíjat számít fel egy bérlőnek a megoldáshoz való hozzáférésért egy adott ideig. Ugyanez a díjszabás érvényes a szolgáltatás használatától, a felhasználók számától, a csatlakoztatott eszközök számától vagy bármely más metrikától függetlenül. Lásd az alábbi diagramot.

Ez a legegyszerűbb modell a megvalósításhoz és az ügyfelek számára a megértéshez, és ezt gyakran kérik a nagyvállalati ügyfelek. Ez azonban könnyen veszteségessé válhat, ha továbbra is új funkciókat kell hozzáadnia, vagy ha a bérlői fogyasztás további bevétel nélkül növekszik.

Előnyök: Az átalánydíjas díjszabás könnyen eladható, és az ügyfelek könnyen megérthetik és költségvetést használhatnak.

Összetettség és üzemeltetési költségek: Az átalánydíjas díjszabási modellek könnyen implementálhatók, mert a számlázási ügyfelek nem igényelnek fogyasztásmérést vagy nyomon követési fogyasztást. Bár nem lényeges, célszerű a bérlőnkénti fogyasztást mérni annak biztosítása érdekében, hogy pontosan mérje a COGS-t, és biztosítsa a jövedelmezőség fenntartását.

Kockázatok: Ha olyan bérlői vannak, akik nagyban használják a megoldást, akkor ez a tarifamodell könnyen veszteségessé válik.

Kedvezményes díjszabás

Miután meghatározta a tarifamodellt, dönthet úgy, hogy kereskedelmi stratégiákat implementál a növekedés ösztönzésére a kedvezményes díjszabással. A kedvezményes díjszabás használatalapú, felhasználónkénti és egységenkénti díjszabási modellekkel használható.

Megjegyzés:

A kedvezményes díjszabás általában nem igényel architekturális szempontokat, az összetettebb számlázási struktúra támogatásán túl. A kedvezmény kereskedelmi előnyeinek teljes körű megvitatása meghaladja a jelen dokumentum hatókörét.

A kedvezmény díjszabásának gyakori mintái a következők:

• Rögzített díjszabás. Minden felhasználóra, egységre vagy fogyasztásra ugyanazt a költséget kell fizetnie, függetlenül attól, hogy mennyit vásárolnak vagy használnak fel. Ez a legegyszerűbb megközelítés. Azonban azok az ügyfelek, akik nagy mértékben használják a megoldást, úgy érezhetik, hogy kedvezményt kapnak a méretgazdaságosság előnyeiből.
• Csökkenő díjszabás. Mivel az ügyfelek több egységet vásárolnak vagy használnak fel, ön csökkenti az egységenkénti költséget. Ez üzleti szempontból vonzóbb az ügyfelek számára.
• Lépés díjszabása. Az egy egységre jutó költséget csökkentheti, mivel az ügyfelek többet vásárolnak. Ezt azonban a lépésmódosítások során, előre meghatározott mennyiségi tartományok alapján teheti meg. Előfordulhat például, hogy magasabb árat számít fel az első 100 felhasználóért, majd alacsonyabb árat a 101. és a 200. felhasználó számára, majd utána ismét alacsonyabb árat. Ez nyereségesebb is lehet.

Az alábbi ábra ezeket a díjszabási mintákat szemlélteti.

Nem éles környezetben érvényes kedvezmények

Az ügyfeleknek sok esetben hozzáférésre van szükségük egy nem éles környezethez, amelyet teszteléshez, betanításhoz vagy saját belső dokumentációjuk létrehozásához használhatnak. A nem éles környezetek általában alacsonyabb fogyasztási követelményekkel és költségekkel rendelkeznek a működéshez. Például a nem éles környezetekre gyakran nem vonatkoznak szolgáltatási szintű szerződések (SLA-k), és a sebességkorlátok alacsonyabb értékeken állíthatók be. Az Azure-szolgáltatások agresszívebb automatikus skálázását is megfontolhatja.

Az ügyfelek gyakran elvárják, hogy a nem éles környezetek jelentősen olcsóbbak legyenek, mint az éles környezeteik. Számos alternatíva lehet megfelelő, ha nem éles környezeteket biztosít:

• Kínáljon egy freemiumszintet, mint ahogy azt a fizetős ügyfelek esetében is megteheti. Ezt gondosan figyelni kell, mivel egyes szervezetek számos tesztelési és betanítási környezetet hozhatnak létre, amelyek további erőforrásokat fognak használni a működéshez.

  Megjegyzés:

  A freemiumszinteket használó időkorlátos próbaverziók általában nem alkalmasak tesztelési és betanítási környezetekhez. Az ügyfeleknek általában arra van szükségük, hogy a nem éles környezeteik az éles szolgáltatás teljes élettartama alatt elérhetők legyenek.

• A szolgáltatás tesztelési vagy betanítási szintjét kínálhatja alacsonyabb használati korlátokkal. Dönthet úgy, hogy a szint rendelkezésre állását a meglévő fizetős bérlőt használó ügyfelekre korlátozza.
• Kedvezményes felhasználónkénti, aktív felhasználónkénti vagy egységenkénti díjszabást kínálhat a nem éles bérlők számára, alacsonyabb vagy nem szolgáltatási szintű szerződéssel.
• Az átalánydíjas díjszabást használó bérlők esetében előfordulhat, hogy a megállapodás részeként nem éles környezetekről is tárgyalnak.

Megjegyzés:

A funkcióalapú díjszabás általában nem jó választás nem éles környezetek esetében, kivéve, ha a kínált funkciók megegyeznek az éles környezet által kínált szolgáltatásokkal. Ennek az az oka, hogy a bérlők általában ugyanazokat a funkciókat szeretnék tesztelni és betanítást biztosítani, amelyek éles környezetben érhetők el.

Nem nyereséges díjszabási modellek

A nem nyereséges díjszabási modell többe kerül a szolgáltatás nyújtásához, mint a bevétel. Előfordulhat például, hogy bérlőnkénti átalánydíjat számol fel a szolgáltatás korlátozása nélkül, de a szolgáltatást használatalapú Azure-erőforrásokkal és bérlőnkénti használati korlátok nélkül építené fel. Ebben az esetben előfordulhat, hogy a bérlők túlhasználják a szolgáltatást, és így veszteségessé teszik a kiszolgálásukat.

Általában el szeretné kerülni a nem jövedelmező díjszabási modelleket. Vannak azonban olyan helyzetek, amikor úgy dönthet, hogy nem jövedelmező díjszabási modellt vezet be, például:

• A növekedés érdekében ingyenes szolgáltatást kínálunk.
• A további bevételi streameket szolgáltatások vagy bővítményfunkciók biztosítják.
• Egy adott bérlő üzemeltetése egy másik kereskedelmi értéket biztosít, például horgony bérlőként való használatát egy új piacon.

Abban az esetben, ha véletlenül nem nyereséges díjszabási modellt hoz létre, többféleképpen is mérsékelheti a hozzájuk kapcsolódó kockázatokat, például:

• A szolgáltatás használatának korlátozása a használati korlátokon keresztül.
• Kapacitásfoglalások használatának megkövetelése.
• Kérje meg a bérlőt, hogy lépjen egy magasabb szolgáltatás- vagy szolgáltatási szintre.

Kockázatos díjszabási modellek

Egy megoldás díjszabási modelljének implementálásakor általában feltételeznie kell, hogy hogyan fogja használni. Ha ezek a feltételezések helytelennek bizonyulnak, vagy a használati minták idővel megváltoznak, akkor a díjszabási modell veszteségessé válhat. A veszteségessé válás kockázatának kitett díjszabási modelleket kockázatos díjszabási modelleknek nevezzük. Ha például olyan tarifamodellt vezet be, amely arra számít, hogy a felhasználók önkorlátozóan korlátozzák a megoldás általuk használt összeget, akkor előfordulhat, hogy kockázatos díjszabási modellt implementáltak.

A legtöbb SaaS-megoldás rendszeresen új funkciókat ad hozzá. Ez növeli a ROV-t a felhasználók számára, ami a megoldás által használt mennyiség növekedéséhez is vezethet. Ez olyan megoldást eredményezhet, amely veszteségessé válik, ha az új funkciók használata a használatot vezérli, de a díjszabási modell ezt nem veszi figyelembe.

Ha például egy új videófeltöltési funkciót vezet be a megoldásba, amely egy használatalapú erőforrást használ, és a szolgáltatás felhasználói elterjedtsége magasabb a vártnál, akkor fontolja meg a használati korlátok, a funkciók és a szolgáltatásszintű díjszabás kombinációját.

Használati korlátok

A használati korlátok lehetővé teszik a szolgáltatás használatának korlátozását annak érdekében, hogy a tarifamodellek ne legyenek veszteségesek, vagy hogy egyetlen bérlő ne használja fel aránytalanul nagy mértékben a szolgáltatás kapacitását. Ez különösen fontos lehet a több-bérlős szolgáltatásokban, ahol egyetlen bérlő hatással lehet más bérlők élményére az erőforrások túlzott felhasználásával.

Megjegyzés:

Fontos, hogy az ügyfelek tisztában legyenek a használati korlátok alkalmazásával. Ha a használati korlátokat úgy valósítja meg, hogy az ügyfelek nem ismerik fel a korlátot, az az ügyfelek elégedetlenségét eredményezi. Ez azt jelenti, hogy fontos, hogy a használati korlátokat előre meg lehessen határozni és megtervezni. A cél a korlát megtervezése, majd a korlátok kommunikálása az ügyfelekkel, mielőtt szükségessé válnának.

A használati korlátokat gyakran használják funkció- és szolgáltatási szintű díjszabással kombinálva, hogy magasabb szintű használatot biztosítsanak. A korlátokat gyakran használják olyan alapvető összetevők védelmére is, amelyek a rendszer szűk keresztmetszeteit vagy teljesítményproblémákat okoznak, ha túlhasználják őket.

Sebességkorlátok

A használati korlátok alkalmazásának gyakori módja, ha sebességkorlátokat ad hozzá az API-khoz vagy adott alkalmazásfüggvényekhez. Ezt szabályozásnak is nevezik. A sebességkorlátok megakadályozzák a folyamatos túlhasználatot. Gyakran használják őket az API-ra irányuló hívások számának meghatározott időszakra történő korlátozására. Egy API-t például csak percenként 20-szor lehet meghívni, és http 429-es hibát ad vissza, ha ennél gyakrabban hívják meg.

Bizonyos helyzetekben, ahol gyakran használják a sebességkorlátozást, az alábbiakat foglalja magában:

• REST API-k.
• Aszinkron feladatok.
• Nem időérzékeny feladatok.
• Olyan műveletek, amelyek végrehajtása magas költséggel jár.
• Jelentéskészítés.

A sebességkorlátozás implementálása növelheti a megoldás összetettségét, de az Azure API Managementhez hasonló szolgáltatások ezt egyszerűbbé tehetik a sebességkorlát-szabályzatok alkalmazásával.

A díjszabási modell életciklusa

A megoldás többi részéhez hasonlóan a tarifamodellek is életciklussal rendelkeznek. Ahogy az alkalmazás idővel fejlődik, előfordulhat, hogy módosítania kell a díjszabási modelleket. Ennek oka lehet az ügyféligények, a kereskedelmi követelmények vagy az alkalmazáson belüli funkciók módosítása. Néhány gyakori díjszabási életciklus-módosítás a következőket tartalmazza:

• Teljesen új díjszabási modell hozzáadása. Például egy fogyasztási díjszabási modell hozzáadása egy olyan megoldáshoz, amely jelenleg átalánymodellt kínál.
• Meglévő tarifamodell kivonása.
• Réteg hozzáadása meglévő tarifamodellhez.
• Egy szint kivonása egy meglévő tarifamodellben.
• A díjszabási modell egy funkciójára vonatkozó használati korlátok módosítása.
• Szolgáltatások hozzáadása vagy eltávolítása egy szolgáltatás- és szolgáltatásszintű díjszabási modellből.
• Váltás üzleti felhasználók közötti (B2C) kereskedelmi modellről üzletközi (B2B) kereskedelmi modellre. Ez a változás új díjszabási struktúrákat igényel az üzleti ügyfelek számára.

Általában bonyolult egyszerre számos különböző díjszabási modell implementálása és kezelése. Az ügyfelek számára is zavaró. Így jobb, ha csak egy vagy két modellt implementál, kis számú réteggel. Ez akadálymentesebbé és könnyebben kezelhetővé teszi a megoldást.

Megjegyzés:

A díjszabási modelleket és a számlázási függvényeket tesztelni kell, ideális esetben automatizált teszteléssel, ugyanúgy, mint a rendszer bármely más része. Minél összetettebbek a tarifamodellek, annál több tesztelésre van szükség, így a fejlesztési költségek és az új funkciók növekedni fognak.

A díjszabási modellek módosításakor a következő tényezőket kell figyelembe vennie:

• A bérlők át szeretnének migrálni az új modellbe?
• A bérlők egyszerűen migrálhatóak az új modellbe?
• Az új díjszabási modellek kockázatnak teszik ki a szolgáltatást? Eltávolítja például azokat a sebességkorlátokat, amelyek jelenleg védik a kritikus erőforrásokat a túlzott használattól?
• A bérlőknek egyértelmű elérési útjuk van az új díjszabási modellbe való migráláshoz?
• Hogyan akadályozhatja meg, hogy a bérlők régebbi tarifamodelleket használjanak, hogy kivonhassa őket?
• A bérlők valószínűleg sokkot kapnak a díjszabási modellek módosításakor (negatív reakció egy váratlan számlára) ?
• Figyeli a szolgáltatások teljesítményét és kihasználtságát az új vagy módosított díjszabási modellek esetében, hogy biztosítsa a folyamatos jövedelmezőséget?
• Képes egyértelműen kommunikálni az új díjszabási modellek ROV-ját a meglévő bérlőkkel?

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerző:

• Daniel Scott-Raynsford | Partnertechnológiai stratéga

Egyéb közreműködők:

• Bohdan Cherchyk | Az Azure-hoz készült FastTrack vezető ügyfélmérnöke
• John Downs | Az Azure-hoz készült FastTrack vezető ügyfélmérnöke
• Chad Kittel | Fő szoftvermérnök
• Paolo Salvatori | Az Azure-hoz készült FastTrack vezető ügyfélmérnöke
• Arsen Vladimirskiy | Az Azure-hoz készült FastTrack vezető ügyfélmérnöke

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

További lépések

Gondolja át, hogyan fogja mérni a bérlők általi felhasználást a megoldásban.