Pay-per-use oznacza naliczanie opłat za rzeczywiste zużycie: za kilowatogodzinę, za wywołanie API, za gigabajt, za godzinę wynajmu, za wydrukowaną stronę. Klient nie płaci nic, gdy nie korzysta z usługi. Twój przychód porusza się razem z jego aktywnością, a zwykle razem z nią poruszają się też twoje koszty, co utrzymuje stabilną marżę przy dowolnym wolumenie.
Chmura obliczeniowa i car sharing to znane przykłady. Płacisz za minuty albo gigabajty, które faktycznie zużyłeś.
Atutem jest stabilność marży. Załóżmy, że naliczasz 0,10 euro za 1 000 wywołań API, a twoja infrastruktura kosztuje 0,04 euro za 1 000 wywołań. Klient z 2 milionami wywołań miesięcznie płaci 200 euro i kosztuje cię 80 euro, co zostawia 120 euro. Klient z 200 000 wywołań płaci 20 euro i kosztuje 8 euro, co zostawia 12 euro. W obu przypadkach zatrzymujesz 60 procent. Przy stawce ryczałtowej 150 euro miesięcznie pierwszy klient generowałby stratę, a drugi duży zysk.
Słabością jest przewidywalność. Nie masz dolnego progu przychodu. Jeśli twoi klienci mają spokojny kwartał, ty też masz spokojny kwartał, a czynsz zostaje taki sam. Wielu dostawców łączy więc modele: niewielką opłatę bazową plus zużycie, albo minimalne miesięczne zobowiązanie, od którego odlicza się zużycie.
Klienci mają przeciwną obawę, fakturę, której nie potrafią przewidzieć. Zmniejsz ją limitem wydatków, alertem przy 80 procentach uzgodnionego limitu i podglądem zużycia na żywo. Jeden nieoczekiwany rachunek na kilka tysięcy kończy relację szybciej niż podwyżka ceny.
Pomiar musi być dokładny i widoczny. Jeśli klient nie może odtworzyć, jak obliczono fakturę, zakwestionuje ją. Loguj każdą jednostkę, pokazuj log i zdefiniuj w umowie, co liczy się jako jedna jednostka: nieudane wywołanie API, anulowaną rezerwację, niepełną godzinę.
Pay-per-use pojawia się w wygenerowanych biznesplanach jako jeden z ocenianych wzorców przychodów, zwykle zestawiony ze stawką ryczałtową. Wybór zależy od tego, czy twoje koszty rosną wraz z zużyciem.
