ट्यूटरिंग सेंटर शेड्यूलिंग और इनवॉइसिंग ऐप: एक सरल योजना

क्यों स्प्रेडशीट ट्यूटरिंग एडमिन के लिए काम करना बंद कर देती हैं

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

अधिकांश सेंटर एक ही तरह की समस्याओं से जूझते हैं:

• एक लेसन मूव होता है, पर सिर्फ़ एक टैब अपडेट होता है, तो कोई रूम या ट्यूटर डबल-बुक हो जाता है।
• एक इनवॉइस बनाया गया पर भेजा नहीं गया के तौर पर मार्क नहीं हुआ, तो वो भूल जाता है।
• भुगतान देर से आते हैं क्योंकि कोई सुसंगत “पेमेंट देय” प्रक्रिया नहीं है, बस कोई याद रखने की कोशिश कर रहा है कि किसे नोटिस देना है।

रिकरिंग लेसंस स्प्रेडशीट्स को विशेष रूप से नाज़ुक बनाते हैं। जब कोई छात्र हर मंगलवार एक ही स्लॉट लेता है, तो आप हफ्तों या महीनों के लिए पंक्तियाँ कॉपी करते रहते हैं। फिर एक अपवाद होता है (त्योहार, मेक-अप, ट्यूटर बदलना), और अचानक आपके पास असली घटनाओं के बारे में कई “सच्चाइयाँ” हो जाती हैं। कई ट्यूटर, अलग दरें और पैकेज जोड़ें — शीट मैनुअल चेकों का पैचवर्क बन जाती है।

इसका असर तीन भूमिकाओं पर एक साथ पड़ता है: मालिक जो नकदी प्रवाह देखना चाहते हैं, एडमिन जो दिन-प्रतिदिन संभालते हैं, और लीड ट्यूटर जिन्हें भरोसेमंद कैलेंडर चाहिए। अगर कोई पूछ रहा है “कौन सा वर्शन सही है?”, तो आपने स्प्रेडशीट्स से आगे बढ़ना चाहिए।

"काफी अच्छा" ट्यूटरिंग सेंटर शेड्यूलिंग और इनवॉइसिंग ऐप का अर्थ भड़कीला नहीं होता। आमतौर पर इसका मतलब यह चार चीज़ें हर बार काम करती हैं:

• एक ऐसा शेड्यूल जिसे हर कोई भरोसा करे (रिकरिंग लेसंस और अपवादों के साथ)
• इनवॉइस जो वही दिखाएँ जो दिया गया था (दरें, पैकेज, डिस्काउंट)
• स्वचालित, विनम्र रिमाइंडर जो समय पर भेजे जाएँ
• सरल रिपोर्टिंग: क्या पढ़ाया गया, क्या बिल किया गया, क्या बाकी है

जब ये चार स्पष्ट हो जाते हैं, तो बाकी सब ऐड-ऑन बन जाते हैं बजाय रोज़ की आग बुझाने के।

ऐप को क्या ट्रैक करना चाहिए (बनाने से पहले)

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

लोगों और सर्विस से शुरू करें:

• Students
• Guardians (जो भुगतान करते हैं)
• Tutors
• Subjects
• Locations (सेंटर में, ऑनलाइन, या कोई खास रूम)

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

एक साधारण शुरुआती रिकॉर्ड सेट:

• Student (नाम, ग्रेड, नोट्स, असाइन किया गया guardian)
• Guardian (संपर्क, पसंदीदा चैनल, बिलिंग विवरण)
• Tutor (कौशल, उपलब्धता)
• Lesson (दिन/समय, अवधि, स्थान, विषय, स्थिति)
• Rate plan (घंटा, प्रति-सत्र, पैकेज, या कस्टम)

अगला, शेड्यूलिंग नियम पकड़ें, सिर्फ़ सिंगल इवेंट नहीं। उपलब्धता मायने रखती है (कब ट्यूटर पढ़ा सकता है, कब छात्र आ सकता है), साथ में रिकरिंग पैटर्न (हर मंगलवार 4pm) भी। आपको अपवाद भी चाहिए: छुट्टियाँ, ट्यूटर की छुट्टी, एक-बार की रीस्‍केडलिंग, कैंसलेशन, और नो-शो।

शुरुआत में तय कर लें कि लेसन कैंसिल होने पर बिलिंग क्या होगी। यही निर्णय हर जगह दिखाई देगा।

फिर पैसे के हिस्से जोड़ें। एक इनवॉइस सिर्फ़ PDF से ज्यादा होना चाहिए। यह एक रिकॉर्ड है जिसमें शामिल हैं:

• Line items (प्रत्येक लेसन या पैकेज चार्ज)
• Discounts (भाई-बहन, प्रोमो)
• Credits (मेक-अप लेसन, ओवरपेमेंट)
• Tax (अगर आपकी लोकेशन में ज़रूरी हो)

अंत में, कम्युनिकेशन बेसिक्स की योजना बनाएं। ईमेल/SMS के लिए ऑप्ट-इन स्थिति रखें, और कुछ संदेश टेम्पलेट स्टोर करें ताकि स्टाफ़ हर बार "पेमेंट देय" नोट फिर से न लिखे।

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

अपने स्टाफ़ के लिए एक सरल वर्कफ़्लो परिभाषित करें

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

कोर वर्कफ़्लो छोटा रखें:

• बुक (या रीस्‍केड्यूल) एक लेसन
• पढ़ाएँ और उपस्थिति मार्क करें
• इनवॉइस जनरेट करें (या मासिक स्टेटमेंट में जोड़ें)
• भुगतान रिकॉर्ड करें और बैलेंस क्लोज़ करें

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

एक कैलेंडर व्यू चुनें जिसे डिफ़ॉल्ट सोर्स ऑफ़ ट्रूथ माना जाए। एडमिन्स को आम तौर पर डे या वीक ग्रिड चाहिए ताकि गैप और कॉन्फ्लिक्ट्स दिखाई दें। ट्यूटर अक्सर सिर्फ़ अगेंडा लिस्ट पसंद करते हैं जो आज और कल दिखाती है साथ में छात्र विवरण। दोनों ऑफर कर सकते हैं, पर केवल एक को "सही" मानें।

अपनी टीम के लिए सादा भाषा में एक छोटा नियम लिखें ताकि दबाव में वे импровाइज न करें:

• 24 घंटे के अंदर की लेट कैंसलेशन चार्जेबल है (जब तक बीमारी न हो)
• नो-शो पूरी तरह चार्ज होता है
• मेक-अप लेसन 30 दिनों के अंदर उपयोग होना चाहिए
• पैकेज़ एक तय तारीख के बाद एक्सपायर होते हैं
• इनवॉइस के 7 दिनों के भीतर भुगतान देय है

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

रिकरिंग लेसंस: उन्हें बिना उलझन के मॉडल कैसे करें

रिकरिंग लेसंस वही हैं जहाँ अधिकतर ट्यूटरिंग एडमिन सिस्टम गड़बड़ हो जाते हैं। समाधान यह है कि आप बिल्ड करने से पहले तय कर लें कि किस तरह के रिपीट्स आप सपोर्ट करेंगे।

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

एक साफ मॉडल यह है: एक रिकरिंग प्लान कई लेसन इंस्टेंस बनाता है।

• प्लान नियम स्टोर करता है (साप्ताहिक, द्विसाप्ताहिक, मासिक), दिन/समय, ट्यूटर, छात्र, आरंभ तिथि, और समाप्ति तिथि।
• कैलेंडर पर हर लेसन एक अलग इंस्टेंस होता है जिसकी अपनी स्थिति होती है।

यह संरचना बिलिंग को स्पष्ट बनाती है क्योंकि आप बिल उसी चीज़ से करते हैं जो हुई, न कि जो प्लान किया गया था।

अपवाद: छुट्टियाँ और टाइम-ऑफ

वास्तविक जीवन पैटर्न तोड़ता है, इसलिए अपवादों को सामान्य घटनाओं की तरह ट्रीट करें। किसी के दूर रहने पर पूरी सीरीज़ संपादित करने के बजाय, आप एक इंस्टेंस बदलें।

सामान्य अपवाद क्रियाएँ:

• एक तारीख छोड़ दें (त्यौहार, छात्र की छुट्टी)
• एक तारीख रीस्‍केड्यूल करें (मंगलवार को गुरुवार पर ले जाएँ)
• एक तारीख कैंसिल करें (ट्यूटर बीमार)
• एक-बार की अतिरिक्त लेसन जोड़ें

उदाहरण: मिया की साप्ताहिक गणित सोमवार 4 बजे है। किसी सार्वजनिक छुट्टी पर, उस एकल लेसन को "स्किप" या "कैंसिल" मार्क करें, पर रिकरिंग प्लान महीने के बाकी हिस्सों के लिए वही रहता है।

लगातार रहने वाले स्टेटस

स्टाफ़ के झगड़े से बचने के लिए स्टेटस सरल रखें। एक अच्छा सेट है: scheduled, completed, canceled, no-show। अधिक विवरण चाहिए तो नोट जोड़ें (जैसे "छात्र द्वारा कैंसिल")।

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

इनवॉइस सेटअप: दरें, पैकेज और इनवॉयस पर क्या आएगा

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

अधिकांश ट्यूटरिंग सेंटर के लिए ये अच्छे हैं:

• प्रति सत्र (फ्लैट फीस प्रति लेसन)
• प्रति घंटा (रेट x अवधि)
• प्रीपेड पैकेज (उदा. 10 घंटे जो समय के साथ उपयोग होते हैं)
• ग्रुप सेशन (प्रति छात्र बिल या बांटकर)
• छूट और फीस (भाई-बहन डिस्काउंट, लेट कैंसल फीस)

निर्धारित करें कि प्रत्येक इनवॉइस लाइन आइटम क्या दर्शाएगा। एक अच्छा डिफ़ॉल्ट है: एक पूरा हुआ लेसन = एक लाइन। माता-पिता के लिए इसे समझना आसान और स्टाफ़ के लिए समझाना भी।

एक व्यावहारिक लाइन आइटम फॉर्मूला है: लेसन तारीख + ट्यूटर + सब्जेक्ट + अवधि + रेट = राशि। उदाहरण: “Jan 12, Algebra, 60 min, Tutor: Maya, $55/hr” कुल $55 के साथ।

निर्धारित करें कि इनवॉइस कब बनते हैं:

• जब लेसन "completed" मार्क हो (जब शेड्यूल अक्सर बदलते हों तो यह बेहतर)
• एक तय शेड्यूल पर (साप्ताहिक या मासिक) उस अवधि में पूरी हुई लेसंस के आधार पर

एक चुनें और दस्तावेज़ बनाएं ताकि हर कोई एक ही आदत अपनाए।

समायोजन के लिए योजना बनाएं, क्योंकि वे होंगे:

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

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

भुगतान देय रिमाइंडर जो मददगार लगे, न कि दबाव डालने वाला

एक अच्छा रिमाइंडर सिस्टम एक साथ दो काम करता है: यह आपके कैश फ्लो की रक्षा करता है और रिश्ते की सुरक्षा भी करता है।

कुछ निश्चित, predictable टचपॉइंट चुनें और संदेश को सरल रखें। कई सेंटर निम्नलिखित से अच्छा करते हैं:

• देय तिथि से 7 दिन पहले (पहले से सूचना)
• देय तिथि पर (मित्रवत नज़रअंदाज़)
• देय तिथि के 3 दिन बाद (मदद के साथ फॉलो-अप)

2 से 3 टेम्पलेट रखें ताकि यह ऑटोमेटेड चिढ़ न लगे। अनुकूलित करने के लिए उदाहरण:

"Hi [Name], a quick reminder that invoice [#] for [Amount] is due on [Due Date]. Reply if you have any questions. Thank you!"

"Hi [Name], invoice [#] for [Amount] is due today. If you have already paid, please ignore this message. Thanks!"

"Hi [Name], invoice [#] for [Amount] is now past due. If you need to change the payment date or split it, tell us and we will help."

स्पैम से बचने के लिए, भुगतान रिकॉर्ड होते ही रिमाइंडर रुकना चाहिए। इसके लिए स्पष्ट इनवॉइस स्टेटस चाहिए (Draft, Sent, Paid, Overdue) और वह एक जगह जहाँ स्टाफ़ भुगतान रिकॉर्ड करे (कैश, कार्ड, बैंक ट्रांसफर)। जब स्टेटस Paid बन जाए, तो किसी भी शेड्यूल किए गए रिमाइंडर को कैंसल कर दें।

हर रिमाइंडर में सिर्फ़ वही शामिल होना चाहिए जो अभिभावक को कार्रवाई करने में मदद करे:

• राशि देय
• देय तिथि
• इनवॉइस नंबर
• कैसे भुगतान करें (संक्षिप्त निर्देश)
• संपर्क जानकारी (किसे रिप्लाई करना है)

चरण-दर-चरण: पहला वर्किंग वर्जन बनाएं

एक पहले वर्शन को कुछ चीज़ें अच्छे से करनी चाहिए, भले ही वह कुछ "अच्छी है" फीचर्स स्किप कर दे। छोटे कदमों में बनाएं ताकि आप हर हिस्से को असली स्टाफ़ के साथ टेस्ट कर सकें।

बोरिंग, स्पष्ट डेटा से शुरू करें: Students, Tutors, Lessons, Invoices, Payments।

• Lessons: student, tutor, start time, duration, status (scheduled, completed, canceled), rate (या rate plan से लिंक)
• Invoices: student, invoice period, total, due date, status (draft, sent, paid, overdue)
• Payments: एक इनवॉइस से जुड़ा, राशि, तारीख, विधि, नोट्स

अगला, एक शेड्यूलिंग स्क्रीन बनाएं जिसे स्टाफ़ बिना ट्रेनिंग के इस्तेमाल कर सके। फ़्लो ऐसा होना चाहिए: ट्यूटर चुनें, छात्र चुनें, दिन/समय चुनें, आवश्यक हो तो "recurring" चुनें, सेव करें। अगर आप 30 सेकंड में लेसन नहीं बना पा रहे, तो यह ज़्यादा जटिल है।

फिर लेसंस को इनवॉइसिंग से जोड़ें एक सरल नियम से: केवल "completed" लेसंस बिल करने योग्य हों।

इनवॉइसिंग क्रियाओं को व्यावहारिक रखें:

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

रिमाइंडर आखिर में जोड़ें, देय तिथि और भुगतान स्टेटस के आधार पर (उदा., देय तिथि से 3 दिन पहले, फिर 3 दिन बाद यदि अभी भी अमूर्त)।

अंत में, बुनियादी रोल्स जोड़ें। ट्यूटर केवल अपना शेड्यूल और स्टूडेंट्स देखें। एडमिन स्टाफ़ सब कुछ देख सके और इनवॉइस जेनरेट कर सके।

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

सामान्य जाल (और उनसे कैसे बचें)

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

वे जाल जो उथल-पुथल पैदा करते हैं

• रिकरिंग लेसंस को जल्द ही "बहुत स्मार्ट" बनाना। साप्ताहिक पैटर्न और एक स्पष्ट एंड डेट के साथ शुरू करें (या "ongoing")। वास्तविक केस देखने के बाद ही जटिल नियम जोड़ें।
• लेसन स्टेटस का अभाव, जिससे आप दो बार बिल कर देते हैं। हर सत्र को एक स्टेटस चाहिए। केवल "Completed" से इनवॉइस जेनरेट करें।
• रेट एडिट करना इतिहास को फिर से लिख देता है। जारी की गई इनवॉइस पर प्राइसिंग लॉक करें। नए रेट केवल नए सेशंस पर लागू हों।
• अपवादों के लिए स्पष्ट मालिक नहीं होना। तय करें कि छुट्टियाँ कौन मूव कर सकता है, मेकअप कौन अप्रूव करता है, और कैंसलेशन कौन ओवरराइड कर सकता है। इसे ऐप में परमिशन के रूप में रखें, न कि "हम याद रखेंगे"।
• गोपनीयता मूल बातें अनदेखी करना। केवल वही स्टोर करें जो आवश्यक हो, स्टाफ़ एक्सेस सीमित रखें, और संवेदनशील छात्र डेटा किसने बदला इसका लॉग रखें। छात्र नोट्स और बिलिंग नोट्स अलग रखें।

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

उदाहरण: एक छोटे ट्यूटरिंग सेंटर का एक असली महीना

मान लीजिए एक छोटा सेंटर जिसमें 3 ट्यूटर और लगभग 25 सक्रिय छात्र हैं। अधिकतर छात्र सप्ताह में एक बार आते हैं, और कुछ दो बार। यहां लक्ष्य सरल है: कैलेंडर, क्या दिया गया, और क्या बिल किया जाना चाहिए — सब मेल खाएँ।

1 मई को स्टाफ़ ने हर छात्र का रिकरिंग लेसन सेट किया: दिन, समय, ट्यूटर, और रेट। महीना शेड्यूल से भर गया, तो कोई स्प्रेडशीट में पंक्तियाँ कॉपी नहीं कर रहा।

दूसरे सप्ताह में, एक छात्र (Jordan) को स्कूल इवेंट के कारण एक सेशन मूव करना पड़ता है। स्टाफ़ उस एकल लेसन को रीस्‍केड्यूल कर देता है। महीने में बाद में, Jordan फिर से रीस्‍केड्यूल करता है। ऐप मूल सीरीज़ को अखंड रखता है, और दोनों सेशंस स्पष्ट रूप से "moved" मार्क होते हैं, न कि कैंसिल।

Jordan को बीमार होने पर एक मेक-अप लेसन भी चाहिए। स्टाफ़ एक एक-बार का मेक-अप सेशन बनाता है जो छात्र और ट्यूटर से लिंक्ड होता है। यह महीने में दिखता है पर रिकरिंग शेड्यूल को नहीं बदलता।

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

• साप्ताहिक लेसंस सहमति रेट पर बिल किए जाते हैं
• मेक-अप लेसन अलग लाइन आइटम के रूप में शामिल है
• दूसरे बच्चे के इनवॉइस पर भाई-बहन छूट लागू की जाती है
• रीस्‍केड्यूल किए गए सेशंस के लिए नोट्स (वैकल्पिक) जोड़े जाते हैं

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

रोलआउट से पहले त्वरित चेक

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

10-मिनट चेकलिस्ट

इन चेक्स को एक क्लीन टेस्ट अकाउंट पर यथार्थवादी नाम, रेट और लेसन लंबाई के साथ करें:

• एक नया छात्र जोड़ें और 60 सेकंड से कम में एक रिकरिंग लेसन सेट करें।
• उसी समय पर ही एक ही ट्यूटर को डबल-बुक करने की कोशिश करें और पुष्टि करें कि कैलेंडर ब्लॉक करता है (या साफ़ चेतावनी दे और कारण माँगे)।
• दो क्लिक में एक तारीख रेंज के लिए इनवॉइस जेनरेट करें (तिथियाँ चुनें, जेनरेट क्लिक करें) और पुष्टि करें कि इसमें सही सेशंस हैं।
• केवल अनपेड़ इनवॉइस के लिए रिमाइंडर भेजें (paid और voided इनवॉइस को कभी "पेमेंट देय" संदेश नहीं मिलना चाहिए)।
• एक "Overdue" व्यू खोलें और जवाब दें: कौन overdue है और कितना, बिना किसी एक्सपोर्ट के।

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

अच्छा दिखने का मतलब

अच्छा तब होता है जब ऐप सामान्य गलतियों को रोकता है और अपवादों को आसान बनाता है। स्टाफ़ को विशेष नियम याद रखने की ज़रूरत नहीं होनी चाहिए जैसे "कल बैंक ट्रांसफर से भुगतान करने वाले परिवारों को याद न कराना"। सिस्टम को इनवॉइस स्टेटस और भुगतान रिकॉर्ड पर निर्भर होना चाहिए।

अगले कदम: पायलट, सुधार, और बनाना कैसे है चुनें

अपने पहले वर्जन को पायलट समझें। एक प्रोग्राम चुनें (उदा., Math grades 6-8) या एक लोकेशन और इसे 2 से 4 हफ्ते चलाएँ। कम दांव होने से समस्याएँ आसान पकड़ में आती हैं और सुधार सरल होते हैं।

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

साप्ताहिक समीक्षा को सरल रखें:

• हम अभी भी कौन क्या स्प्रेडशीट में कर रहे हैं, और क्यों?
• किस इनवॉइस में मैन्युअल एडिट करना पड़ा?
• किस रिमाइंडर ने रिप्लाई या शिकायत करवाई?
• किस जगह पर स्टाफ़ हिचकिचाया क्योंकि नियम अस्पष्ट थे?
• अगले हफ्ते सबसे ज़्यादा समय कौन बचाएगा?

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

यदि आप नॉन-कोड से बनाना चाहते हैं, तो AppMaster (appmaster.io) एक विकल्प है जो इस तरह की सिस्टम के लिए अच्छा बैठता है क्योंकि यह पूरे ऐप को कवर करता है: डेटाबेस, बिज़नेस लॉजिक, वेब और नेटिव मोबाइल ऐप। व्यावहारिक परीक्षण सरल है: क्या आपकी टीम पूरे हफ्ते को—शेड्यूलिंग, उपस्थिति, इनवॉइसिंग, और रिमाइंडर—एक ही सोर्स ऑफ़ ट्रूथ से चला सकती है।

जब पायलट शांत और पूर्वानुमानिक लगे, तो उसी चेकलिस्ट के साथ अगले प्रोग्राम पर रोलआउट करें और छोटे, सुरक्षित कदमों में सुधार जारी रखें।