Telegram बुकिंग बॉट: बनवाएँ, बनाएँ या तैयार लें (2026)

TL;DR. बुकिंग बॉट देखने में weekend project लगता है: कैलेंडर, समय-खाना picker, भुगतान, याद दिलाना. Development studios ठीक इसी के 1,500–3,500 EUR माँगते हैं — नीचे basic याद दिलाने वाला एक कैलेंडर, ऊपर कई staff, अग्रिम भुगतान और रद्दीकरण नियम. Weekend और तीन हज़ार यूरो के बीच का फ़ासला वह दूसरी सूची है जो brief में कोई नहीं लिखता: race conditions, timezones, आपस में टकराती अवधियाँ, पुनरारंभ होते workers. नीचे तीन रास्ते हैं — बनवाना, बनाना, तैयार लेना — और वे मौके भी जहाँ बनवाना ही सही जवाब है।

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

फिर 1,500–3,500 EUR का estimate आता है और बढ़ा-चढ़ा लगता है। आम तौर पर होता नहीं। वह दूसरी सूची है।

वह सूची जो brief में कोई नहीं लिखता

• दो ग्राहक एक ही सेकंड में 15:00 दबाते हैं। समय-खाना किसे मिलेगा, और आपको कैसे पता चलेगा?
• ग्राहक Lisbon में है, आप Warsaw में। स्क्रीन पर दिख रहा 15:00 किसका है?
• 90 मिनट की sitting और उसके बाद 15 मिनट का gap — यह और कौन-से समय-खाने बंद करता है?
• याद दिलाना job बीच दौर में पुनरारंभ हो जाता है। दूसरा याद दिलाना किसे जाएगा?
• एक बुकिंग गुरुवार को खिसक गई। क्या उसके याद दिलाने भी साथ खिसके?

इनमें से कुछ भी सुविधा सूची में नहीं दिखता, और हर बिंदु बिगड़ने पर सहायता संदेश बन जाता है। पैसा यही हिस्सा माँगता है; रास्ते बस इसमें अलग हैं कि कौन चुकाता है और कब।

रास्ता 1 — custom development बनवाना

क्या मिलता है. ठीक वही जो आपने माँगा — अपनी branding में, अपने infrastructure पर, बिना योजना सीमाएँ और बिना vendor. काम सचमुच असामान्य है तो वहाँ तक यही रास्ता पहुँचता है।

कितना लगता है. Studios basic याद दिलाने वाले सादे बुकिंग बॉट को 1,500–3,500 EUR की सीमा के निचले सिरे पर रखते हैं, और कई practitioners, अग्रिम भुगतान और रद्दीकरण नीति वाले को ऊपरी सिरे के पास। यह दाम सूची नहीं, बाज़ार का अनुमान है: देश और studio से बदलता है।

दूसरा बिल. बुकिंग बॉट कभी पूरा नहीं होता। Telegram API के versions निकालता है, timezone डेटाबेस साल में दो बार बदलता है, कोई ग्राहक ऐसी स्थिति ढूँढ़ लेता है जिसे किसी ने test नहीं किया। Handover के बाद यह या तो maintenance retainer है या आपके weekends — और estimate में यह शायद ही शामिल होता है।

रास्ता 2 — खुद बनाना

n8n साँचे और GitHub repositories दिखने वाला हिस्सा एक शाम में कर देते हैं: समय-खाना सूची, inline keyboard, confirmation संदेश. इसमें कुछ ग़लत नहीं — हफ़्ते में गिनी-चुनी बुकिंग ही पूरा काम है तो शायद यही आख़िरी जवाब हो। पहले न दिखने वाला हिस्सा गिरता है।

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

Overlap, बराबरी नहीं. Gap की सहज जाँच start times मिलाती है। लेकिन 15 मिनट buffer वाली 90 मिनट की बुकिंग हर उस चीज़ से टकराती है जिसका सीमा उसे छूता है — यह अलग सवाल है। Start times मिलाने से ऐसा कैलेंडर बनता है जो सही दिखता है और ऐसे समय-खाने बेच देता है जिन्हें आप निभा नहीं पाएँगे।

दोहरे याद दिलाने. Loop में भेजिए, और हर पुनरारंभ उन्हें दोहरा देगा। रोकने के लिए हर याद दिलाना को अलग-अलग भेजा हुआ चिह्नित करना पड़ता है, और कोई साँचा इसके साथ नहीं आता।

Timezones. काटने से पहले सबसे लंबे टिकने वाला मामला: दूसरे देश के पहले ग्राहक तक — या अक्तूबर के आख़िरी रविवार तक — सब बेदाग़ चलता है।

रास्ता 3 — तैयार लेना

सौदा उल्टा है: न बनाना, न बिल — और असामान्य ज़रूरतें भी नहीं। मिलते हैं पहले से लिए गए फ़ैसले। AdminHub के बुकिंग बहाव में:

कैलेंडर. काम के घंटे हर weekday के intervals हैं, और एक दिन में एक से ज़्यादा हो सकते हैं: 10:00–13:00 और 15:00–18:00 lunch break है, special case नहीं। हर बुकिंग के दोनों ओर 0 से 120 मिनट का buffer बैठता है, और candidate समय-खाना तब हटता है जब उसका सीमा किसी बुकिंग से overlap करे, न कि तब जब start समय मिले। अगले दो घंटों में कुछ bookable नहीं, आगे की खिड़की तयशुदा 30 दिन, और बंद तारीखों की ranges त्योहार तथा अगस्त का एक हफ़्ता हटा देती हैं। हर सेवा के लिए एक timezone, जो हर समय-खाना के साथ जाता है ताकि कोई अंदाज़ा न लगाए कि वह 15:00 किसकी घड़ी का है।

याद दिलाने. एक समय-खाना से 24 घंटे पहले, एक घंटे भर पहले। हर एक भेजते ही चिह्नित हो जाता है, इसलिए पुनरारंभ हुआ worker उसे दोहरा नहीं सकता, और बुकिंग खिसकने पर दोनों निशान मिट जाते हैं ताकि नए समय को अपने याद दिलाने मिलें। ये हमेशा आपके बॉट से जाते हैं: मंच का बॉट आपके ग्राहकों को कभी संदेश नहीं करता, इसलिए याद दिलाना उसी चैट में गिरता है जहाँ बुकिंग हुई थी, उसी नाम से।

रद्दीकरण. खिड़की आप तय करते हैं, तयशुदा 24 घंटे। उसके भीतर ग्राहक खुद रद्द करता है; बाहर नहीं कर सकता, और बात आप तक आती है। आप किसी भी बुकिंग को कभी भी रद्द या खिसका सकते हैं, और ग्राहक को उसके बॉट चैट में बता दिया जाता है। पैसे पर ईमानदारी ज़रूरी है: AdminHub उसे रोककर नहीं रखता, इसलिए अपने आप कुछ वापस नहीं होता — वापसी आपका काम है, उसी पटरी से जिससे भुगतान आया था। समय-खाना का अंत समय बीतते ही बुकिंग खुद बंद हो जाती है, बिना किसी automatic “समीक्षा दीजिए” संदेश के: बिना माँगे समीक्षा की गुज़ारिश ग्राहक को सिखा देती है कि आपका बॉट स्पैम है।

अग्रिम भुगतान. बुकिंग का रिकॉर्ड तब बनता है जब चालान चुकता होता है, समय-खाना दबाने पर नहीं — जवाबदेही का पूरा तंत्र यही है। आंशिक deposit का field नहीं: चालान उत्पाद की क़ीमत है, इसलिए पहले से कम रक़म रोकना दाम का फ़ैसला है, सेटिंग नहीं। समय-खाना चुनते वक़्त ग्राहक जो note लिखता है वह बुकिंग के साथ चलता है, तो आप जानते हुए पहुँचते हैं कि वह क्यों आया है।

भुगतान पटरी चुनने की चीज़ नहीं

साफ़ कहना ज़रूरी है, क्योंकि briefs इसी के इर्द-गिर्द लिखे जाते हैं। Telegram का नियम binary है। असली दुनिया की सेवा — visit, haircut, घर पर आना — भुगतान प्रदाता के ज़रिए कार्ड से चुकाई जाती है। डिजिटल रूप से दी जाने वाली सेवा, जैसे वीडियो consultation, Telegram Stars से। एक उत्पाद एक पटरी लेकर चलता है, और “ग्राहक खुद चुन ले” तीनों में से कोई रास्ता नहीं बना सकता।

कौन क्या है

	Custom development	साँचा पर खुद बनाया	AdminHub बुकिंग
शुरुआती खर्च	Studios के हिसाब से 1,500–3,500 EUR	आपका समय	कुछ नहीं
Double बुकिंग से बचाव	डेवलपर पर निर्भर	आम तौर पर नहीं	डेटाबेस constraint
याद दिलाने	Spec के मुताबिक़	हाथ से बने, पुनरारंभ पर दोहराते हैं	24 घंटे और 1 घंटा, हर एक बार
असामान्य ज़रूरतें	जितनी क़ीमत दें	जितना बना लें	सिर्फ़ जो पहले से है
Duty पर कौन	आप या retainer	आप	AdminHub
चालू खर्च	Server और maintenance	Server	Free; Pro हर 30 दिन में 400 Stars

अगर… तो…

अगर…	तो…
एक कैलेंडर, एक व्यक्ति, ग्राहक पहले से Telegram पर	तैयार लीजिए — वे छह बिंदु ही पूरा काम हैं
कई practitioners कमरे या उपकरण साझा करते हैं	बनवाइए — यह scheduling graph है, कैलेंडर नहीं
बुकिंग वेबसाइट, phone या बाज़ार से भी आनी हैं	बनवाइए, या sector का software रखिए और Telegram पहचान के लिए
बीच में clinic रिकॉर्ड system, fiscal hardware या insurer का API है	बनवाइए — वह सीमा असल में जोड़ की ही क़ीमत है
हफ़्ते में गिनी-चुनी बुकिंग और बनाना ही असल मज़ा है	खुद बनाइए, पर डेटाबेस constraint पहली माफ़ी से पहले लगाइए

शुरुआत कहाँ से

• दूसरी सूची लिखिए, पहली नहीं. Race conditions, timezones, buffers, restarts, रद्दीकरण नीति — असली scope यही है, चाहे studio का brief हो या n8n।
• बनवा रहे हैं तो दूसरा साल भी जोड़िए: handover के बाद maintenance का खर्च लिखित में पूछिए।
• खुद बना रहे हैं तो पहले डेटाबेस में uniqueness डालिए. एक constraint वही चूक रोक देता है जो ग्राहक माफ़ नहीं करते।
• तैयार बहाव काम चला रहा हो तो एक शाम में पता कीजिए. एक सेवा, असली काम के घंटे, एक test बुकिंग।

---

बुकिंग के प्रारूप पर — अग्रिम भुगतान और उसी चैट के याद दिलाने न आना के ख़िलाफ़ कैसे काम करते हैं — देखें Telegram पर सेवाएँ। किस उत्पाद को कौन-सा पटरी मिलता है, इसके लिए Stars या कार्ड। यही सवाल सामग्री pipelines के लिए n8n से तैयार सेवा तक में है। बहाव देखने के लिए खोलें Telegram के लिए सेवाएँ।