ConnectWiz बुकिंग

वह अपॉइंटमेंट बही जिसकी रीढ़ एक डेटाबेस है.

किसी एजेंट ने बुक किया, AI ने, किसी फ़्लो ने, या ख़ुद ग्राहक ने — हर अपॉइंटमेंट एक ही लेजर में आता है, जहाँ कमरे, उपकरण और डॉक्टर ठीक-ठीक एक-दूसरे को काटते हैं, दोहरी बुकिंग को स्टोरेज परत ख़ुद रोक देती है, और आपके असली कैलेंडर दोनों तरफ़ सिंक होते हैं.

बुकिंग के चार दरवाज़े, एक ही सच टकराव डेटाबेस से ही रुके हुए Google · Outlook · Apple सिंक
उपलब्धता — जो डेटाबेस तय करता है
गुरुवार
कमरा + उपकरण + डॉक्टर: खाली
ओवरलैप — DB ने ख़ारिज किया
14:30 बुक
Google को भेजा गया · व्यस्त समय घटाया गया
4
बुकिंग के दरवाज़े — पैनल, AI, फ़्लो का क़दम, और विजेट में विज़िटर की अपनी बुकिंग
0
दोहरी बुकिंग मुमकिन — ओवरलैप को डेटाबेस की एक शर्त ख़ारिज करती है, कोई ऐप नियम नहीं जो होड़ में हार सके
3
दोनों तरफ़ सिंक होने वाले कैलेंडर प्रोवाइडर — Google, Outlook/Microsoft 365 और Apple/CalDAV
15 मिनट
रिमाइंडर इंजन की चाल — ग्राहक रिमाइंडर और स्टाफ़ अलर्ट आपके तय किए समय पर चलते हैं

चार दरवाज़े

सब एक ही सच के सामने बुक करते हैं

टीम, डायरी में

एक दिन-दृश्य डायरी और पूरा बुकिंग प्रबंधन — प्रकार, जगहें, डॉक्टर, सेवा के रूप, किरायेदार के तय किए स्थिति लेबल, न-आने की सँभाल और लाइन आइटम.

AI, दो क्रियाओं में

Wiz असली खाली स्लॉट बताता है, फिर वही बुक करता है जो ग्राहक चुनता है — जान-बूझकर दो क़दम, क्योंकि किसी के लिए पहला खाली स्लॉट अपने आप रोक लेना डेमो की चाल है, सेवा नहीं.

फ़्लो, एक क़दम के रूप में

यह बुकिंग नोड किसी भी ऑटोमेशन में स्लॉट देने का काम डाल देता है — वह रिमाइंडर फ़्लो जो दोबारा बुक हुई अपॉइंटमेंट पर ख़त्म होता है, बीच में किसी इंसान के बिना.

विज़िटर, ख़ुद-सेवा

यह वेबसाइट विजेट, इसका बुकिंग मिनी-ऐप ग्राहकों को लाइव उपलब्धता में से ख़ुद चुनने देता है — और दिखता तभी है जब आप सचमुच बुक होने लायक़ सेवाएँ देते हैं.

संसाधन का मॉडल

कमरे, उपकरण, लोग — हक़ीक़त की तरह एक-दूसरे को काटते हुए

"उपलब्ध" तीन तरफ़ा सवाल है: डॉक्टर, कमरा और उपकरण, तीनों एक साथ खाली होने चाहिए. ज़्यादातर बुकिंग टूल एक ही धुरी का मॉडल बनाते हैं और उम्मीद पर बैठ जाते हैं; यह टूल कटान का मॉडल बनाता है.

अमूर्त 3D चित्र: एक कैलेंडर ग्रिड जिसमें एक पन्ना-हरा स्लॉट है, तीन संसाधन गोले जिन्हें एक रोशनी का छल्ला बाँधे हुए है, और एक ओवरलैप करता स्लॉट जिसे एक बल-क्षेत्र दूर धकेल रहा है

भूमिकाएँ और कंटेनर

एक बुकिंग भूमिका के हिसाब से कई संसाधन रखती है — कमरा, उपकरण, डॉक्टर — और कंटेनर लिंक का मतलब है कि व्यस्त कमरे के भीतर रखा उपकरण ठीक ही अनुपलब्ध रहता है, भले ही किसी ने उपकरण बुक न किया हो.

शर्त, कोई नियम नहीं

ओवरलैप रोकना स्टोरेज परत में एक exclusion constraint के रूप में रहता है — होड़ करती दो माँगें दोनों नहीं जीत सकतीं, क्योंकि दूसरी लिखाई भौतिक रूप से ख़ारिज हो जाती है. नियम इंजन वादा करता है; शर्त गारंटी देती है.

क्षमता, इकाइयों के रूप में

आठ सीट वाली क्लास आठ इकाइयाँ है, कोई काउंटर नहीं — तो "एक बची है" किसी एक ख़ास इकाई के बारे में तथ्य है, और रिफ़ंड से गणित नहीं बिगड़ता.

पात्रता, अलग से

"क्या यह कमरा यह सेवा दे सकता है" अपना अलग मैट्रिक्स है, क़ब्ज़े से अलग — तो खाली लेकिन ग़लत संसाधन कभी पेश नहीं होता, और वजह देखी जा सकती है.

कैलेंडर सिंक

आपके कैलेंडर, उपलब्धता में से घटे हुए

बुकिंग बाहर जाती हैं

अपॉइंटमेंट Google, Outlook या Apple कैलेंडर में इवेंट बनकर दिखते हैं — और रद्द होने पर ग़ायब हो जाते हैं. डॉक्टर के फ़ोन का कैलेंडर डायरी से कभी एक दिन पीछे नहीं रहता.

व्यस्त समय भीतर आता है

बाहरी इवेंट उपलब्धता में से घट जाते हैं — AI गुरुवार 15:00 कभी नहीं देता जब आपके निजी Google Calendar में वहाँ पहले से दाँतों का डॉक्टर बैठा हो.

हर स्रोत की अपनी भूमिका और दिशा

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

रिमाइंडर और ऑपरेशंस

फ़ॉलो-थ्रू, अपने आप

रिमाइंडर जो सचमुच चलते हैं

आपके तय किए समय पर ग्राहक की पुष्टि और रिमाइंडर — Email से, और चाहें तो SMS से — साथ में नई बुकिंग पर स्टाफ़ अलर्ट. "फिर से संपर्क करना" अब याददाश्त पर नहीं टिकता.

बुकिंग स्टॉक ख़र्च करती हैं

एक सेवा अपॉइंटमेंट पुर्ज़े यहाँ से ख़र्च कर सकता है: स्टॉक लेजर — इलाज और उसमें लगी सामग्री एक ही हरकत में हिसाब में आ जाते हैं.

हिस्ट्री भी साथ आती है

किसी दूसरे CRM से आ रहे हैं? माइग्रेशन इंजन आपकी मौजूदा अपॉइंटमेंट हिस्ट्री उसी लेजर में ले आता है — डायरी याददाश्त खोकर शुरू नहीं होती.

बारीक अक्षर, ईमानदारी से

इससे पहले कि आप इसके भरोसे योजना बनाएँ, कह दिया गया

अभी अलग से बुकिंग लिंक नहीं

ख़ुद-सेवा बुकिंग वेबसाइट चैट विजेट के भीतर रहती है — Calendly जैसा कोई सार्वजनिक बुकिंग पेज अभी नहीं है जिसे आप Email से भेज सकें. अगर आपका असली काम यही है, तो हमें बताएँ; रोडमैप इसी से बनता है.

बाहरी CRM कम ढोते हैं

जब कोई बुकिंग किसी जुड़े CRM में लिखी जाती है, तो उपकरण और खपत का ब्योरा शायद न बचे — वेंडर API ये धुरियाँ छापते ही नहीं, और सिंक चुपचाप गिराने के बजाय बताता है कि उसने क्या गिराया.

लेजर हमेशा हमारा ही रहता है

जो भी कैलेंडर और CRM जुड़ें, बुकिंग लेजर ConnectWiz की अपनी टेबल ही रहता है — बाहरी सिस्टम स्रोत और आईना हैं, मालिक कभी नहीं. यह एक डिज़ाइन का रुख़ है, साफ़ कहा हुआ.

बुकिंग FAQ

तय करने से पहले

और जानकारी: पूरा FAQ, या हमसे सीधे पूछें.

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

ख़ुद डेटाबेस से — स्टोरेज परत पर लगी एक exclusion constraint एक ही संसाधन पर दो ओवरलैप होती पकड़ों को भौतिक रूप से लिखना नामुमकिन बना देती है, चाहे कोशिश किसी भी दरवाज़े से हुई हो. ऐप्लिकेशन नियम होड़ में हार सकते हैं; शर्त नहीं.

हाँ — Google, Outlook/Microsoft 365 और Apple/CalDAV, दोनों तरफ़: बुकिंग इवेंट बनकर बाहर जाती हैं (और रद्द होने पर ग़ायब हो जाती हैं), और बाहरी व्यस्त समय भीतर आकर उपलब्धता में से घट जाता है, तो AI कभी वह स्लॉट नहीं देता जो आपका निजी कैलेंडर पहले ही ले चुका है. हर स्रोत की अपनी भूमिका और दिशा सेटिंग है — पढ़ना, लिखना, दोनों, या सिर्फ़ व्यस्त समय.

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

हर "आप कब खाली हैं?" एक रुके हुए स्लॉट पर ख़त्म हो सकता है.

अपने संसाधन एक बार सेट करें — फिर एजेंट, AI, फ़्लो और ग्राहक, सब एक ही सच के सामने बुक करते हैं.