EdunodeX Logo EdunodeX
AI & Future Trends in School Tech 29 जुल॰ 2026 8 मिनट पढ़ें

School Autopilot: बिना आपके चलने वाला काम

EdunodeX के autopilot packs रोज़ के फॉलो-अप को कैसे तय समय पर चलने वाले, दोहराव-रोधी और खुद रुक जाने वाले background काम में बदल देते हैं।

EX
EdunodeX Editorial Desk
Verified School ERP & EdTech Guide
📋 Table of Contents

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

Autopilot EdunodeX का वही हिस्सा है जो फॉलो-अप करता है। यह पेज बताता है कि यह चीज़ तकनीकी रूप से है क्या, ताकि आप किसी विशेषण पर भरोसा करने के बजाय ख़ुद परख सकें।

EdunodeX के भीतर “Autopilot” का मतलब

Autopilot दरअसल packs की एक सूची है। Pack यानी एक तय उद्देश्य वाला, नाम दिया हुआ, अपने-आप में पूरा automation: बकाया फीस का फॉलो-अप करना, लगातार ग़ैरहाज़िरी को चिह्नित करना, किसी सरकारी समय-सीमा की याद accountant को दिलाना। अपने स्कूल के लिए pack चालू करते ही आपके स्कूल के अपने database schema में एक या अधिक rules लिख दिए जाते हैं। उसके बाद एक background worker उन rules को उनके तय समय पर जाँचता है और जो भेजना है, भेजता है।

इसके लिए किसी को कोई स्क्रीन नहीं खोलनी पड़ती। यही इसका पूरा मक़सद है — और यही वजह है कि नीचे दी गई सुरक्षा-दीवारें सुविधाओं की सूची से ज़्यादा मायने रखती हैं।

Packs उन्हीं विभागों के हिसाब से श्रेणियों में बँटे हैं जो काम देखते हैं — फीस, उपस्थिति, शैक्षणिक, अभिभावक-संवाद, अनुपालन, संचालन और payroll। मौजूदा सूची, हर pack की settings और एक बार चलने की अनुमानित लागत के साथ, Automations स्क्रीन पर दिखती है।

एक Pack की बनावट: शर्त, action, समय-सारणी

Pack जो rule बनाता है, उसके ठीक तीन हिस्से होते हैं।

शर्त (Condition) — आपके डेटा पर एक निश्चित प्रकार की query। fee_ledger_overdue, जिसमें कितने दिन का बकाया और न्यूनतम कितनी राशि। ml_score_threshold, जो एक जोखिम-स्कोर पढ़ता है। attendance_pending_after_period, जो देखता है कि हाज़िरी दर्ज हुई या नहीं। शर्तें server पर ही एक तय शब्दावली से बनती हैं; कोई भाषा-मॉडल आपके स्कूल के रिकॉर्ड पर SQL नहीं लिखता।

Action — शर्त मिलने पर क्या हो। जो हो सकता है: एक अनुमोदित WhatsApp template, SMS, ईमेल, ऐप के भीतर सूचना, push notification, या किसी नामित आंतरिक intent को बुलाकर सारांश तैयार कराना। हर action के साथ उसका variable map, deduplication key और deduplication window रहता है।

समय-सारणी (Schedule) — cron, तय अंतराल, एक बार, या घटना-आधारित। Cron समय आपके अपने स्कूल के timezone में लिखा जाता है, इसलिए “10:00” का मतलब वहीं की सुबह दस बजे है जहाँ स्कूल है, किसी दूर के server का नहीं।

तीनों हिस्से चूँकि code नहीं, डेटा हैं — इसलिए pack क्या कर रहा है यह देखा भी जा सकता है और बदला भी। फीस रिमाइंडर सात दिन से दस दिन करते समय आप एक threshold बदल रहे हैं, किसी से दोबारा deploy करने को नहीं कह रहे।

Rule mode और agent mode: pack दो तरह से तय करता है

ज़्यादातर packs rule mode में चलते हैं। शर्त मिली, action चला, संदेश पहले से अनुमोदित template में गया और उसमें variables भर दिए गए। तय, सस्ता और अनुमान लगाने लायक — सात दिन का रिमाइंडर सात दिन का ही रहता है।

कुछ packs में agent mode भी है। वहाँ भी पंक्तियाँ चुनने और उनमें संदर्भ जोड़ने का काम तय SQL ही करता है — मॉडल कभी आपके database से query नहीं करता — और एक अकेला structured call वह तय करता है जो निर्णय जैसा है: इस अभिभावक के लिए कौन-सा लहजा ठीक रहेगा, कौन-सी ग़ैरहाज़िरी कभी-कभार की नहीं बल्कि लगातार की लगती है, सोमवार को फ़ोन असल में किन तीन घरों में करना चाहिए। जो जवाब आता है उसे एक सख़्त schema पर जाँचा जाता है और जो पहचान में न आए, हटा दिया जाता है।

Agent mode हर pack के लिए वैकल्पिक है, और हर pack यह घोषित करता है कि उसका agent सीधे कौन-से action चला सकता है — वह सूची छोटी रखी जाती है। उससे बाहर की कोई भी चीज़ सीधे होने के बजाय समीक्षा की क़तार में जाती है। मॉडल को दिया गया स्कूल का डेटा स्पष्ट delimiters के बीच रखा जाता है, इस निर्देश के साथ कि इसे अविश्वसनीय सामग्री मानना है — ताकि छात्र के रिकॉर्ड में टाइप की गई कोई टिप्पणी निर्देश की तरह काम न कर सके।

सुरक्षा-दीवारें: deduplication, circuit breaker, भेजने का समय

जो automation अभिभावकों को spam कर सकता है, उससे बेहतर है कोई automation ही न हो। ठीक इसी को रोकने के लिए तीन व्यवस्थाएँ हैं।

Deduplication. कोई भी संदेश जाने से पहले उस action की deduplication key Redis में atomically claim की जाती है, तय window के बराबर time-to-live के साथ। एक ही tick में एक ही rule जाँच रहे दो workers में से ठीक एक ही सफल होगा। Keys हर स्कूल के लिए अलग namespace में रहती हैं। सबसे अहम बात, यह जाँच बंद की ओर झुकती है: Redis उपलब्ध न हो तो action भेजा नहीं जाता, छोड़ दिया जाता है — क्योंकि छूटा हुआ tick अगली जाँच में सँभल जाता है, पर भेजा जा चुका दूसरा संदेश वापस नहीं लिया जा सकता।

Circuit breaker. हर rule लगातार होने वाली त्रुटियाँ गिनता है। पाँच पर rule error स्थिति में चला जाता है और चलना बंद कर देता है। Admin और principal उपयोगकर्ताओं को ऐप के भीतर सूचना मिलती है — वह भी dedup की हुई, ताकि टूटा हुआ rule ख़ुद शोर का स्रोत न बने — और breaker गिराने वाला WhatsApp action dead-letter table में दर्ज हो जाता है।

भेजने का समय। Packs संदेश शालीन और बदले जा सकने वाले समय पर भेजते हैं — फीस रिमाइंडर default में स्थानीय समयानुसार 10:00, collection briefing 08:00, उपस्थिति का दिन-अंत सारांश roll-call के बाद 17:00। कई packs में सप्ताहांत और छुट्टियाँ छोड़ने की setting भी है। इसके अलावा दख़ल देने वाले channels — push, SMS, WhatsApp — पर broadcast स्कूल की default शांत अवधि, रात 21:00 से सुबह 07:00 IST, में रोक लिए जाते हैं; आपात श्रेणी के संदेश इससे बाहर हैं।

शुरुआत का क्रम: पहले तीन packs

पहले ही दिन सब कुछ चालू कर देना — स्कूल इसी तरह automation पर से भरोसा खोते हैं। जो क्रम काम करता है:

  1. अपने ही स्टाफ़ के लिए, सिर्फ़ पढ़ने लायक कुछ। रोज़ की collection briefing या उपस्थिति का सारांश। स्कूल के बाहर कुछ नहीं जा रहा। आप देख लेते हैं कि आँकड़े आपकी अपनी समझ से मेल खाते हैं या नहीं।
  2. लेन-देन वाला और स्वागतयोग्य कुछ। भुगतान की पुष्टि। अभिभावक इसे पाकर ख़ुश होते हैं, और WhatsApp का पूरा रास्ता एक बार जाँचा जाता है।
  3. याद दिलाने वाला कुछ। फीस फॉलो-अप या लगातार ग़ैरहाज़िरी। तब तक एक हफ़्ते का firing history आपके पास होगा और आप जान चुके होंगे कि आँकड़े सही हैं।

हर क़दम के बाद firing log पढ़ें। हर जाँच पर एक पंक्ति लिखी जाती है — क्या मिला, क्या भेजा गया, दोहराव मानकर क्या छोड़ा गया, और क्या विफल हुआ।

Autopilot जान-बूझकर क्या नहीं करता

आपकी ओर से यह किसी सरकारी portal पर कुछ जमा नहीं करता। अनुपालन packs समय-सीमाएँ सामने लाते हैं और संबंधित फ़ाइल समीक्षा के लिए तैयार कर देते हैं; जमा करना इंसान का ही काम रहता है।

यह वित्तीय निर्णय नहीं लेता। छूट, रियायत, reversal और समायोजन — कोई मॉडल चाहे जो सुझाए, सब इंसानी अनुमोदन की क़तार में जाते हैं।

EdunodeX Lite में यह शामिल नहीं है। उस स्तर पर pack runner स्पष्ट रूप से बंद है; Lite स्कूलों को इसके बदले सिर्फ़ देखने लायक AI सतहें मिलती हैं।

और यह बिना audit trail के नहीं चलता। हर firing, हर deduplication skip, हर circuit-breaker trip — सब ऐसी पंक्तियाँ हैं जिन्हें आप पढ़ सकते हैं। जिस स्वायत्तता का कोई रिकॉर्ड न हो, वह असल में सॉफ्टवेयर का ऐसा काम है जिसे आप जाँच ही नहीं सकते।

आगे पढ़ें

💰

Interactive School Fee Savings Calculator

Calculate how much money EdunodeX 0% MDR WhatsApp UPI saves your school annually.

1,000 Students
₹30,000 / year
1.5% MDR
Total Annual Fee Collection
₹3,00,00,000
Legacy MDR Fee Lost
₹4,50,000 / yr
EdunodeX 0% MDR Fee
₹0 (Zero MDR)
Your Total Annual Net Savings
₹4,50,000 / year
Claim Your Savings — Book Free Demo →

Frequently Asked Questions (GEO Verified)

क्या autopilot और स्कूल का AI chatbot एक ही चीज़ हैं?

नहीं। Chatbot तभी जवाब देता है जब कोई कुछ पूछे। Autopilot तय समय पर या किसी घटना पर चलता है, भले ही सामने कोई न हो — यह आपके स्कूल के डेटा पर एक शर्त जाँचता है और तय काम भेज देता है। EdunodeX में ये दो अलग सतहें हैं और अलग-अलग भी इस्तेमाल हो सकती हैं।

एक ही अभिभावक को दो बार संदेश जाने से क्या रोकता है?

हर action के साथ एक deduplication key और घंटों में तय एक window होती है। संदेश भेजने से पहले वह key Redis में atomically claim की जाती है, इसलिए एक ही rule चला रहे दो workers दोनों नहीं भेज सकते। Redis तक न पहुँचा जा सके तो जाँच बंद की ओर झुकती है — संदेश छूट जाता है, दोहराया नहीं जाता।

क्या स्कूल अलग-अलग pack चालू या बंद कर सकता है?

हाँ। Pack हर स्कूल के लिए अलग से चालू होते हैं, और हर pack के अपने threshold होते हैं — दिन, घंटा, cut-off, न्यूनतम राशि, प्राप्तकर्ता की भूमिका। Pack चालू करने पर उसके rules सक्रिय होते हैं; बंद करने पर आपकी settings मिटे बिना rules निष्क्रिय हो जाते हैं।

अगर कोई pack बार-बार विफल होने लगे तो?

हर rule लगातार होने वाली त्रुटियाँ गिनता है। पाँच पर पहुँचते ही rule error स्थिति में चला जाता है और चलना बंद कर देता है। Admin और principal उपयोगकर्ताओं को ऐप के भीतर सूचना मिलती है, और जिस WhatsApp action पर breaker गिरा उसे dead-letter रिकॉर्ड में लिखा जाता है — विफलता चुपचाप दबती नहीं, जाँची जा सकती है।

Related AI & Future Trends in School Tech Guides

Regulatory & Policy References

Modernize Your School Operations Today

Join 500+ schools leveraging EdunodeX AI for WhatsApp fee collection, instant parent alerts, APAAR ID compliance, and automated report cards.