Modele cen dla rozwiązania wielodostępnego

Dobry model cenowy zapewnia, że w miarę wzrostu liczby dzierżaw i dodawania nowych funkcji pozostaje opłacalne. Ważnym zagadnieniem podczas opracowywania komercyjnego rozwiązania wielodostępnego jest projektowanie modeli cenowych dla produktu. Na tej stronie udostępniamy wskazówki dla osób podejmujących decyzje techniczne dotyczące modeli cenowych, które można wziąć pod uwagę, oraz kompromisów związanych z nimi.

Podczas określania modelu cenowego produktu należy zrównoważyć zwrot z wartości (ROV) dla klientów kosztem sprzedanych towarów (COGS), aby dostarczyć usługę. Oferowanie bardziej elastycznych modeli komercyjnych (w przypadku rozwiązania) może zwiększyć ROV dla klientów, ale może również zwiększyć złożoność architektury i komercyjną rozwiązania (a tym samym zwiększyć twoją WSPÓŁPRACĘ ZABEZPIECZEŃ).

Niektóre ważne zagadnienia, które należy wziąć pod uwagę podczas opracowywania modeli cenowych dla rozwiązania, są następujące:

• Czy COGS będzie wyższy niż zysk uzyskany z rozwiązania?
• Czy usługa COGS może ulec zmianie w czasie na podstawie wzrostu użytkowników lub zmian w wzorcach użycia?
• Jak trudno jest zmierzyć i zarejestrować informacje wymagane do obsługi modelu cenowego? Jeśli na przykład planujesz rozliczać klientów na podstawie liczby wykonanych wywołań interfejsu API, czy zidentyfikowano sposób mierzenia wywołań interfejsu API wykonanych przez każdego klienta?
• Czy zyskowność zależy od zapewnienia, że klienci korzystają z rozwiązania w ograniczony sposób?
• Jeśli klient nadmiernie korzysta z rozwiązania, czy oznacza to, że nie jesteś już rentowny?

Istnieją pewne kluczowe czynniki wpływające na rentowność:

• Modele cen usług platformy Azure. Modele cenowe usług platformy Azure lub innych firm, które tworzą rozwiązanie, mogą mieć wpływ na to, które modele są opłacalne.
• Wzorce użycia usługi. Użytkownicy mogą mieć dostęp tylko do rozwiązania w godzinach pracy lub mogą mieć niewielki odsetek użytkowników o dużej liczbą. Czy można zmniejszyć coGS, zmniejszając nieużywaną pojemność, gdy użycie jest niskie?
• Wzrost magazynu. Większość rozwiązań gromadzi dane w czasie. Więcej danych oznacza wyższy koszt przechowywania i ochrony, co zmniejsza zyskowność na dzierżawę. Czy można ustawić limity przydziału magazynu lub wymusić okres przechowywania danych?
• Izolacja dzierżawy. Używany model dzierżawy ma wpływ na poziom izolacji między dzierżawami. Jeśli udostępniasz zasoby, czy musisz wziąć pod uwagę, w jaki sposób dzierżawcy mogą nadmiernie wykorzystywać lub nadużywać usługi? W jaki sposób poziom izolacji dzierżawy wpłynie na twoją grupę coGS i wydajność dla wszystkich? Niektóre modele cenowe nie są opłacalne bez dodatkowych mechanizmów kontroli dotyczących alokacji zasobów. Na przykład może być konieczne zaimplementowanie ograniczania usługi w celu zapewnienia zrównoważonego modelu cen zryczałtowaną.
• Cykl życia dzierżawy. Na przykład rozwiązania z wysokimi współczynnikami zmian klientów lub usług, które wymagają większego nakładu pracy na pokładzie, mogą cierpieć na niższą rentowność — zwłaszcza jeśli są wyceniane przy użyciu modelu opartego na użyciu.
• Wymagania dotyczące poziomu usług. Dzierżawy wymagające wyższego poziomu usług mogą oznaczać, że rozwiązanie nie jest już opłacalne. Ważne jest, aby jasno poznać oczekiwania klientów na poziomie usług i wszelkie posiadane zobowiązania, dzięki czemu można odpowiednio zaplanować modele cenowe.

Typowe modele cenowe

Istnieje wiele typowych modeli cenowych, które są często używane z rozwiązaniami wielodostępnymi. Każdy z tych modeli cenowych ma związane z komercyjnymi korzyściami i ryzykiem i wymaga dodatkowych zagadnień dotyczących architektury. Ważne jest, aby zrozumieć różnice między tymi modelami cenowymi, aby zapewnić, że rozwiązanie pozostanie opłacalne w miarę rozwoju.

Uwaga

Możesz zaoferować wiele modeli dla rozwiązania lub połączyć modele razem. Można na przykład podać model dla poszczególnych użytkowników dla klientów, którzy mają dość stabilne liczby użytkowników, i można również zaoferować model zużycia dla klientów, którzy mają zmienne wzorce użycia.

Ceny oparte na użyciu

Model zużycia jest czasami określany jako płatność zgodnie z rzeczywistym użyciem lub płatność zgodnie z rzeczywistym użyciem. W miarę zwiększania się użycia usługi przychody rosną:

Podczas mierzenia zużycia można wziąć pod uwagę proste czynniki, takie jak ilość danych dodawanych do rozwiązania. Alternatywnie można rozważyć kombinację atrybutów użycia razem. Modele zużycia oferują wiele korzyści, ale mogą być trudne do zaimplementowania w rozwiązaniu wielodostępnym.

Korzyści: z perspektywy klientów istnieje minimalna inwestycja z góry wymagana do korzystania z rozwiązania, dzięki czemu ten model ma niską barierę wejścia. Z perspektywy operatora usługi koszty hostingu i zarządzania rosną wraz ze wzrostem użycia klientów i przychodów. Ten wzrost może sprawić, że będzie to wysoce skalowalny model cen. Modele cen użycia działają szczególnie dobrze, gdy usługi platformy Azure używane w rozwiązaniu również są oparte na użyciu.

Złożoność i koszt operacyjny: Modele zużycia opierają się na dokładnych pomiarach użycia i dzieleniu tego użycia przez dzierżawę. Może to być trudne, szczególnie w rozwiązaniu z wieloma składnikami rozproszonymi. Należy zachować szczegółowe rekordy użycia na potrzeby rozliczeń i inspekcji, a także zapewnić klientom metody uzyskiwania dostępu do danych użycia.

Ryzyko: Ceny zużycia mogą zachęcić klientów do zmniejszenia użycia systemu, aby zmniejszyć koszty. Ponadto modele zużycia powodują nieprzewidywalne strumienie przychodów. Możesz temu zapobiec, oferując rezerwacje pojemności, w których klienci płacą za jakiś poziom zużycia z góry. Jako dostawca usług możesz użyć tego przychodu, aby zainwestować w ulepszenia rozwiązania, aby zmniejszyć koszty operacyjne lub zwiększyć zwrot z wartości przez dodanie funkcji.

Uwaga

Implementowanie i obsługa rezerwacji pojemności może zwiększyć złożoność procesów rozliczeniowych w aplikacji. Może być również konieczne rozważenie sposobu, w jaki klienci otrzymują zwrot kosztów lub wymieniają rezerwacje pojemności, a te procesy mogą również dodawać wyzwania komercyjne i operacyjne.

Cennik poszczególnych użytkowników

Model cen dla poszczególnych użytkowników obejmuje naliczanie opłat za klientów na podstawie liczby osób korzystających z usługi, jak pokazano na poniższym diagramie.

Modele cenowe poszczególnych użytkowników są bardzo powszechne ze względu na ich prostotę implementacji w rozwiązaniu wielodostępnym. Są one jednak związane z kilkoma zagrożeniami komercyjnymi.

Korzyści: w przypadku rozliczania klientów dla każdego użytkownika można łatwo obliczyć i prognozować strumień przychodów. Ponadto przy założeniu, że masz dość spójne wzorce użycia dla każdego użytkownika, przychody rosną w takim samym tempie co wdrożenie usług, dzięki czemu jest to skalowalny model.

Złożoność i koszt operacyjny: modele poszczególnych użytkowników są zwykle łatwe do zaimplementowania. Jednak w niektórych sytuacjach należy zmierzyć użycie poszczególnych użytkowników, co może pomóc w zapewnieniu, że coGS dla pojedynczego użytkownika pozostaje opłacalne. Mierząc zużycie i kojarząc je z konkretnym użytkownikiem, można zwiększyć złożoność operacyjną rozwiązania.

Ryzyko: Różne wzorce zużycia użytkowników mogą spowodować zmniejszenie rentowności. Na przykład użytkownicy z dużym obciążeniem rozwiązania mogą kosztować więcej niż użytkowników lekkich. Ponadto rzeczywisty zwrot wartości (ROV) dla rozwiązania nie jest odzwierciedlany przez rzeczywistą liczbę zakupionych licencji użytkownika.

Ceny poszczególnych aktywnych użytkowników

Ten model jest podobny do cen poszczególnych użytkowników, ale zamiast wymagać zobowiązania z góry od klienta w przypadku liczby oczekiwanych użytkowników, klient jest naliczany tylko za użytkowników, którzy rzeczywiście logują się do rozwiązania i korzystają z niego w danym okresie (jak pokazano na poniższym diagramie).

Można to zmierzyć w jakimkolwiek okresie ma sens. Okresy miesięczne są powszechne, a następnie ta metryka jest często rejestrowana jako co miesiąc aktywni użytkownicy lub MAU.

Korzyści: Z perspektywy klientów ten model wymaga niskiej inwestycji i ryzyka, ponieważ jest to minimalne straty; niewykorzystane licencje nie są rozliczane. Sprawia to, że jest to szczególnie atrakcyjne w przypadku marketingu rozwiązania lub rozwoju rozwiązania dla większych klientów korporacyjnych. Z punktu widzenia właściciela usługi twój ROV jest dokładniej odzwierciedlany klientowi przez liczbę aktywnych użytkowników miesięcznie.

Złożoność i koszt operacyjny: Modele użytkowników aktywnych wymagają zarejestrowania rzeczywistego użycia i udostępnienia go klientowi w ramach faktury. Mierzenie zużycia poszczególnych użytkowników pomaga zapewnić utrzymanie rentowności w usłudze COGS dla jednego użytkownika, ale ponownie wymaga dodatkowej pracy w celu zmierzenia zużycia dla każdego użytkownika.

Ryzyko: Podobnie jak w przypadku cen poszczególnych użytkowników, istnieje ryzyko, że różne wzorce zużycia poszczególnych użytkowników mogą mieć wpływ na rentowność. W porównaniu z cenami poszczególnych użytkowników modele poszczególnych aktywnych użytkowników mają mniej przewidywalny strumień przychodów. Ponadto ceny rabatów nie zapewniają przydatnego sposobu stymulowania wzrostu.

Ceny za jednostkę

W wielu systemach liczba użytkowników nie jest elementem, który ma największy wpływ na ogólną grupę COGS. Na przykład w rozwiązaniach zorientowanych na urządzeniach, nazywanych również Internetem rzeczy lub IoT, liczba urządzeń często ma największy wpływ na COGS. W tych systemach można użyć modelu cenowego dla poszczególnych jednostek, w którym można zdefiniować jednostkę, taką jak urządzenie. Zapoznaj się z poniższym diagramem.

Ponadto niektóre rozwiązania mają bardzo zmienne wzorce użycia, w których niewielka liczba użytkowników ma nieproporcjonalny wpływ na COGS. Na przykład w rozwiązaniu sprzedawanym sprzedawcom detalicznym z cegły i zaprawy model cenowy dla sklepu może być odpowiedni.

Korzyści: w systemach, w których indywidualni użytkownicy nie mają znaczącego wpływu na COGS, ceny na jednostkę są lepszym sposobem reprezentowania rzeczywistości skalowania systemu i wynikającego z tego wpływu na COGS. Może również poprawić dopasowanie do rzeczywistych wzorców użycia dla klienta. W przypadku wielu rozwiązań IoT, w których każde urządzenie generuje przewidywalną i stałą ilość zużycia, może to być skuteczny model skalowania wzrostu rozwiązania.

Złożoność i koszt operacyjny: Ogólnie rzecz biorąc, ceny za jednostkę są łatwe do zaimplementowania i mają dość niski koszt operacyjny. Jednak koszt operacyjny może stać się wyższy, jeśli trzeba rozróżniać i śledzić użycie poszczególnych jednostek, takich jak urządzenia lub sklepy detaliczne. Pomiar zużycia poszczególnych jednostek pomaga zapewnić utrzymanie rentowności, ponieważ można określić COGS dla pojedynczej jednostki.

Ryzyko: ryzyko modelu cenowego dla poszczególnych jednostek jest podobne do cen poszczególnych użytkowników. Różne wzorce zużycia przez niektóre jednostki mogą oznaczać zmniejszenie rentowności, na przykład jeśli niektóre urządzenia lub sklepy są znacznie cięższymi użytkownikami rozwiązania niż inne.

Cennik oparty na funkcjach i na poziomie usług

Możesz zaoferować rozwiązanie z różnymi warstwami funkcjonalności w różnych punktach cenowych. Na przykład możesz podać dwie miesięczne ceny zryczałtowaną lub jednostkową, jedną z ofertą podstawową z dostępnym podzbiorem funkcji, a drugą — kompleksowym zestawem funkcji rozwiązania. Zapoznaj się z poniższym diagramem.

Ten model może również oferować różne umowy dotyczące poziomu usług dla różnych warstw. Na przykład warstwa podstawowa może oferować czas pracy na poziomie 99,9%, natomiast warstwa Premium może oferować 99,99%. Wyższą umowę dotyczącą poziomu usług (SLA) można zaimplementować przy użyciu usług i funkcji, które umożliwiają uzyskanie wyższych celów dostępności.

Chociaż ten model może być korzystny komercyjnie, wymaga dojrzałych praktyk inżynieryjnych. Przy starannym rozważeniu ten model może być bardzo skuteczny.

Korzyści: ceny oparte na funkcjach są często atrakcyjne dla klientów, ponieważ mogą wybrać warstwę na podstawie wymaganego zestawu funkcji lub poziomu usług. Zapewnia również wyraźną ścieżkę do zwiększenia sprzedaży klientów z dodatkowymi funkcjami lub większą odpornością dla tych, którzy tego potrzebują.

Złożoność i koszt operacyjny: Modele cenowe oparte na funkcjach mogą być złożone do zaimplementowania, ponieważ wymagają one, aby rozwiązanie wiedziało o funkcjach dostępnych w każdej warstwie cenowej. Przełączanie funkcji może być skutecznym sposobem zapewnienia dostępu do niektórych podzbiorów funkcjonalności, ale wymaga to ciągłej konserwacji. Ponadto przełączanie funkcji zwiększa obciążenie, aby zapewnić wysoką jakość, ponieważ będzie więcej ścieżek kodu do testowania. Włączenie wyższych celów dostępności usług w niektórych warstwach może wymagać dodatkowej złożoności architektury, aby upewnić się, że odpowiedni zestaw infrastruktury jest używany dla każdej warstwy, a ten proces może zwiększyć koszt operacyjny rozwiązania.

Ryzyko: Modele cenowe oparte na funkcjach mogą stać się skomplikowane i mylące, jeśli istnieje zbyt wiele warstw lub opcji. Ponadto obciążenie związane z dynamicznym przełączaniem funkcji może spowolnić szybkość dostarczania dodatkowych funkcji.

Cennik freemium

Możesz zaoferować warstwę bezpłatną usługi z podstawową funkcjonalnością i bez gwarancji poziomu usług. Następnie możesz zaoferować oddzielną warstwę płatną z dodatkowymi funkcjami i formalną umową dotyczącą poziomu usług (jak pokazano na poniższym diagramie).

Warstwa Bezpłatna może być również oferowana jako wersja próbna ograniczona czasowo, a w okresie próbnym klienci mogą mieć dostęp do pełnej lub ograniczonej funkcjonalności. Jest to nazywane modelem freemium, który jest skutecznie rozszerzeniem modelu cen opartego na funkcjach.

Korzyści: bardzo łatwo jest reklamować rozwiązanie, gdy jest bezpłatne.

Złożoność i koszt operacyjny: Wszystkie problemy związane z złożonością i kosztami operacyjnymi mają zastosowanie z modelu cen opartego na funkcjach. Należy jednak również wziąć pod uwagę koszty operacyjne związane z zarządzaniem bezpłatnymi dzierżawami. Może być konieczne upewnienie się, że nieaktywne dzierżawy są odłączane lub usuwane, a w przypadku dzierżaw bezpłatnych musisz mieć zasady przechowywania jasnego. W przypadku podwyższenia poziomu dzierżawy do warstwy płatnej może być konieczne przeniesienie dzierżawy między usługami platformy Azure, aby uzyskać wyższe umowy SLA. Ważne będzie również zachowanie danych i konfiguracji dzierżawy podczas przechodzenia do warstwy płatnej.

Czynniki ryzyka: należy zapewnić wystarczająco wysoką wartość ROV dla dzierżaw, aby rozważyć przełączenie do warstwy płatnej. Ponadto koszt dostarczania rozwiązania klientom w warstwie Bezpłatna musi być objęty marżą zysku od tych, którzy znajdują się w warstwach płatnych.

Koszt sprzedanych towarów

Możesz zdecydować się na cenę rozwiązania, aby każda dzierżawa płaciła tylko koszt obsługi udziału usług platformy Azure bez dodatkowej marży zysku. Ten model — nazywany również kosztami lub cenami — jest czasami używany w przypadku wielodostępnych rozwiązań, które nie mają być centrum zysków.

Koszt sprzedanych towarów jest dobrym rozwiązaniem dla rozwiązań wielodostępnych. Każda jednostka organizacyjna odpowiada dzierżawie, a koszty zasobów platformy Azure muszą być rozłożone między nimi. Może to być również odpowiednie, gdy przychody pochodzą ze sprzedaży innych produktów i usług, które zużywają lub rozszerzają rozwiązanie wielodostępne.

Korzyści: ponieważ ten model nie zawiera żadnego dodatkowego marży dla zysku, koszt dzierżawy będzie niższy.

Złożoność i koszt operacyjny: Podobnie jak w modelu zużycia, koszt sprzedanych towarów zależy od dokładnych pomiarów użycia i podziału tego użycia przez dzierżawę. Śledzenie zużycia może być trudne, zwłaszcza w rozwiązaniu z wieloma składnikami rozproszonymi. Należy zachować szczegółowe rekordy użycia na potrzeby rozliczeń i inspekcji, a także zapewnić klientom metody uzyskiwania dostępu do danych użycia.

W przypadku rozwiązań wielodostępnych wewnętrznych dzierżawcy mogą akceptować przybliżone szacunki kosztów i mieć bardziej złagodzone wymagania dotyczące inspekcji rozliczeń. Te złagodzone wymagania zmniejszają złożoność i koszty działania rozwiązania.

Ryzyko: Koszt sprzedanych towarów może zachęcić dzierżawców do zmniejszenia użycia systemu w celu zmniejszenia kosztów. Jednak ponieważ ten model jest używany w przypadku aplikacji, które nie są centrami zysków, może to nie być problemem.

Cennik z ryczałtami

W tym modelu opłaty są naliczane zryczałtowaną stawkę dla dzierżawy w celu uzyskania dostępu do rozwiązania przez dany okres czasu. Te same ceny mają zastosowanie niezależnie od tego, ile korzystają z usługi, liczby użytkowników, liczby urządzeń, z którymi się łączą lub jakiejkolwiek innej metryki. Zapoznaj się z poniższym diagramem.

Jest to najprostszy model do zaimplementowania i zrozumienia przez klientów, który jest często wymagany przez klientów korporacyjnych. Jednak może łatwo stać się nieopłacalne, jeśli musisz nadal dodawać nowe funkcje lub jeśli użycie dzierżawy wzrasta bez dodatkowych przychodów.

Korzyści: Ceny z ryczałtami są łatwe do sprzedaży i łatwo jest zrozumieć i budżetować klientów.

Złożoność i koszt operacyjny: modele cen stawek prostych mogą być łatwe do zaimplementowania, ponieważ klienci rozliczeń nie wymagają żadnych pomiarów ani śledzenia zużycia. Jednak chociaż nie jest to niezbędne, zaleca się pomiar zużycia poszczególnych dzierżaw, aby upewnić się, że mierzysz dokładnie coGS i upewnisz się, że rentowność jest utrzymywana.

Ryzyko: jeśli masz dzierżawców, którzy korzystają z rozwiązania, łatwo jest to zrobić, aby ten model cen stał się nierentowny.

Cennik rabatu

Po zdefiniowaniu modelu cenowego możesz wdrożyć strategie komercyjne, aby zachęcić do wzrostu poprzez ceny rabatowe. Ceny rabatu mogą być używane z modelami cen użycia, poszczególnych użytkowników i cen na jednostkę.

Uwaga

Ceny rabatów nie wymagają zwykle zagadnień dotyczących architektury, poza dodaniem obsługi bardziej złożonej struktury rozliczeń. Kompletna dyskusja na temat korzyści komercyjnych z rabatami wykracza poza zakres tego dokumentu.

Typowe wzorce cen rabatów obejmują:

• Stałe ceny. Masz ten sam koszt dla każdego użytkownika, jednostki lub ilości zużycia, niezależnie od tego, ile jest kupowane lub zużywane. Jest to najprostsze podejście. Jednak klienci, którzy korzystają z twojego rozwiązania, mogą czuć się jak powinni korzystać z korzyści skali, uzyskując rabat.
• Rozbieżne ceny. Gdy klienci kupują lub zużywają więcej jednostek, zmniejszasz koszt jednostkowy. Jest to bardziej atrakcyjne komercyjnie dla klientów.
• Cennik kroków. Obniżasz koszt jednostkowy, ponieważ klienci kupują więcej. Jednak należy to zrobić w ramach zmian kroków na podstawie wstępnie zdefiniowanych zakresów ilości. Na przykład możesz ponieść wyższą cenę dla pierwszych 100 użytkowników, a następnie niższą cenę dla 101-200 użytkownika, a następnie ponownie niższą cenę. Może to być bardziej opłacalne.

Na poniższym diagramie przedstawiono te wzorce cen.

Rabaty środowiska nieprodukcyjnego

W wielu przypadkach klienci wymagają dostępu do środowiska nieprodukcyjnego, którego mogą używać do testowania, trenowania lub tworzenia własnej dokumentacji wewnętrznej. Środowiska nieprodukcyjne zwykle mają niższe wymagania dotyczące zużycia i koszty działania. Na przykład środowiska nieprodukcyjne często nie podlegają umowom dotyczącymi poziomu usług (SLA), a limity szybkości mogą być ustawiane przy niższych wartościach . Możesz również rozważyć bardziej agresywne skalowanie automatyczne w usługach platformy Azure.

Klienci często oczekują, że środowiska nieprodukcyjne będą znacznie tańsze niż środowiska produkcyjne. Istnieje kilka alternatyw, które mogą być odpowiednie, jeśli udostępniasz środowiska nieprodukcyjne:

• Zaoferuj warstwę freemium, podobnie jak w przypadku płatnych klientów. Powinno to być dokładnie monitorowane, ponieważ niektóre organizacje mogą tworzyć wiele środowisk testowych i szkoleniowych, które będą zużywać dodatkowe zasoby do działania.

  Uwaga

  Ograniczone czasowo wersje próbne korzystające z warstw freemium zwykle nie są odpowiednie dla środowisk testowych i szkoleniowych. Klienci zwykle potrzebują, aby ich środowiska nieprodukcyjne mogły być dostępne przez cały okres istnienia usługi produkcyjnej.

• Oferowanie warstwy testowania lub trenowania usługi z niższymi limitami użycia. Możesz ograniczyć dostępność tej warstwy do klientów, którzy mają istniejącą płatną dzierżawę.
• Oferowanie rabatu dla poszczególnych użytkowników, aktywnych użytkowników lub cen dla dzierżaw nieprodukcyjnych z niższą lub bez umowy dotyczącej poziomu usług.
• W przypadku dzierżaw korzystających z cen prostych można negocjować środowiska nieprodukcyjne w ramach umowy.

Uwaga

Ceny oparte na funkcjach nie są zwykle dobrym rozwiązaniem dla środowisk nieprodukcyjnych, chyba że oferowane funkcje są takie same jak oferowane przez środowisko produkcyjne. Dzieje się tak, ponieważ dzierżawcy zwykle chcą testować i zapewniać szkolenia na wszystkich tych samych funkcjach, które są dostępne dla nich w środowisku produkcyjnym.

Nieopłacalne modele cenowe

Nieopłacalny model cenowy kosztuje cię więcej, aby dostarczać usługę niż przychód, który zarabiasz. Na przykład możesz naliczać opłatę płaską za dzierżawę bez żadnych limitów dla usługi, ale następnie utworzyć usługę przy użyciu zasobów platformy Azure opartych na użyciu i bez limitów użycia dla poszczególnych dzierżaw. W takiej sytuacji może istnieć ryzyko nadmiernego korzystania z usługi przez dzierżawców, co sprawia, że nie będzie można ich obsługiwać.

Ogólnie rzecz biorąc, chcesz uniknąć nieopłacalnych modeli cenowych. Istnieją jednak sytuacje, w których można zdecydować się na wdrożenie nierentownego modelu cenowego, w tym:

• Bezpłatna usługa jest oferowana w celu umożliwienia wzrostu.
• Dodatkowe strumienie przychodów są udostępniane przez usługi lub funkcje dodatków.
• Hosting określonej dzierżawy zapewnia inną wartość handlową, taką jak użycie ich jako dzierżawy kotwicy na nowym rynku.

W przypadku niezamierzonego utworzenia nierentownego modelu cenowego istnieje kilka sposobów ograniczenia ryzyka związanego z nimi, w tym:

• Ogranicz korzystanie z usługi za pośrednictwem limitów użycia.
• Wymagaj użycia rezerwacji pojemności.
• Zażądaj przeniesienia dzierżawy do wyższej funkcji lub warstwy usługi.

Ryzykowne modele cenowe

Podczas implementowania modelu cenowego dla rozwiązania zwykle trzeba założyć, jak będzie on używany. Jeśli te założenia okaże się nieprawidłowe lub wzorce użycia zmieniają się w czasie, model cen może stać się nierentowny. Modele cenowe, które mogą stać się nierentowne, są nazywane ryzykownymi modelami cenowymi . Jeśli na przykład przyjmiesz model cen, który oczekuje od użytkowników samodzielnego ograniczenia kwoty używanej przez nich rozwiązania, być może zaimplementowano ryzykowny model cen.

Większość rozwiązań SaaS regularnie dodaje nowe funkcje. Zwiększa to ROV dla użytkowników, co może również prowadzić do zwiększenia ilości używanej rozwiązania. Może to spowodować, że rozwiązanie stanie się nierentowne, jeśli użycie nowych funkcji powoduje użycie, ale model cen nie uwzględnia tego.

Jeśli na przykład wprowadzisz nową funkcję przekazywania wideo do rozwiązania, która korzysta z zasobu opartego na użyciu, a wychwyt użytkownika funkcji jest wyższa niż oczekiwano, rozważ połączenie limitów użycia i cen funkcji i poziomu usług.

Limity użycia

Limity użycia umożliwiają ograniczenie użycia usługi, aby zapobiec utracie opłacalności modeli cenowych lub uniemożliwić jednej dzierżawie korzystanie z nieproporcjonalnej ilości pojemności usługi. Może to być szczególnie ważne w usługach wielodostępnych, w których jedna dzierżawa może mieć wpływ na środowisko innych dzierżaw przez nadmierne wykorzystanie zasobów.

Uwaga

Ważne jest, aby klienci wiedzieli, że stosujesz limity użycia. Jeśli zaimplementujesz limity użycia bez informowania klientów o limicie, to spowoduje to niezadowolenie klientów. Oznacza to, że ważne jest, aby zidentyfikować i zaplanować limity użycia z wyprzedzeniem. Celem powinno być zaplanowanie limitu, a następnie przekazanie limitów klientom, zanim staną się konieczne.

Limity użycia są często używane w połączeniu z cenami funkcji i poziomu usług, aby zapewnić wyższą ilość użycia w wyższych warstwach. Limity są również często używane do ochrony podstawowych składników, które spowodują wąskie gardła systemu lub problemy z wydajnością, jeśli są one nadmiernie używane.

Limity szybkości

Typowym sposobem zastosowania limitu użycia jest dodanie limitów szybkości do interfejsów API lub określonych funkcji aplikacji. Jest to również nazywane ograniczaniem przepustowości. Limity szybkości uniemożliwiają ciągłe nadmierne korzystanie. Są one często używane do ograniczania liczby wywołań do interfejsu API w określonym przedziale czasu. Na przykład interfejs API może być wywoływany tylko 20 razy na minutę i zwróci błąd HTTP 429, jeśli jest wywoływany częściej niż ten.

Niektóre sytuacje, w których często używane jest ograniczanie szybkości, obejmują następujące kwestie:

• Interfejsy API REST.
• Zadania asynchroniczne.
• Zadania, które nie są wrażliwe na czas.
• Akcje, które generują wysoki koszt wykonania.
• Generowanie raportów.

Implementowanie ograniczania szybkości może zwiększyć złożoność rozwiązania, ale usługi takie jak Azure API Management mogą ułatwić stosowanie zasad limitu szybkości.

Cykl życia modelu cenowego

Podobnie jak w przypadku każdej innej części rozwiązania modele cenowe mają cykl życia. W miarę rozwoju aplikacji w miarę upływu czasu może być konieczne zmianę modeli cen. Może to być spowodowane zmianą potrzeb klientów, wymaganiami komercyjnymi lub zmianami funkcjonalności w aplikacji. Oto niektóre typowe zmiany cyklu życia cen:

• Dodanie zupełnie nowego modelu cenowego. Na przykład dodanie modelu cen użycia do rozwiązania, które obecnie oferuje model stawek prostych.
• Wycofanie istniejącego modelu cenowego.
• Dodawanie warstwy do istniejącego modelu cenowego.
• Wycofywanie warstwy w istniejącym modelu cenowym.
• Zmiana limitów użycia funkcji w modelu cenowym.
• Dodawanie lub usuwanie funkcji z modelu cenowego funkcji i poziomu usług.
• Zmiana modelu komercyjnego z modelu biznesowego na konsumenta (B2C) na model komercyjny biznesowy (B2B). Ta zmiana wymaga zatem nowych struktur cenowych dla klientów biznesowych.

Zwykle wdrożenie wielu różnych modeli cenowych i zarządzanie nimi jest zwykle złożone. Jest to również mylące dla Twoich klientów. Dlatego lepiej zaimplementować tylko jeden lub dwa modele z niewielką liczbą warstw. Dzięki temu rozwiązanie jest bardziej dostępne i łatwiejsze do zarządzania.

Uwaga

Modele cenowe i funkcje rozliczeń powinny być testowane, najlepiej przy użyciu testów automatycznych, podobnie jak w przypadku każdej innej części systemu. Bardziej złożone modele cenowe, tym bardziej wymagane jest testowanie, a więc koszty programowania i nowych funkcji wzrosną.

Podczas zmieniania modeli cen należy wziąć pod uwagę następujące czynniki:

• Czy dzierżawcy będą chcieli przeprowadzić migrację do nowego modelu?
• Czy dzierżawcy mogą łatwo przeprowadzić migrację do nowego modelu?
• Czy nowe modele cenowe uwidacznią usługę na ryzyko? Czy na przykład usuwasz limity szybkości, które obecnie chronią krytyczne zasoby przed nadmiernym nadużywaniem?
• Czy dzierżawy mają wyraźną ścieżkę migracji do nowego modelu cenowego?
• Jak uniemożliwić dzierżawcom korzystanie ze starszych modeli cenowych, aby można było je wycofać?
• Czy dzierżawcy mogą otrzymać szok rachunków (negatywną reakcję na nieoczekiwany rachunek) po zmianie modeli cenowych?
• Czy monitorujesz wydajność i wykorzystanie usług, w przypadku nowych lub zmienionych modeli cenowych, aby zapewnić ciągłą rentowność?
• Czy możesz wyraźnie przekazać ROV dla nowych modeli cenowych do istniejących dzierżaw?

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

• Daniel Scott-Raynsford | Partner TechnologyStrateg

Inni współautorzy:

• Bohdan Cherchyk | Starszy inżynier klienta, fasttrack dla platformy Azure
• John Downs | Główny inżynier klienta, fasttrack dla platformy Azure
• Chad Kittel | Główny inżynier oprogramowania
• Paolo Salvatori | Główny inżynier klienta, fasttrack dla platformy Azure
• Arsen Vladimirskiy | Główny inżynier klienta, fasttrack dla platformy Azure

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

Zastanów się, jak zmierzysz zużycie według dzierżaw w rozwiązaniu.