सब्सक्रिप्शन बनाम उपयोग-आधारित बिलिंग: पहले दिन से क्या स्टोर करें

क्यों प्राइसिंग मॉडल के लिए डेटा प्लान ज़रूरी है

प्राइसिंग सिर्फ आपकी वेबसाइट का एक पन्ना नहीं है। यह तय करता है कि आपको क्या रिकॉर्ड करना है, आप कैसे रिपोर्ट करेंगे, और क्या आप महीनों बाद किसी चार्ज की व्याख्या कर पाएंगे। जब आप सब्सक्रिप्शन बनाम उपयोग-आधारित बिलिंग चुनते हैं, तो आप अपने बिलिंग डेटा की आकृति भी चुन रहे होते हैं।

एक साधारण सब्सक्रिप्शन कुछ तथ्यों से अक्सर गणना की जा सकती है: प्लान, बिलिंग अवधि, स्टार्ट डेट, और छूट। उपयोग-आधारित प्राइसिंग में और ज़रुरत होती है: क्या उपयोग हुआ, कब हुआ, किस ग्राहक का था, और वह उपयोग पैसों में कैसे बदलता है। उन रिकॉर्ड्स के बिना आप इनवॉइस भेज सकते हैं, पर आप उनका बचाव नहीं कर पाएंगे।

बाद में उपयोग जोड़ने की बिना योजना से आम तौर पर तीन जगहों पर टूटता है:

• आपके पास विश्वसनीय उपयोग इतिहास नहीं होता, इसलिए ग्राहक चार्ज पर विवाद करते हैं।
• आपकी एनालिटिक्स अंदाज़ा बन जाती है क्योंकि टीमें "उपयोग" को अलग परिभाषित करती हैं।
• फाइनेंस इनवॉइसेस ऑडिट नहीं कर सकता क्योंकि रॉ इनपुट्स गायब हैं या ओवरराइट हो गए हैं।

लक्ष्य नीरस परंतु आवश्यक है: हर बार वही इनवॉइस वही तरीके से गिनना। इसका मतलब है कि आप संग्रहीत तथ्यों (प्लान टर्म्स, मीटर नियम, उपयोग इवेंट्स, और उस समय लागू प्राइसिंग वर्शन) से गणना को रीप्ले कर सकते हैं।

"मॉडलिंग व्यू" का मतलब बस बिलिंग को उन बिल्डिंग ब्लॉक्स के रूप में वर्णित करना है जो साथ आते हैं, भले ही आप इंजीनियर न हों। एक टीम चैट उत्पाद की कल्पना करें:

• सब्सक्रिप्शन: $99 प्रति वर्कस्पेस प्रति माह
• उपयोग: 50,000 संदेशों के बाद प्रति संदेश $0.01

इसे बाद में सपोर्ट करने के लिए आपका डेटा यह जवाब दे सके: कौन सा वर्कस्पेस, कौन सा महीना, कितने संदेश, क्या शामिल था, और कौन से प्राइस नियम सक्रिय थे।

सब्सक्रिप्शन बनाम उपयोग: व्यवहार में कैसे अलग हैं

सब्सक्रिप्शन एक्सेस के लिए चार्ज करता है। उपयोग-आधारित बिलिंग खपत के लिए चार्ज करती है। अपग्रेड, डाउनग्रेड, प्रोरेशन और वास्तविक दुनिया के एज़ केस आने पर वे बहुत अलग व्यवहार करते हैं।

सब्सक्रिप्शन के साथ मुख्य प्रश्न यह है: "क्या ग्राहक को इस समय उत्पाद उपयोग करने का अधिकार था?" आप मुख्य रूप से प्लान, सीट काउंट, बिलिंग अवधि, और क्या इनवॉइस का भुगतान हुआ, यह ट्रैक करते हैं। उपयोग का महत्व रहता है, पर अक्सर यह लाइन आइटम के रूप में नहीं बल्कि लिमिट्स के रूप में दिखता है।

उपयोग-आधारित बिलिंग के साथ मुख्य प्रश्न यह बनता है: "ठीक-ठीक क्या हुआ, और कब?" आपको विश्वसनीय मीटरिंग, स्पष्ट नियम कि कब उपयोग गिना जाता है, और हर चार्ज को बाद में समझाने का तरीका चाहिए। भले ही आपकी UI एक संख्या दिखाए (जैसे "1,243 API कॉल्स"), पीछे घटनाओं का सेट होता है जिसे संगत और ऑडिटेबल होना चाहिए।

कई B2B SaaS टीमें हाइब्रिड प्राइसिंग चुनती हैं: बेस फ़ी जो एक बंडल को कवर करती है, साथ में ओवरेज।

सामान्य हाइब्रिड पैटर्न

अधिकांश हाइब्रिड मॉडल कुछ परिचित रूपों में आते हैं:

• बेस प्लेटफ़ॉर्म फ़ी प्लस प्रति-सीट फ़ी
• बेस फ़ी प्लस शामिल यूनिट्स (संदेश, टास्क, API कॉल्स) फिर ओवरेज रेट
• टायर्ड प्लान प्लस उपयोग एड-ऑन (सिर्फ सक्षम होने पर चार्ज होता है)
• न्यूनतम कमिट के साथ उपयोग क्रेडिट ड्रॉडाउन

अनुमाननीयता मदद करती है जब ग्राहकों को बजट स्वीकृति चाहिए और स्थिर मासिक खर्च चाहिए। पे-एज़-यू-गो बेहतर है जब वैल्यू एक्टिविटी के साथ स्केल होती है (उदाहरण के लिए, "प्रति प्रॉसेस्ड इनवॉइस"), या जब ग्राहक ट्रायल पर हैं और कम रिस्क चाहते हैं।

योजना परिवर्तन निश्चित हैं। मूल्य, बंडल और पैकेजिंग बदलेंगे। बिलिंग को इस तरह डिज़ाइन करें कि आप नया मीटर जोड़ सकें, नई टियर पेश कर सकें, या "शामिल" का मतलब बदल सकें बिना इतिहास को फिर से लिखे। एक व्यावहारिक नियम: चार्ज के समय ग्राहक के प्लान और प्राइसिंग टर्म्स को उसी रूप में स्टोर करें, न कि केवल आज जो है।

ऐसे मीटर परिभाषित करें जिन्हें आप विश्वसनीय रूप से माप सकें

एक मीटर वह सटीक चीज़ है जिसके लिए आप चार्ज करते हैं, इसे इतनी स्पष्टता से लिखा होना चाहिए कि दो लोग गिनें तो वही संख्या मिले। इसमें तीन भाग होते हैं: इवेंट (क्या हुआ), यूनिट (आप क्या गिनते हैं), और टाइमिंग (कब गिना जाता है)।

अधिकांश विवाद यहीं से शुरू होते हैं। एक पक्ष सोचता है कि वे परिणाम के लिए भुगतान कर रहे हैं, जबकि दूसरा पक्ष सटीक गतिविधि चार्ज कर रहा है।

मीटर को अस्पष्ट न रखें

ऐसे मीटर चुनें जो वास्तविक प्रोडक्ट एक्शन्स से मैप हों और स्वचालित रूप से रिकॉर्ड हो सकें। सामान्य उदाहरण:

• सीट्स (सक्रिय उपयोगकर्ता जो लॉग इन कर सकते हैं)
• API कॉल्स (सफल अनुरोध, या सभी अनुरोध)
• स्टोरेज (एक पॉइंट इन टाइम पर GB, या अवधि के औसत के रूप में)
• संदेश (भेजे गए, डिलीवर हुए, या खोले गए)
• कंप्यूट मिनट्स (एक जॉब कितनी देर चला)

फिर यह परिभाषित करें कि क्या गिना जाएगा और क्या नहीं। यदि आप प्रति API कॉल बिल करते हैं, तो तय करें कि retries गिने जाएंगे या नहीं, 4xx/5xx रिस्पॉन्स गिने जाएंगे या नहीं, और आपकी अपनी इंटीग्रेशन्स द्वारा किए गए इंटरनल कॉल्स गिने जाएँगे या नहीं।

टाइमिंग यूनिट जितनी मायने रखती है उतनी ही यूनिट। सीट्स अक्सर बिलिंग अवधि के लिए एक पॉइंट-इन-टाइम स्नैपशॉट के रूप में बेहतर काम करते हैं। API कॉल्स आमतौर पर विंडो के भीतर जोड़े जाते हैं। स्टोरेज जटिल है: ग्राहक आम तौर पर "आपने कितना स्टोर किया" के लिए भुगतान करना चाहते हैं, जो अक्सर अवधि के औसत का अर्थ होता है, न कि पीक।

स्कोप भी तय करें: प्रति अकाउंट, या प्रति वर्कस्पेस/प्रोजेक्ट। एक सरल नियम: यदि टीमों को अलग से बिल किया जा सकता है, तो मीटर प्रति वर्कस्पेस होने चाहिए।

लिमिट्स, टियर और एंटाइटलमेंट्स

एंटाइटलमेंट नियम हैं जो बताते हैं कि ग्राहक ने जो खरीदा है उसके कारण वे क्या करने के लिए पात्र हैं। वे सवालों के जवाब देते हैं: वे कितने उपयोगकर्ता जोड़ सकते हैं? कौन से फीचर सक्षम हैं? प्रति माह कितना वॉल्यूम अनुमति है? एंटाइटलमेंट एक्सेस और बिलिंग के बीच आते हैं: वे यह तय करते हैं कि उत्पाद क्या अनुमति देता है, जबकि मेटरिंग रिकॉर्ड करती है कि वास्तव में क्या हुआ।

एंटाइटलमेंट को मेटरिंग लॉजिक से अलग रखें। एंटाइटलमेंट पढ़ने योग्य और स्थिर होने चाहिए (प्लान, एड-ऑन, कॉन्ट्रैक्ट शर्तें)। मेटरिंग उत्पाद के साथ विकसित होगी (नए इवेंट्स, नए मीटर), और आप नहीं चाहेंगे कि हर मीटर परिवर्तन एक्सेस को तोड़ दे।

हार्ड लिमिट्स, सॉफ्ट लिमिट्स, और ओवरएज बिलिंग UI में एक जैसे दिख सकते हैं, पर व्यवहार में वे अलग होते हैं:

• हार्ड लिमिट कैप के बाद क्रिया को ब्लॉक कर देता है।
• सॉफ्ट लिमिट क्रिया की अनुमति देता है पर चेतावनी देता है और फॉलो-अप के लिए फ्लैग करता है।
• ओवरएज बिलिंग अतिरिक्त उपयोग की अनुमति देती है और उसके लिए चार्ज करती है।
• ग्रेस पीरियड अस्थायी रूप से हार्ड लिमिट को सॉफ्ट लिमिट जैसा बनाता है।
• ट्रायल्स और फ्री टीयर एंटाइटलमेंट लागू करते हैं, पर प्राइसिंग अलग होती है (अक्सर शून्य) जब तक कोई तिथि या थ्रेशहोल्ड न आ जाए।

पहले तय कर लें कि किसी लिमिट के पार जाने पर क्या होता है। उदाहरण: "स्टार्टर" टियर में 5 सीट्स और प्रति माह 10,000 API कॉल्स शामिल हैं। यदि वे 6ठा यूज़र इनवाइट करते हैं, तो क्या आप उसे ब्लॉक करेंगे, अतिरिक्त सीट पर चार्ज शुरू करेंगे, या 7 दिनों के लिए ग्रेस देंगे? हर विकल्प के लिए एक नियम होना चाहिए जिसे आप इनवॉइस और सपोर्ट लॉग में दिखा सकें।

एंटाइटलमेंट्स को टाइम-बाउंड रिकॉर्ड के रूप में स्टोर करें: ग्राहक, प्लान या एड-ऑन, स्टार्ट और एंड टाइमस्टैम्प, लिमिट मान, और प्रवर्तन मोड (हार्ड, सॉफ्ट, ओवरएज)। इससे एक्सेस निर्णय और बिलिंग निर्णय संगत रहते हैं।

ऑडिटेबल इनवॉइस और बिलिंग पीरियड्स

एक इनवॉइस सिर्फ PDF नहीं है। यह एक ऑडिट ट्रेल है जो बताती है: किसे बिल किया गया, किस चीज़ के लिए, किन तारीखों के लिए, और किन नियमों के तहत। यदि आप प्राइसिंग बदलते हैं, तो भी आपको पुराने इनवॉइस ठीक वैसी ही रीबिल्ड करने लायक होना चाहिए।

कुछ कोर रिकॉर्ड्स से शुरू करें: Customer, Subscription (या Contract), Billing Period, और Invoice विथ Line Items। प्रत्येक लाइन आइटम को उसकी सोर्स की ओर पॉइंट करना चाहिए: प्लान फी, उपयोग सारांश, या एक-बार का चार्ज। यही लिंक बिलिंग को समझाने लायक बनाता है जब कोई चार्ज विवादित हो।

बिलिंग पीरियड्स को एक एंकर और टाइमज़ोन चाहिए। "मंथली" पर्याप्त नहीं है। साइकिल एंकर डेट (उदाहरण के लिए 15वाँ दिन 00:00) और उस टाइमज़ोन को स्टोर करें जिसका उपयोग पीरियड काटने में हुआ। इसे संगत रखें नहीं तो DST के आसपास ऑफ-बाय-वन-डे शिफ्ट होंगे।

ऑडिट योग्य इनवॉइस आमतौर पर इन्हें शामिल करते हैं:

• हर इनवॉइस और लाइन आइटम पर period_start और period_end
• उपयोग किए गए प्राइसिंग वर्शन (प्लान/प्राइस IDs)
• अपरिवर्तनीय टोटल्स: subtotal, tax, discounts, amount_due, currency
• किसी भी उपयोग-आधारित लाइन आइटम के लिए सटीक उपयोग विंडो
• जहां लागू हो वहाँ बाहरी पेमेंट रेफरेंस (प्रोसेसर चार्ज ID)

राजस्व मान्यता चार्ज करने से संबंधित पर अलग होती है। प्रीपेड सब्सक्रिप्शन फी आम तौर पर सर्विस पीरियड के ऊपर मान्यता पाती है, जबकि उपयोग अक्सर प्रदान किए जाने पर मान्यता होती है। कम से कम इतना डेट स्टोर करें कि बाद में यह सपोर्ट कर सके।

क्रेडिट नोट्स, रिफंड और समायोजन को प्रथम श्रेणी के रिकॉर्ड की तरह व्यवहार करें, कभी पुराने इनवॉइस को एडिट के रूप में नहीं बदलें। यदि ग्राहक मिड-साइकिल अपग्रेड करता है, तो एक समायोजन लाइन या क्रेडिट नोट बनायें जो मूल इनवॉइस का संदर्भ दे और उपयोग की गई प्रोरेशन नीति बताए।

इनवॉइस जनरेशन और पेमेंट प्रयासों के लिए इडेम्पोटेंसी कीज़ मायने रखती हैं। यदि कोई जॉब दो बार चलता है, तो आप एक ही इनवॉइस, एक ही चार्ज और एक स्पष्ट लॉग चाहते हैं।

प्रोरेशन और मिड-साइकिल परिवर्तन

मिड-साइकिल परिवर्तन वे जगह हैं जहाँ बिलिंग विवाद शुरू होते हैं। यदि किसी ने 20 तारीख को अपग्रेड किया, फिर एक सप्ताह के लिए पॉज़ किया, फिर कैंसिल किया, तो आपको ऐसे नियम चाहिए जो उन कार्रवाइयों को उन संख्याओं में बदल दें जो इनवॉइस पर समझ में आती हों।

निर्णय लें कि आप कौन से परिवर्तन अनुमति देते हैं और कब वे प्रभावी होंगे। कई टीमें अपग्रेड तुरंत लागू करती हैं ताकि ग्राहक तुरंत वैल्यू पाएं, पर डाउनग्रेड रिन्यूअल पर लागू करती हैं ताकि पेचीदा रिफंड से बचा जा सके।

एक प्रोरेशन नीति चुनें जिसे आप समझा सकें

प्रोरेशन डेली, आवर्सिक, या बिलकुल नहीं भी हो सकता। जितना अधिक आप सटीक होते हैं, उतने ज़्यादा टाइमस्टैम्प, राउंडिंग नियम, और किनारे के मामले (edge cases) आपको स्टोर और टेस्ट करने होंगे।

नीति विकल्प जल्दी ठोस कर दें:

• अपग्रेड्स को तुरंत प्रोरटे करें, डाउनग्रेड्स को रिन्यूअल पर टालें
• डेली प्रोरेशन का उपयोग करें (आवर्सिक से सरल और आम तौर पर काफी निष्पक्ष)
• राउंडिंग नियम पर निर्णय लें (उदाहरण के लिए, निकट की सेंट तक ऊपर राउंड करें)
• पॉज़ कैसे काम करते हैं तय करें (बचे हुए समय का क्रेडिट वापस करें, या अवधि बढ़ाएं)
• कैंसिलेशन के लिए स्पष्ट रिफंड नीति सेट करें (पूर्ण, आंशिक, या कोई नहीं)

प्रोरेशन को इनवॉइस लाइन आइटम के रूप में मॉडल करें

छिपा हुआ गणित न रखें। प्रोरेशन को इनवॉइस पर स्पष्ट समायोजन के रूप में प्रतिनिधित्व करें, जैसे नए प्लान पर शेष समय के लिए डेबिट और पुराने प्लान पर अनउपयोग किए गए समय के लिए क्रेडिट। प्रत्येक लाइन आइटम को उस सटीक परिवर्तन-इवेंट (change_id) की ओर इशारा करना चाहिए जिसने उसे उत्पन्न किया और प्रोरेशन विंडो (start_at, end_at), मात्रा/टाइम बेसिस, और टेक्स कैटेगरी शामिल होनी चाहिए।

उपयोग मीटर एक और निर्णय जोड़ते हैं: जब प्लान बदलता है, तो क्या मीटर रीसेट होते हैं, जारी रहते हैं, या खंडों में विभाजित होते हैं? एक सरल, ऑडिटेबल तरीका यह है कि उपयोग को प्लान वर्शन के अनुसार सेगमेंट किया जाए। उदाहरण: ग्राहक मिड-माह 10 सीट्स से 25 सीट्स पर अपग्रेड करता है। आप उपयोग इवेंट्स को जैसा का तैसा रखते हैं, पर रेटिंग उन्हें उस एंटाइटलमेंट पीरियड के अनुसार समूहित करती है जो उस समय सक्रिय था।

निर्णय लें कि क्या पलटनीय है। यह मददगार होता है अगर आप उपयोग इवेंट्स को स्वीकार होने के बाद अंतिम मानें, जबकि सब्सक्रिप्शन परिवर्तन केवल तब तक पलटे जा सकते हैं जब तक इनवॉइस फाइनल न हो। परिवर्तन इवेंट्स और इनवॉइस समायोजन स्टोर करें ताकि जब नियम विकसित हों तो आप इनवॉइसें साफ़ तरीके से फिर से जेनरेट कर सकें।

वे डेटा जो आपको पहले दिन से स्टोर करने चाहिए

यदि आप ग्राहकों की शिकायत के बाद बिलिंग डेटा डिज़ाइन करने का इंतजार करते हैं, तो आप अनुमान लगाने लगेंगे। चाहे आप सब्सक्रिप्शन चुनें, उपयोग-आधारित, या हाइब्रिड B2B SaaS प्राइसिंग मॉडल, सबसे सुरक्षित शुरुआती बिंदु छोटे सेट रिकॉर्ड्स है जिन्हें आप बाद में हमेशा ऑडिट कर सकें।

एक स्पष्ट ग्राहक पदानुक्रम के साथ शुरू करें। B2B SaaS में भुगतान करने वाला आम तौर पर कंपनी अकाउंट होता है, पर उपयोग अक्सर वर्कस्पेसेस या प्रोजेक्ट्स के अंदर होता है, और कार्रवाइयाँ व्यक्तिगत उपयोगकर्ताओं से आती हैं। इन तीनों स्तरों (account, workspace, user) को स्टोर करें और रिकॉर्ड रखें कि किसने क्या किया। बिलिंग विवाद अक्सर इस प्रश्न में बदलते हैं: "यह किस टीम ने किया था?"

एक न्यूनतम बिलिंग डेटाबेस डिज़ाइन जो वास्तविक इनवॉइस और साफ़ जांच का समर्थन करता है:

• अकाउंट्स और ऑर्ग संरचना: account, workspace (या project), users, roles, billing contact, और टैक्स फील्ड्स यदि ज़रूरी हों
• सब्सक्रिप्शन्स: प्लान, स्टेटस, स्टार्ट/एंड डेट्स, रिन्यूअल सेटिंग्स, कैंसलेशन कारण, और स्टार्ट पर लागू प्राइसिंग वर्शन
• प्राइस कैटलॉग: प्रोडक्ट्स, प्लान कंपोनेंट्स (बेस फी, सीट्स, मीटर), टायर्स, करेंसी, और प्रभावी तिथियाँ
• उपयोग मीटरिंग डेटा: एक अपरिवर्तनीय अपेंड-ओनली इवेंट लॉग जिसमें टाइमस्टैम्प, वर्कस्पेस, यूज़र (यदि उपलब्ध), मीटर नाम, मात्रा, और यूनिक इडेम्पोटेंसी की
• इनवॉइस आर्टिफैक्ट्स: बिलिंग पीरियड बॉउंड्रीज़, लाइन आइटम्स, टोटल्स, टैक्स/डिस्काउंट समायोजन, और उपयोग किए गए इनपुट्स का स्नैपशॉट

सिर्फ एग्रीगेटेड काउंटर पर भरोसा मत करें। स्पीड के लिए काउंटर रखें, पर इवेंट लॉग को स्रोत-सत्य मानें। एक सरल नियम मदद करता है: इवेंट्स अपरिवर्तनीय हैं, करेक्शन नई इवेंट होते हैं (उदाहरण के लिए नकारात्मक मात्रा), और हर इवेंट एक विशिष्ट मीटर परिभाषा से जुड़ा होता है।

उदाहरण: एक ग्राहक कहता है कि उनके "API कॉल्स" पिछले महीने दोगुने हो गए। यदि आप वर्कस्पेस और दिन के अनुसार रॉ इवेंट्स खींच सकते हैं, तो आप दिखा सकते हैं कि स्पाइक कहाँ से आया या किसी इंटीग्रेशन लूप को पकड़ सकते हैं।

कदम-दर-कदम: उपयोग इवेंट्स से इनवॉइस तक

कठिन भाग गणित नहीं है। कठिन हिस्सा यह सुनिश्चित करना है कि परिणाम महीनों बाद समझ में आये, भले ही प्लान, कीमतें और ग्राहक बदल गए हों।

1) ऐसा प्राइस कैटलॉग शुरू करें जो टाइम-ट्रैवल कर सके

प्रोडक्ट्स, प्लान्स, मीटर और प्राइस को प्रभावी तारीखों के साथ सेट करें। कभी पुरानी कीमत को ओवरराइट न करें। यदि एक ग्राहक को मार्च में बिल किया गया था, तो आपको मार्च के लिए मार्च कैटलॉग का उपयोग करके फिर से रन करने में सक्षम होना चाहिए।

उदाहरण: "API Calls" 1 अप्रैल से प्रति कॉल $0.002 खर्च करता है। मार्च इनवॉइसेस को अभी भी पुराने रेट का उपयोग करना चाहिए।

2) उस पीरियड के दौरान ग्राहक को जो अधिकार थे उसका स्नैपशॉट लें

हर बिलिंग पीरियड की शुरुआत में (या जब परिवर्तन होता है) एक एंटाइटलमेंट स्नैपशॉट स्टोर करें: प्लान, शामिल यूनिट्स, लिमिट्स, टियर नियम, डिस्काउंट्स, और टैक्स सेटिंग्स। इसे उस अवधि के लिए "हमने जो वादा किया" समझें।

3) उपयोग इवेंट्स को ingest करें और जल्दी सत्यापित करें

उपयोग को अपरिवर्तनीय इवेंट्स के रूप में आना चाहिए: टाइमस्टैम्प, ग्राहक, मीटर, मात्रा, और डेडुप्लिकेशन के लिए एक यूनिक id। बेसिक्स को दरवाज़े पर सत्यापित करें (गुम मीटर, नकारात्मक मात्रा, असंभव टाइमस्टैम्प्स) और कच्चे इवेंट को रिकॉर्ड करें भले ही आप एक साफ़ संस्करण भी स्टोर करें।

फिर गणना दो पास में करें:

• घटनाओं को ग्राहक, मीटर और बिलिंग पीरियड के अनुसार टोटल्स में एग्रीगेट करें (और एग्रीगेशन वर्शन रखें)
• उन टोटल्स को कैटलॉग और एंटाइटलमेंट स्नैपशॉट का उपयोग कर चार्ज में रेट करें (शामिल यूनिट्स, ओवरएज प्राइस, टायर्स)

इनवॉइस लाइन आइटम्स जेनरेट करें जो उपयोग किए गए सटीक इनपुट्स (कैटलॉग वर्शन, स्नैपशॉट id, एग्रीगेशन id) का संदर्भ दें।

अंत में, इनवॉइस को लॉक कर दें। गणना इनपुट्स और आउटपुट को स्टोर करें, इसे फ़ाइनल मार्क करें, और देर से आने वाले इवेंट्स आने पर इसे बदलने से रोकें। देर से आने वाले इवेंट्स नेक्स्ट इनवॉइस या अलग समायोजन में जाएँ, स्पष्ट ऑडिट नोट के साथ।

ग्राहक और आंतरिक रिपोर्टिंग की ज़रूरतें

ग्राहक इस बात से परवाह नहीं करते कि आपने सब्सक्रिप्शन चुना या उपयोग-आधारित बिलिंग। उन्हें केवल यह चाहिए कि आपकी संख्याएँ उनकी अपनी गिनी से मेल खाती हों, और वे अनुमान लगा सकें कि अगला चार्ज क्या होगा।

ग्राहक-समक्ष रिपोर्टिंग सबसे अच्छी तब होती है जब एक सरल बिलिंग होम सवालों के जवाब दे बिना सपोर्ट टिकट खोले:

• मैं किस प्लान पर हूँ, और इसमें क्या शामिल है?
• मैंने इस अवधि में कितना उपयोग किया है, और उपयोग कैसे गिना गया?
• मेरी लिमिट्स क्या हैं, और पार होने पर क्या होता है?
• बिलिंग अवधि कब खत्म होती है, और मेरा अनुमानित अगला बिल क्या होगा?
• मैं पिछले इनवॉइस और पेमेंट कहाँ देख सकता/सकती हूँ?

आंतरिक रूप से, सपोर्ट और फाइनेंस को एक संख्या की व्याख्या करनी होती है, सिर्फ उसे दिखाना नहीं। इसका मतलब है स्पाइक्स को ढूँढना, परिवर्तनों का पता लगाना, और प्रीव्यू गणित को फाइनल बिलिंग से अलग रखना।

बिल प्रीव्यू को इनवॉइस से अलग रखें। प्रीव्यू को देर से आने वाले उपयोग आने पर या जब आप मीटर परिभाषा सुधारते हैं तब फिर से कैलकुलेट किया जा सकता है। इनवॉइस को नहीं।

आपकी आंतरिक रिपोर्टिंग को अनोमलीज़ (अचानक उपयोग उछाल, नकारात्मक उपयोग, डुप्लिकेट इवेंट) फ़्लैग करना, किसी इनवॉइस लाइन आइटम को रॉ उपयोग और नियमों से पुन:उत्पन्न करना, और उस अवधि के लिए प्लान परिवर्तन व प्रोरेशन नियम देखना आसान बनाना चाहिए।

ऑडिट ट्रेल अधिक मायने रखता है जितना कई टीमें सोचती हैं। यदि ग्राहक कहता है, "हमने 12 तारीख को अपग्रेड किया," तो आपको टाइमस्टैम्प्स, एक्टर (यूज़र, एडमिन, ऑटोमेशन), और प्लान, सीट्स, लिमिट्स, और मीटर रेट्स के सटीक पहले/बाद के मान चाहिए।

रिटेंशन के लिए, रॉ उपयोग इवेंट्स और फाइनलाइज़्ड इनवॉइस आर्टिफैक्ट्स को लंबी अवधि तक रखें। एक व्यावहारिक नियम: यदि यह चार्ज की गई राशि को बदल सकता है या किसी विवाद में बचाव में मदद कर सकता है, तो इसे अपरिवर्तनीय रूप से स्टोर करें।

बिलिंग विवाद जन्म देने वाले सामान्य जाल

अधिकांश बिलिंग विवाद मूल्य के बारे में नहीं होते। वे तब होते हैं जब आप इनवॉइस की एक संख्या समझा नहीं पाते, या वही इनपुट बाद में अलग कुल देती है।

एक सामान्य गलती केवल मासिक टोटल्स रखना है। रॉ इवेंट्स के बिना आप साधारण सवालों का उत्तर नहीं दे सकते जैसे "किस दिन ने हमें लिमिट के पार धकेला?" इवेंट रखें, फिर उसे एग्रीगेट करें।

एक और सामान्य समस्या यह है कि मीटर का अर्थ बदला गया पर उसे ट्रैक नहीं किया। "सक्रिय उपयोगकर्ता" शुरू में "कम से कम एक बार लॉग इन" हो सकता है और बाद में "रिकॉर्ड बनाया" बन सकता है। यदि आप मीटर परिभाषाओं को वर्शन नहीं करते, तो ग्राहक पुराने इनवॉइस की तुलना नए इनवॉइस से करेंगे और आप यह साबित नहीं कर पाएँगे कि किस नियम लागू था।

विवाद अक्सर कुछ ही पैटर्न से आते हैं:

• केवल UI में लागू एंटाइटलमेंट्स (बैकेंड अभी भी अतिरिक्त उपयोग की अनुमति देता है या वैध उपयोग को ब्लॉक करता है)
• हर चीज़ के लिए एक ही टाइमस्टैम्प फ़ील्ड का उपयोग (इवेंट टाइम, ingestion टाइम, बिलिंग पीरियड टाइम)
• टाइम ज़ोन की उपेक्षा (लोकल 00:30 पर हुआ उपयोग गलत दिन/माह में गिर सकता है)
• बिलिंग एंकर भूल जाना (कुछ ग्राहकों को 1 तारीख को बिल होता है, दूसरों को साइनअप डे पर)
• प्लान, प्राइस, और लिमिट परिवर्तन का कोई ऑडिट ट्रेल नहीं

उदाहरण: टोक्यो में एक ग्राहक मिड-साइकिल 31 तारीख को अपग्रेड करता है लोकल टाइम पर। यदि आप सिर्फ UTC टाइमस्टैम्प स्टोर करते हैं और कोई बिलिंग एंकर नहीं रखते, तो अपग्रेड आपके सिस्टम में 30 तारीख को दिख सकता है, जो प्रोरेशन और उपयोग को गलत पीरियड में शिफ्ट कर देगा।

भरोसा खोने का सबसे तेज़ तरीका यह है कि पुरानी इनवॉइस गणना को पुन:उत्पन्न करने का कोई तरीका न हो। इनपुट्स (इवेंट्स, वर्शन, एंकर, और लागू कीमतें) स्टोर करें ताकि आप वही लॉजिक बाद में फिर से चला कर वही परिणाम पा सकें, भले ही आपका प्रोडक्ट बदल गया हो।

शिप करने से पहले त्वरित जाँचें

लॉन्च से पहले एक ड्रिल करें: एक रैंडम ग्राहक चुनें और केवल स्टोर किए गए डेटा का उपयोग करके उनका पिछला इनवॉइस फिर बनाएं। यदि आपको "उस समय कोड ने जो कुछ किया" चाहिए हो तो आपके पास ऑडिट ट्रेल नहीं है।

सुनिश्चित करें कि हर मीटर अस्पष्ट नहीं है। एक मीटर को एक स्पष्ट यूनिट (रिक्वेस्ट्स, सीट्स, GB, मिनट), एक विश्वसनीय स्रोत (कौन सी सर्विस इसे इमिट करती है), और एक समय विंडो (प्रति दिन, प्रति बिलिंग पीरियड, प्रति कैलेंडर माह) चाहिए। यदि आप मीटर को एक वाक्य में समझा नहीं सकते, तो ग्राहक उस पर भरोसा नहीं करेंगे।

ऐसी त्वरित जाँचें जो अधिकांश बिलिंग समस्याओं को पकड़ लेती हैं:

• आप इनपुट्स: प्लान वर्शन, कीमतें, उपयोग टोटल्स, टैक्स, डिस्काउंट्स, और प्रोरेशन पैरामीटर का उपयोग करके इनवॉइस को रीप्ले कर सकते हैं
• उपयोग इवेंट्स अपेंड-ओनली, अपरिवर्तनीय, और डुप्लिकेट से बचने के लिए डेडुप किए गए हैं (इडेम्पोटेंसी की या इवेंट id)
• प्लान और प्राइस परिवर्तन प्रभावी तिथियों के साथ वर्शन किए गए हैं (पुरानी कीमतें ओवरराइट न हों)
• प्रोरेशन नियम सादे शब्दों में लिखे गए हैं और टेस्ट किए गए हैं
• सपोर्ट जल्दी यह जवाब दे सके "मुझे क्यों चार्ज किया गया?" वही सुरक्षित तथ्य उपयोग करके

उदाहरण: ग्राहक 18 तारीख को 10 सीट्स से 25 सीट्स पर अपग्रेड करता है और 23 तारीख को उपयोग थ्रेशहोल्ड पार कर जाता है। आपकी प्रणाली को दिखाना चाहिए (1) कौन सा प्लान वर्शन प्रत्येक तारीख पर सक्रिय था, (2) सीट-परिवर्तन इवेंट के साथ टाइमस्टैम्प, (3) उपयोग की गई प्रोरेशन फ़ॉर्मूला, और (4) अंतिम कुल में रोल-अप होने वाले उपयोग इवेंट्स।

अगला कदम: ऐसे लागू करें कि खुद को मुश्किल में न डालें

छोटा शुरू करें, पर अस्पष्ट न शुरू करें। सबसे सुरक्षित रास्ता सबसे छोटे डेटा मॉडल से है जो फिर भी आपको महीनों बाद एक प्रश्न का उत्तर देने देता हो: "हमने यह राशि क्यों चार्ज की?"

अपने बिलिंग स्कीमा और एडमिन स्क्रीन का प्रोटोटाइप जल्दी बनाएं, अपने पहले प्राइसिंग परिवर्तन से पहले। यदि आप सेल्स के नए टियर या मिड-साइकिल अपग्रेड के लिए इंतजार करेंगे, तो आप बहुत सी जगहों में लॉजिक पैच कर देंगे।

एक व्यावहारिक विभाजन यह है: Stripe को चार्जिंग, रसीदें, और पेमेंट रिट्राइ संभालने दें, पर रेटिंग (उपयोग को लाइन आइटम में कैसे बदला जाए) अपने सिस्टम में रखें। इसका मतलब है कि आप रॉ उपयोग इवेंट्स, प्राइसिंग वर्शन्स, और इनवॉइस प्रीव्यू बनाने के लिए प्रयुक्त गणना परिणाम स्टोर करते हैं।

एक सरल लॉन्च प्लान जो लचीला रहता है:

• 1-2 मीटर चुनें जिन्हें आप विश्वसनीय रूप से माप सकते हैं (उदाहरण: सक्रिय सीट्स प्रति दिन और API कॉल्स)
• पहले दिन से प्राइसिंग नियमों को वर्शन करें ताकि पुराने इनवॉइस पुराने नियमों से मेल खाते रहें
• एक आंतरिक बिलिंग एडमिन पैनल बनाएं ताकि उपयोग, ओवरराइड्स, क्रेडिट्स, और विवाद देखे जा सकें
• एक बुनियादी ग्राहक पोर्टल व्यू जोड़ें: वर्तमान प्लान, वर्तमान अवधि का उपयोग, अनुमानित बिल
• हर इनवॉइस को एक ऑडिटेबल स्नैपशॉट मानें, न कि फिर से गणना की गई अनुमानित राशि

यदि आप तेज़ी से चलना चाहते हैं बिना बहुत कस्टम बैक-ऑफिस कोड लिखे, तो आप इन एंटिटीज़ को AppMaster में मॉडल कर सकते हैं और इसके विज़ुअल टूल्स से एडमिन और पोर्टल स्क्रीन बना सकते हैं, जबकि PostgreSQL को इवेंट्स और इनवॉइस के लिए सिस्टम ऑफ़ रिकॉर्ड रखते हैं।

ठोस उदाहरण: आप एक सीट्स मीटर के साथ लॉन्च करते हैं। तीन महीने बाद आप स्टोरेज GB जोड़ते हैं। यदि मीटर, एंटाइटलमेंट, और प्राइसिंग नियम वर्शन किए गए हैं, तो आप नया मीटर पेश कर सकते हैं बिना पुराने इनवॉइस तोड़े, और सपोर्ट किसी भी लाइन आइटम की व्याख्या मिनटों में कर सकता है।