निर्णय का आधार
सेवा चालू रखने, प्रति ग्राहक गतिविधि और असाधारण सहायता के खर्च अलग करें। होस्टिंग का एक अंक संग्रहण, ईमेल, निगरानी, बैकअप, एकीकरण और समस्या सुलझाने वाले लोगों को छिपाता है।
एक व्यावहारिक उदाहरण
उदाहरण मॉडल: मासिक आधार 200 गणना इकाइयाँ, सक्रिय ग्राहक पर 4 और सहायता 12 घंटे, दर 30। 50 ग्राहकों पर कुल 760 इकाइयाँ। ये बनाए हुए इनपुट हैं, प्रदाता दर नहीं। एक बार में एक मान बदलें।
गणना के साथ मान्यताएँ रखें
हर लागत में इकाई, मात्रा, दर, स्रोत और मालिक लिखें। आधार महीने, संदेश संख्या और सहायता समय है। सब “सर्वर” न बनें। यहाँ 50 सक्रिय कंपनियाँ हैं। सहायता घंटे और ऑनबोर्डिंग का अर्थ दें। सत्यापित कीमत न हो तो दर अज्ञात और सूत्र रखें। प्रमाण तथा अनुमान अलग हों।
ठोस बदलाव जाँचें
760 इकाइयों से सहायता 12 के बजाय 24 घंटे हो तो 1,120। समान सहायता पर ग्राहक 50 से 100 हों तो 960। काल्पनिक हिसाब है, विकास पूर्वानुमान नहीं। बड़ी फ़ाइल आयात, retry उछाल और साथ कई ग्राहक जोड़ें। अनियंत्रित खर्च रोकने वाला नियम लिखें।
जिम्मेदारी तय करें
अलर्ट पाने वाला जाने क्या सुरक्षित रोका जाए। प्रति ग्राहक, काम या सेवा सीमा और संदेश तय करें। उपयोग, बिल और अनुमान की समीक्षा बाँटें। कुल छोटा दिखाने को जरूरी बैकअप या निगरानी न हटाएँ। टिकाऊ समय पर असली शुल्क और श्रम मिलाएँ। बजट अंतर समझाता है, स्थिर बिल का वादा नहीं।
विकल्पों का आकलन
स्थिर ढाँचा अनुमान आसान करता है; उपयोग आधारित सेवाएँ गतिविधि के साथ खर्च और उछाल लाती हैं। खुद होस्टिंग कुछ शुल्क को संचालन काम से बदलती है। घटनाएँ और अपडेट शामिल करें।
योजना कहाँ टूटती है
अधिकांश निष्क्रिय हों तो सारे खातों से लागत न बाँटें। असली कारण लें: संगठन, फ़ाइल, संदेश या कार्य। विकास अलग रखें और कर तथा शुल्क स्पष्ट करें।
काम शुरू कराने से पहले
कौन प्रति इकाई बिल करता है? अनियंत्रित कार्य कैसे रुकेगा? नए ग्राहक को कितनी मदद चाहिए? ये मान्यताएँ SaaS डिजाइन में लाएँ।