Modele cen dla rozwiązania wielodostępnego

Dobry model cenowy zapewnia, że w miarę wzrostu liczby najemców i dodawaniu nowych funkcji pozostaje opłacalny. Ważnym zagadnieniem podczas opracowywania komercyjnego rozwiązania wielodostępnego jest projektowanie modeli cenowych dla produktu. W tym artykule udostępniamy wskazówki dla osób podejmujących decyzje techniczne dotyczące modeli cenowych, które warto rozważyć, oraz związanych z tym kompromisów.

Zrozumienie rentowności

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 może zwiększyć ROV dla klientów, ale może również zwiększyć złożoność architektoniczną i komercyjną rozwiązania, a tym samym zwiększyć swoje COGS.

Podczas opracowywania modeli cenowych dla rozwiązania należy wziąć pod uwagę następujące pytania:

• Czy COGS będzie wyższy niż zysk uzyskany z rozwiązania? Nieopłacalny model cenowy może działać przez pewien czas, ale nie jest możliwy do utrzymania w dłuższej perspektywie.
• Czy usługa COGS może ulec zmianie w czasie na podstawie wzrostu użytkowników lub zmian w wzorcach użycia? Modelowanie coGS i rozwój, aby zrozumieć, czy COGS sprawia, że twoje rozwiązanie jest nieopłacalne w miarę rozwoju.
• 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, ważne jest określenie sposobu mierzenia wywołań interfejsu API wykonanych przez każdego klienta.
• Czy model cen nie zniechęca do korzystania z produktu? Unikaj sytuacji, w których model cenowy zmniejsza potencjalną wartość, którą klient może osiągnąć z produktu, na przykład poprzez bardzo kosztowne działania. Ta struktura tworzy niedopasowane zachęty i może prowadzić do mieszanego sygnału dla klientów.
• Jeśli klient nadmiernie korzysta z rozwiązania, czy oznacza to, że nie jesteś już rentowny? Jeśli martwisz się o niewłaściwe użycie, umieść bariery zabezpieczające, takie jak limity szybkości.

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ą potrzebować uzyskiwać dostęp do rozwiązania tylko w godzinach pracy lub może być tylko niewielki odsetek użytkowników generujących duży ruch. 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 każdego najemcę. Czy można ustawić limity przydziału magazynu lub wymusić okres przechowywania danych?

• Izolacja najemcy. Używany model dzierżawy ma wpływ na poziom izolacji między najemcami. 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 najemcy wpłynie na twój COGS i ogólną wydajność?

  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 najemcy. Na przykład rozwiązania z wysoką wskaźnikiem odchodzenia klientów lub usługi, które wymagają większego nakładu pracy przy wdrożeniu, mogą charakteryzować się niższą rentownością, szczególnie jeśli są wyceniane przy użyciu modelu opartego na konsumpcji.

• 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 dotyczące poziomu usług i wszelkich zobowiązań, dzięki czemu można odpowiednio zaplanować modele cenowe. Rozważ użycie różnych warstw cenowych dla klientów z różnymi wymaganiami dotyczącymi poziomu usług.

Typowe modele cenowe

Istnieje wiele typowych modeli cenowych, które są często używane z rozwiązaniami dla wielu klientów. 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.

Podczas wybierania modelu cenowego zastanów się, co ma sens z perspektywy klientów. Jeśli model cenowy jest zbyt złożony lub abstrakcyjny, może mieć trudności z oszacowaniem kosztów. Staraj się powiązać ceny z modelami biznesowymi najemców.

Ceny oparte na zużyciu

Model zużycia jest czasami określany jako płać za użycie lub PAYG. 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 według najemcy. 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 od klientów na podstawie liczby osób korzystających z usługi:

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: Gdy rozliczasz klientów za każdego użytkownika, łatwo jest obliczyć i prognozować przepływ 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, jak wdrożenie usługi, co sprawia, że ten model jest skalowalny w miarę rozwoju.

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 obsługa użytkowników intensywnie korzystających z rozwiązania może kosztować więcej niż obsługa użytkowników korzystających w mniejszym stopniu. Ponadto rzeczywisty zwrot wartości (ROV) dla rozwiązania nie jest odzwierciedlany przez rzeczywistą liczbę zakupionych licencji użytkownika. Jeśli Twoje rozwiązanie obejmuje możliwości, które nie są bezpośrednio związane z użytkownikami, takie jak wysyłanie wiadomości e-mail do dużej liczby adresatów, przychody mogą nie wzrosnąć wraz ze wzrostem kosztów sprzedanych towarów (COGS).

Ceny za aktywnego użytkownika

Ten model jest podobny do cen poszczególnych użytkowników, ale zamiast wymagać zobowiązania z góry od klienta w sprawie liczby oczekiwanych użytkowników, klient jest naliczany tylko za użytkowników, którzy rzeczywiście logowali się do rozwiązania i korzystali z niego w danym okresie:

Można to zmierzyć w dowolnym okresie, który 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 do modelu cenowego za użytkownika, modele cenowe za aktywnego użytkownika mają mniej przewidywalny strumień przychodów. Ponadto ceny promocyjne nie są skutecznym sposobem stymulowania wzrostu.

Ceny za jednostkę

W wielu systemach liczba użytkowników nie jest elementem, który ma największy wpływ na całkowity koszt własny sprzedaży. 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 sklepom stacjonarnym, model cenowy na sklep może być odpowiedni niezależnie od liczby użytkowników w każdym sklepie.

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 na jednostkę pomaga zapewnić utrzymanie rentowności, ponieważ można określić koszt własny sprzedaży (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ć, że rentowność jest niższa, na przykład jeśli niektóre urządzenia lub sklepy są znacznie bardziej intensywnymi 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ć trzy miesięczne ceny zryczałtowe lub jednostkowe, dwie podstawowe oferty z podzbiorem dostępnych funkcji, a trzeci przedstawiający kompleksowy zestaw funkcji rozwiązania:

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 sprzedaży dodatkowych funkcji klientom lub zwiększoną odporność 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 również wziąć pod uwagę koszty operacyjne związane z zarządzaniem bezpłatnymi dzierżawami. Może być konieczne upewnienie się, że nieaktywni dzierżawcy są odłączani lub usuwani, a zwłaszcza w przypadku darmowych dzierżawców musisz mieć jasną politykę dotyczącą zatrzymywania danych. W przypadku przenoszenia użytkownika do płatnej warstwy może być konieczne migracja danych lub obciążeń użytkownika między usługami Azure w celu uzyskania wyższych SLA. Ważne będzie również zachowanie danych i konfiguracji dzierżawcy podczas przechodzenia do warstwy płatnej.

Czynniki ryzyka: należy zapewnić wystarczająco wysoką wartość ROV dla najemców, aby rozważyli przejście na płatną wersję. 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.

Wycena kosztu sprzedanych towarów

Możesz zdecydować się wycenić swoje rozwiązanie tak, aby każdy najemca płacił tylko koszt działania tego fragmentu komponentów, które stanowią jego część rozwiązania, bez dodatkowej marży zysku. Ten model — nazywany cennikiem przekazywania lub opłatą zwrotną — jest czasami używany w przypadku rozwiązań wielodostępnych, które nie mają służyć jako centrum zysków.

Model kosztu sprzedanych towarów jest odpowiednim rozwiązaniem dla wewnętrznie zorientowanych rozwiązań wielodostępnych. Każda jednostka organizacyjna odpowiada klientowi, a koszty zasobów 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 opiera się na dokładnych pomiarach użycia i podziale tego użycia przez najemcę. Ś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ępnościowych wewnętrznych dzierżawcy mogą akceptować przybliżone szacunki kosztów i mieć bardziej złagodzone wymagania dotyczące audytu 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 ryczałtowy

W tym modelu pobierasz od najemcy zryczałtowaną opłatę za dostęp do rozwiązania przez określony czas. 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.

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

Korzyści: Stała opłata jest łatwa do sprzedaży, a klienci łatwo ją rozumieją i mogą zaplanować budżet.

Złożoność i koszt operacyjny: Modele cen ryczałtowych mogą być łatwe do zaimplementowania, ponieważ rozliczanie klientów nie wymaga żadnych pomiarów ani śledzenia zużycia. Jednak, chociaż nie jest to konieczne, zaleca się mierzenie zużycia poszczególnych najemców, aby upewnić się, że dokładnie mierzysz COGS i utrzymujesz swoją rentowność.

Ryzyko: jeśli masz najemców, którzy intensywnie korzystają z Twojego rozwiązania, łatwo jest, aby ten model cenowy stał się nierentowny.

Cennik rabatu

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

Uwaga

Zwykle wycena rabatowa nie wymaga kwestii architektonicznych, poza dodaniem obsługi bardziej złożonej struktury fakturowania. Kompletna dyskusja na temat korzyści komercyjnych z rabatami wykracza poza zakres tego artykułu.

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 intensywnie korzystają z twojego rozwiązania, mogą czuć, że powinni uzyskiwać rabat, korzystając z efektów skali.
• Rozbieżne ceny. Gdy klienci kupują lub zużywają więcej jednostek, zmniejszasz koszt jednostkowy. Jest to bardziej atrakcyjne komercyjnie dla klientów.
• Cennik progowy Gdy klienci kupują więcej, zmniejszasz koszt jednostkowy. Jednak należy to zrobić w ramach zmian etapowych 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ę. Takie podejście może być bardziej opłacalne niż ceny dygresywne.

Na poniższym diagramie przedstawiono te wzorce cen.

Rabaty dla ś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, które obsługują obciążenia nieprodukcyjne.

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 pakiet freemium, tak jak możesz już robić dla 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ę.
• Oferuj rabat na użytkownika, użytkownika aktywnego lub jednostkę cenową dla dzierżaw nieprodukcyjnych, z niższą lub bez umowy serwisowej.
• W przypadku najemców korzystających ze stawek ryczałtowych, środowiska nieprodukcyjne mogą być negocjowane 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ć stałą opłatę od dzierżawcy bez żadnych limitów dla swojej usługi, ale następnie utworzyć usługę wykorzystując zasoby Azure oparte na zużyciu i bez limitów użycia na dzierżawcę. W takiej sytuacji może istnieć ryzyko nadmiernego korzystania z twojej usługi przez najemców, co może sprawić, że będzie to nieopłacalne, aby 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.
• Zarządzanie określonym najemcą dostarcza dodatkowej wartości handlowej, na przykład poprzez wykorzystanie go jako głównego najemcy 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 najemcy do wyższego poziomu funkcji lub usługi. Rozważ udostępnienie nowych funkcji wyłącznie w rentownej warstwie usług, aby zachęcić dzierżawców do przeniesienia.

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 wykorzystanie funkcji przez użytkownika jest wyższe niż oczekiwano, rozważ, czy można ograniczyć ryzyko cenowe przy użyciu kombinacji limitów użycia i cen funkcji i poziomu usług.

Limity użycia

Limity użycia umożliwiają ograniczenie korzystania z usługi, aby zapobiec, by modele cenowe stały się nieopłacalne, lub aby uniemożliwić jednemu użytkownikowi korzystanie z nieproporcjonalnej ilości zasobów usługi. Może to być szczególnie ważne w usługach wielodostępnych, w których jeden użytkownik może wpłynąć na doświadczenie innych użytkowników przez nadmierne zużycie 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 mogą powodować wąskie gardła systemu lub problemy z wydajnością, jeśli są nadmiernie konsumowane.

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.

Następujące scenariusze często obejmują limity szybkości:

• 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 cenowego opartego na zużyciu do rozwiązania, które obecnie oferuje model stałej stawki.
• 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 biznesowego typu B2C na model biznesowy typu 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 koszt programowania i złożoności operacyjnej wzrośnie.

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

• Konsekwencje umowne. Jeśli dzierżawcy podpisali kontrakty na podstawie określonego modelu cenowego, upewnij się, że nie naruszasz tych umów przypadkowo.
• Atrakcyjność. Jasno przekaż ROV dla nowych modeli cenowych do istniejących dzierżaw. Upewnij się, że nowy model jest wystarczająco atrakcyjny, aby dzierżawcy chcieli przeprowadzić migrację do nowego modelu. Zdecyduj, w jaki sposób zniechęcisz dzierżawców do korzystania ze starszych modeli cenowych, które planujesz wycofać.
• Oś czasu. Daj najemcom dużo czasu na wszelkie zmiany, aby mogli się przygotować.
• Proces migracji. Ułatw migrację najemców do nowego modelu.
• Zmniejszanie ryzyka cenowego. Oceń każdy nowy model cen, aby dowiedzieć się, czy jest to ryzykowne. Należy na przykład zachować ostrożność podczas usuwania limitów szybkości, które obecnie chronią krytyczne zasoby przed nadmiernym nadużywaniem. W trakcie zmiany monitoruj wydajność i wykorzystanie usług, aby zapewnić ciągłą satysfakcję i rentowność.
• Zmniejsz ryzyko szoku rachunkowego. Zmiany w modelu cenowym mogą spowodować szok związany z rachunkiem, co jest negatywną reakcją na nieoczekiwany rachunek. Jasno i aktywnie komunikuj zmiany w modelu cenowym. Oblicz lub zasymuluj rachunek każdego lokatora przed zmianą i po zmianie, aby można było wykryć sytuacje, w których lokator zapłaci znacznie więcej po zmianie.

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 | Strateg ds. technologii partnerskich

Inni współautorzy:

• Bohdan Cherchyk | Starszy inżynier klienta, fasttrack dla platformy Azure
• John Downs | Główny inżynier oprogramowania, wzorce i praktyki platformy Azure
• Chad Kittel | Główny inżynier oprogramowania, wzorce i praktyki platformy Azure
• 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 przez najemców w swoim rozwiązaniu.