ज़्यादातर स्कूलों में फीस वसूली असल में पैसे की नहीं, याद रखने की समस्या है। अभिभावक देना चाहते हैं। Accountant याद दिलाना चाहते हैं। इन दो इरादों के बीच एक spreadsheet पड़ी रहती है जिसे छाँटने का समय किसी के पास नहीं, और जब तक कोई देखता है, बकाया तीन महीने पुराना हो चुका होता है और बातचीत असहज।
फीस फॉलो-अप pack यही बोझ उठा लेता है।
हाथ से किया जाने वाला फॉलो-अप कहाँ विफल होता है
जाना-पहचाना चक्र यह है: महीने के अंत में बकाया सूची निकालना, साफ़ मामलों पर निशान लगाना, किसी क्लर्क से फ़ोन करवाना, शायद एक-तिहाई तक पहुँचना, बाक़ी अगले चक्र में खिसक जाना। तीन जगह वही चूक दोहराती है।
ऊपर से काम करना। सूची ऊपर से पकड़ी जाती है। जो नीचे है उसे महीने-दर-महीने कोई फ़ोन नहीं करता, और उसका बकाया चुपचाप बढ़ता रहता है।
एक चक्र से दूसरे तक कोई याद नहीं। यह कहीं दर्ज नहीं होता कि 8 तारीख़ को किस अभिभावक को याद दिलाया गया था, इसलिए अगला चक्र या तो उन्हें छोड़ देता है या उन्हीं शब्दों में फिर याद दिला देता है।
मूड के हिसाब से सख़्ती। तीसरे रिमाइंडर का लहजा इस पर निर्भर करता है कि फ़ोन कौन कर रहा है और उसकी सुबह कैसी बीती — इस पर नहीं कि फीस असल में कितने दिन की बकाया है।
इनमें से हर चूक समय-सारणी और हिसाब-किताब की है, यानी ठीक वही काम जो सॉफ्टवेयर को उठा लेना चाहिए।
तीन चरणों की escalation सीढ़ी: 7, 15, 30 दिन
Pack चालू करते ही आपके fee ledger पर तीन rules लिखे जाते हैं, तीनों की समय-सारणी एक ही।
| चरण | Default शर्त | लहजा | Template |
|---|---|---|---|
| नरम | नियत तिथि के 7 दिन बाद | शिष्ट स्मरण | Overdue reminder |
| सख़्त | 15 दिन बाद | कामकाजी | Overdue reminder |
| अंतिम | 30 दिन बाद | अंतिम सूचना | Final-notice template |
हर rule pending या partial स्थिति वाली वे ledger entries पढ़ता है जो अपने चरण की दिन-संख्या पार कर चुकी हैं और न्यूनतम राशि से ऊपर हैं। मिलने वाली entries से रिकॉर्ड में दर्ज अभिभावक को एक WhatsApp संदेश जाता है, जिसमें अभिभावक का नाम, छात्र का नाम, बकाया राशि, असल में कितने दिन का बकाया, और स्कूल का संक्षिप्त नाम भर दिया जाता है।
दिन-संख्याएँ ही असली बात हैं, और तीनों आपके अपने हाथ में हैं। तिमाही billing वाला स्कूल शायद 15, 30 और 45 चाहेगा। जिस स्कूल पर नक़दी का दबाव है वह 3, 10 और 21 चुन सकता है। Escalation का ढाँचा दोनों हालात में वही रहता है।
वे threshold जो सचमुच स्कूल के हाथ में हैं
तीन दिन-संख्याओं के अलावा pack में ऐसी settings हैं जो तय करती हैं कि दायरे में कौन आएगा:
- न्यूनतम राशि, पैसे में रखी हुई, default ₹100। इससे नीचे कुछ नहीं जाता।
- माफ़ को बाहर रखें — default में चालू। जो रियायत आपने ख़ुद दी है, उस पर कोई रिमाइंडर नहीं जाता।
- रद्द को बाहर रखें — default में चालू।
- Quiet hours, एक शुरू और एक अंत समय, उन स्कूलों के लिए जो निर्धारित 10:00 के साथ-साथ एक स्पष्ट न-भेजने की अवधि दर्ज रखना चाहते हैं।
इन्हें एक ही बार, चालू करते समय तय कर लें। जो सिस्टम ठीक चालीस परिवारों तक पहुँचता है और जो rounding की ग़लती पर स्कूल के हर अभिभावक को WhatsApp कर देता है — फ़र्क़ इन्हीं settings का है।
उसी अभिभावक को दूसरा संदेश क्यों नहीं जाता
यही वह व्यवस्था है जिसके भरोसे इसे चलता छोड़ देना सुरक्षित होता है।
भेजे जाने वाले हर action के साथ एक deduplication key होती है, जो चरण, उस विशेष ledger entry और rule — इन तीनों से बनती है; साथ में एक window, जो फीस फॉलो-अप के लिए default में 168 घंटे है। संदेश निकलने से पहले वह key Redis में atomically claim की जाती है। Key पहले से मौजूद हो तो action दोहराव मानकर दर्ज होता है और कुछ भी नहीं भेजा जाता।
दो नतीजे समझ लेने लायक हैं। पहला, key में चरण शामिल है, इसलिए सात दिन से पंद्रह दिन तक पहुँची entry सचमुच एक पायदान ऊपर चढ़ती है — सख़्त रिमाइंडर की key नरम वाली से अलग है। दूसरा, key में ledger entry भी शामिल है, इसलिए तीन बकाया entries वाले परिवार को तीन अलग मामले माना जाता है, एक नहीं; यह न चाहिए तो न्यूनतम राशि का threshold और आपका billing ढाँचा ही आपके साधन हैं।
Redis तक न पहुँचा जा सके तो claim विफल होता है और संदेश भेजने की कोशिश ही नहीं होती, वह छोड़ दिया जाता है। संदेश छूट जाना अगले दिन की run में पूरा हो जाता है। पर पिछले हफ़्ते भुगतान कर चुके अभिभावक को गई दूसरी “अंतिम सूचना” कभी वापस नहीं ली जा सकती।
Agent mode चालू हो तो लहजे का चुनाव
फीस pack में agent mode भी है। तय SQL एक सीमित batch में बकाया entries चुनता है और हर एक के साथ वह संदर्भ जोड़ता है जो सिर्फ़ दिन गिनने से नहीं मिलता: कोई आंशिक भुगतान हुआ है या नहीं, उस छात्र के नाम और कितनी entries खुली हैं, परिवार ने आख़िरी बार कुछ कब दिया था।
फिर एक अकेला structured call हर entry के लिए एक लहजा तय करता है — नरम, सख़्त या अंतिम — और साथ में एक वाक्य का कारण। निर्देशों में स्पष्ट लिखा है कि जिस अभिभावक ने हाल में आंशिक भुगतान किया है उन्हें अधिक से अधिक नरम लहजा मिलेगा, क्योंकि उनकी कोशिश दिख रही है; और आठ दिन की पहली देरी को कभी अंतिम सूचना तक नहीं बढ़ाया जाएगा।
मॉडल सिर्फ़ एक लहजा लौटाता है; वह न ख़ुद कोई पाठ रचता है, न प्राप्तकर्ता चुनता है। संदेश अनुमोदित template से ही जाता है। मॉडल जो कुछ लौटाए और वह अपेक्षित ढाँचे में न बैठे, उसे भेजने से पहले ही हटा दिया जाता है; और फीस agent सीधे सिर्फ़ एक ही काम कर सकता है — WhatsApp संदेश भेजना।
सोमवार का defaulter digest
अभिभावकों से फॉलो-अप करना आधा काम है। बाक़ी आधा है अपने स्टाफ़ को बताना कि इस हफ़्ते का समय कहाँ लगाना है।
एक सहयोगी pack हर सोमवार स्थानीय समयानुसार 09:00 पर admin और accountant भूमिकाओं को एक digest भेजता है — न्यूनतम कितने दिन के बकाया, उस सीमा से ऊपर के सबसे बड़े defaulters की सूची। संख्या और सीमा, दोनों settings हैं। Agent mode में क्रम सिर्फ़ रक़म के हिसाब से नहीं, समग्र होता है — रक़म, उम्र, और आख़िरी बार किसी से संपर्क कब हुआ; साथ में एक छोटा विश्लेषण और हर परिवार के लिए अगला क़दम।
जिन्हें साप्ताहिक नहीं, रोज़ का हिसाब चाहिए, उनके लिए collection morning briefing 08:00 पर वही काम करती है — कल की वसूली और आज की अपेक्षित राशि के साथ।
एक हफ़्ते बाद firing log पढ़ें
Settings स्क्रीन देखकर इस पर भरोसा न करें। पहले हफ़्ते के बाद automations का firing log खोलकर पढ़ें।
हर पंक्ति में rule, शर्त में क्या मिला, कौन-सा action गया, और नतीजा दर्ज रहता है — भेजा गया, दोहराव मानकर छोड़ा गया, या विफल हुआ। आपको अनुपात देखना है: चालीस entries मिलीं और अड़तीस दोहराव मानकर छूटीं, तो escalation windows अपना काम कर रही हैं। कुछ भी न चला हो, तो आपकी दिन-संख्याएँ आपके सबसे पुराने बकाया से भी बड़ी हैं — जो असल में चिंता की बात नहीं।
सफलताओं से ज़्यादा विफलताएँ मायने रखती हैं। किसी rule पर लगातार पाँच त्रुटियाँ होते ही उसका circuit breaker गिर जाता है: rule चलना बंद कर देता है, admin और principal उपयोगकर्ताओं को ऐप के भीतर सूचना मिलती है, और विफल WhatsApp action dead-letter रिकॉर्ड में लिख दिया जाता है। यह जान-बूझकर है। जो rule चुपचाप विफल होता जा रहा है, वह उस rule से बुरा है जो साफ़-साफ़ रुक गया।
हर pack में साझा रहने वाली व्यवस्थाओं के लिए देखें School Autopilot: बिना आपके चलने वाला काम।