Pay-per-use מחייב לפי צריכה בפועל: לפי קילוואט שעה, לפי קריאת API, לפי גיגה-בייט, לפי שעת השכרה, לפי עמוד מודפס. הלקוח לא משלם כלום כשהוא לא משתמש בשירות. ההכנסה שלך נעה עם הפעילות שלו, וברוב המקרים גם העלויות שלך נעות איתה, מה שמשמר שוליים יציבים בכל היקף.
מחשוב ענן ושיתוף רכבים הן הדוגמאות המוכרות. אתה משלם עבור הדקות או הגיגה-בייטים שבהם השתמשת בפועל.
הקסם הוא יציבות השוליים. נניח שאתה גובה 0.10 יורו לכל 1,000 קריאות API והתשתית שלך עולה 0.04 יורו לכל 1,000 קריאות. לקוח עם 2 מיליון קריאות בחודש משלם 200 יורו ועולה לך 80 יורו, ונשארים 120 יורו. לקוח עם 200,000 קריאות משלם 20 יורו ועולה 8 יורו, ונשארים 12 יורו. בשני המקרים אתה שומר 60 אחוז. תחת תעריף קבוע של 150 יורו בחודש, הלקוח הראשון היה מייצר הפסד והשני רווח גדול.
החולשה היא חוסר ודאות. אין לך רצפת הכנסה. אם ללקוחות שלך יש רבעון שקט, גם לך יהיה רבעון שקט, ושכר הדירה נשאר זהה. ספקים רבים לכן משלבים מודלים: תעריף בסיס קטן בתוספת שימוש, או התחייבות חודשית מינימלית עם השימוש נספר כנגדה.
ללקוחות יש פחד הפוך, חשבונית שהם לא יכולים לחזות. הקטן אותו עם תקרת הוצאה, התראה ב-80 אחוז מהמגבלה המוסכמת, ותצוגת שימוש חיה. חשבון בלתי צפוי אחד בעל ארבע ספרות מסיים מערכת יחסים מהר יותר מהעלאת מחיר.
מדידה חייבת להיות מדויקת וגלויה. אם לקוח לא יכול לשחזר איך חושבה החשבונית, הוא יערער עליה. תעד כל יחידה, הצג את היומן, והגדר בחוזה מה נחשב ליחידה אחת: קריאת API כושלת, הזמנה שבוטלה, שעה חלקית.
Pay-per-use מופיע בתוכניות עסקיות שנוצרות כאחת מתבניות ההכנסה המוערכות, בדרך כלל מול התעריף הקבוע. הבחירה תלויה בשאלה האם העלויות שלך עולות עם השימוש.
