मेहमान 360 और पोर्टल · एकल प्रोफ़ाइल, एलर्जी और मैजिक लिंक
हर मेहमान की एक ही प्रोफ़ाइल होती है, जो वेबसाइट, एजेंसी और OTA की बुकिंग में एक ही व्यक्ति को पहचानती है, जिसमें विलय वापस लिया जा सकता है और नक़ाबपोश ईमेल को वही समझा जाता है जो वह है। एलर्जी और पसंद बुकिंग के साथ चलती हैं और विभाग-वार पुष्ट होती हैं। मेहमान पोर्टल में प्रवेश पक्के ईमेल पर भेजे गए मैजिक लिंक से होता है, और लॉयल्टी मेहमान को होटल के अंक कार्यक्रम से जोड़ती है।
एक मेहमान, एक प्रोफ़ाइल
वही व्यक्ति आपकी वेबसाइट से, किसी एजेंसी से और किसी OTA से बुक करता है, और कई सिस्टमों में तीन अलग रिकॉर्ड बन जाते हैं। यहाँ प्रोफ़ाइल एक ही होती है: किसी मेहमान को दर्ज करते समय नया बनाने से पहले पहचानकर्ताओं (ईमेल, फ़ोन, दस्तावेज़) से डुप्लिकेट खोजा जाता है, और यह भी दर्ज होता है कि हर पहचानकर्ता कहाँ से आया। जब दो प्रोफ़ाइल सचमुच एक ही व्यक्ति की हों, तो विलय सब कुछ जोड़ देता है और बाद में वापस भी लिया जा सकता है, क्योंकि ग़लत विलय होता है और वह बिना वापसी वाला दरवाज़ा नहीं हो सकता। OTA जो रिले ईमेल बनाती हैं उन्हें नक़ाबपोश के रूप में पहचाना जाता है: वे प्रोफ़ाइल में वही दिखते हैं जो वे हैं, कभी कोई भूतिया मेहमान नहीं बनाते और पोर्टल में कभी लॉगिन का काम नहीं करते।
एलर्जी और पसंद उन तक पहुँचती हैं जिन्हें ज़रूरत है
मेहमान की पसंद और प्रतिबंधों की एक श्रेणी और गंभीरता होती है, और गंभीर वाली बुकिंग के साथ चलती हैं: दर्ज करते समय आप बताते हैं कि किन विभागों को जानना चाहिए (रसोई, हाउसकीपिंग, सेवा), और हर विभाग मिलने की पुष्टि करता है। यह जानकारी किसी टिप्पणी वाले फ़ील्ड में खोती नहीं: जब तक सब पुष्टि न कर दें, लंबित प्रसारण की सूची बनी रहती है। एलर्जी स्वास्थ्य का डेटा है और उसे उसी भार के साथ सँभाला जाता है: रोज़मर्रा के पठन में वह नक़ाबपोश रहती है, और ब्यौरा उजागर करना एक दर्ज होने वाला कार्य है, कोई आम-सी नज़र नहीं। यह डेटा किसी AI प्रोवाइडर को कभी नहीं भेजा जाता: वर्टिकल की ब्रीफ़िंग व्यक्ति के स्तर वाले डेटा से कोई भी पाठ बनाने से इनकार कर देती है।
मेहमान पोर्टल: मैजिक लिंक से प्रवेश
- मेहमान को पोर्टल का पता पुष्टि वाले ईमेल में या चेक-इन पर एक QR में मिलता है।
- एक्सेस स्क्रीन पर वह बुकिंग में इस्तेमाल किया गया ईमेल डालता है और एक्सेस लिंक माँगता है।
- अगर वह ईमेल प्रोफ़ाइल का पक्का पहचानकर्ता है (OTA का नक़ाबपोश ईमेल कभी लिंक नहीं पाता), तो प्रवेश बटन वाला ईमेल पहुँच जाता है। लिंक 30 मिनट तक चलता है।
- पोर्टल के भीतर मेहमान अपनी बुकिंग (प्रॉपर्टी और तारीख़ों के साथ) और अपने लिए भेजे गए कोटेशन देखता है, और रिसेप्शन को फ़ोन किए बिना अपनी पसंद का कोटेशन स्तर स्वीकार कर सकता है।
लिंक के अनुरोध का जवाब हमेशा एक जैसा रहता है, चाहे वह ईमेल मौजूद हो या न हो: पोर्टल किसी उत्सुक व्यक्ति को यह पुष्टि नहीं करता कि कोई पता होटल का ग्राहक है या नहीं। और सत्र हर बार प्रवेश पर ईमेल दोबारा जाँचता है: रिसेप्शन ने पहचानकर्ता हटाया या बंद किया तो पहुँच उसी क्षण ख़त्म। न कोई पासवर्ड है जो लीक हो, न कोई खाता जिसे मेहमान को सँभालना पड़े।
लॉयल्टी: होटल का अपना कार्यक्रम, कोई दूसरा कार्यक्रम नहीं
आतिथ्य स्क्रीन का लॉयल्टी टैब चयनकर्ता में चुने गए मेहमान के लिए उस लॉयल्टी कार्यक्रम में अंक और श्रेणी दिखाता है जो आपके संगठन के पास CRM में पहले से है। अगर मेहमान अभी उसमें शामिल नहीं है, तो कार्यक्रम में जोड़ें बटन उसे उसी क्षण जोड़ देता है। वर्टिकल होटल के अंकों का कोई समानांतर कार्यक्रम नहीं बनाती: वह मेहमान को मौजूदा कार्यक्रम से जोड़ती है, ताकि कोई दूसरा शेष न बने जिसे बाद में किसी को मिलाना पड़े। ठहराव के लिए अंक जोड़ना सिस्टम की API से होता है, आम तौर पर ठहराव बंद होने पर।
जब मेहमान भुला दिए जाने को कहे
डेटा का स्वामी अपना डेटा निर्यात करवा सकता है और मेहमान के रिकॉर्ड से मिटवा भी सकता है। मिटाने के लिए एक कारण देना पड़ता है और सिस्टम यह रिपोर्ट लौटाता है कि क्या किया गया: प्रोफ़ाइल, पहचानकर्ता और स्वास्थ्य का डेटा मिटा दिया जाता है; बुकिंग और कोटेशन किसी की पहचान बताए बिना बने रहते हैं, क्योंकि वे अधिभोग और लेखांकन को सँभालते हैं; हस्ताक्षरित दायित्व-पत्र प्रमाण के रूप में बना रहता है और सिर्फ़ मिटाई गई प्रोफ़ाइल से उसका जुड़ाव टूट जाता है। जो कुछ क़ानूनी बाध्यता से रोका जाता है वह अपने कारण के साथ सूचीबद्ध दिखता है।