एक शिफ़्ट से अगली शिफ़्ट तक साझा रिसेप्शन टैबलेट
होटल रिसेप्शन के एक काल्पनिक पायलट पर नज़र डालें। देखें कि टीम साझा अनुवाद टैबलेट का परीक्षण कैसे कर सकती है, हर सेशन कैसे खत्म कर सकती है और डिवाइस अगली शिफ़्ट को कैसे सौंप सकती है।
उदाहरण के तौर पर दिया गया परिदृश्य। यह योजना बनाने का एक काल्पनिक उदाहरण है, किसी ग्राहक की केस स्टडी नहीं। नीचे बताए गए होटल, स्टाफ़ और परीक्षण योजना काल्पनिक हैं। इसमें Vavus के किसी ग्राहक के नतीजे या उत्पाद के प्रदर्शन की कोई जानकारी नहीं दी गई है।
एक छोटे होटल की कल्पना करें जो रिसेप्शन पर रोज़मर्रा की बातचीत के लिए एक साझा टैबलेट चाहता है। मैनेजर का सवाल सीधा है: मौजूदा शिफ़्ट खत्म होने पर क्या अगला कर्मचारी इसे सही तरह से इस्तेमाल कर पाएगा? एक उपयोगी पायलट को इस हैंडओवर की जाँच उतनी ही सावधानी से करनी चाहिए, जितनी सावधानी से वह पहले अनुवाद की जाँच करता है।
मेहमानों को डिवाइस देने से पहले होटल स्टाफ़ के नेतृत्व में एक ट्रायल की योजना बनाता है। इसके पहले काम हैं: नाश्ते के कमरे का रास्ता बताना, खुलने का समय बताना और सामान रखने के निर्देश देना। स्टाफ़ पहले से तैयार उदाहरण इस्तेमाल करता है। बुकिंग, भुगतान विवरण, पासपोर्ट की तस्वीरें और आपात स्थितियाँ ट्रायल से बाहर रखी जाती हैं।
तय करें कि टैबलेट को क्या करना है
मैनेजर एक छोटी ज़रूरत लिखता है: स्टाफ़ का कोई सदस्य तय भाषा चुन सके, एक रोज़मर्रा का निर्देश समझा सके, जवाब जाँच सके और सेशन खत्म कर सके। इसके बाद स्टाफ़ का अगला सदस्य तय होम स्क्रीन से शुरुआत कर सके।
यह टीम का स्वीकृति नियम है, यह दावा नहीं कि कोई डिवाइस इसे पहले से पूरा करता है। होटल सप्लायर से ज़रूरी हार्डवेयर, ऐप्लिकेशन और कॉन्फ़िगरेशन बताने को कहता है। वह यह भी पूछता है कि किन कामों के लिए इंटरनेट कनेक्शन या लोकल सर्वर चाहिए।
Vavus हर प्रोजेक्ट के हिसाब से हार्डवेयर और सॉफ़्टवेयर कॉन्फ़िगरेशन देता है। Vavus OS चुने हुए ऐप्लिकेशन, ब्रांडिंग और डिवाइस सेटिंग्स को एक साथ ला सकता है। सटीक सेटअप की पुष्टि के लिए होटल को अपना प्रस्ताव और अपना पायलट चाहिए होगा।
अभ्यास के लिए कुछ छोटी बातचीत तैयार करें
दो कर्मचारी रिसेप्शनिस्ट और आगंतुक की भूमिका निभाते हैं। वे काल्पनिक जानकारी और हर बार वही छोटी स्क्रिप्ट इस्तेमाल करते हैं। भाषा जानने वाला एक सक्षम व्यक्ति जाँचता है कि अनुवाद किया गया निर्देश इच्छित अर्थ बनाए रखता है या नहीं।
एक स्क्रिप्ट में पूछा जाता है कि नाश्ता कहाँ परोसा जाता है। दूसरी में पूछा जाता है कि सामान कब तक ले जाना है। तीसरी में एक अस्पष्ट शब्द है, ताकि रिसेप्शनिस्ट को आगे सवाल पूछना पड़े। स्टाफ़ संख्याएँ और समय सीधे जाँचता है। वे धाराप्रवाह बोले गए जवाब को सही अनुवाद का सबूत नहीं मानते।
टीम यह भी जाँचती है कि क्या दोनों लोग बिना असुविधाजनक ढंग से हाथ बढ़ाए स्क्रीन पढ़ सकते हैं। वे लॉबी के सामान्य शोर में ऑडियो का परीक्षण करते हैं। अगर कोई टाइप किया गया टेक्स्ट पसंद करता है, तो स्टाफ़ उस तरीके को अलग से जाँचता है।
अगला सेशन शुरू होने से पहले पिछला सेशन खत्म करें
टीम सेशन खत्म करने को एक अलग परीक्षण बनाती है। एक रिसेप्शनिस्ट अभ्यास बातचीत पूरी करता है और तय चरणों का पालन करता है। इसके बाद अगला परीक्षक स्क्रीन, हाल की बातचीत वाला व्यू और आम यूज़र्स के लिए उपलब्ध हर दूसरा हिस्सा जाँचता है।
सवाल साफ़ है: क्या वह व्यक्ति पिछले सेशन की सामग्री देख सकता है? अगर जवाब हाँ है, तो टीम सटीक रास्ता दर्ज करती है और कॉन्फ़िगरेशन या प्रक्रिया की समीक्षा होने तक साझा इस्तेमाल का वह परीक्षण रोक देती है।
वे यह भी पूछते हैं कि बातचीत की सामग्री कहाँ स्टोर होती है, कितने समय तक रहती है और उस तक किसकी पहुँच है। ऐप बंद कर देना इस बात का सबूत नहीं है कि स्टोर की गई सामग्री हटा दी गई है। सप्लायर को असल व्यवहार समझाना होगा। होटल को तय करना होगा कि यह उसके नियमों पर खरा उतरता है या नहीं।
शिफ़्ट बदलने का अभ्यास करें
जाने वाला कर्मचारी टैबलेट को उसकी तय जगह पर वापस रखता है, चार्जिंग जाँचता है और कोई भी खुली समस्या बताता है। आने वाला कर्मचारी स्टार्ट स्क्रीन, चुनी गई भाषा और कनेक्शन की स्थिति जाँचता है। काम के लिए टैबलेट इस्तेमाल करने से पहले वह एक तैयार वाक्य चलाकर देखता है।
मैनेजर हैंडओवर का एक छोटा रिकॉर्ड रखता है। उसमें डिवाइस, सॉफ़्टवेयर वर्शन, चार्ज की जाँच और अनसुलझी खराबियाँ दर्ज होती हैं। उसमें आगंतुकों की बातचीत या निजी जानकारी नहीं होती। स्टाफ़ का एक नामित सदस्य खराबियों की सूची और डिवाइस को इस्तेमाल से हटाने के फ़ैसले के लिए ज़िम्मेदार होता है।
टीम यह क्रम किसी दूसरे कर्मचारी के साथ दोहराती है। अगर सफलता किसी एक व्यक्ति की याददाश्त पर निर्भर है, तो वे निर्देशों को बेहतर बनाते हैं और फिर से परीक्षण करते हैं।
कनेक्शन टूटने की स्थिति भी शामिल करें
एक नियंत्रित अभ्यास सेशन के दौरान स्टाफ़ यह परीक्षण करता है कि ज़रूरी कनेक्शन उपलब्ध न होने पर तय व्यवहार क्या है। वे पहले से तैयार टेक्स्ट इस्तेमाल करते हैं, किसी मेहमान का असली अनुरोध नहीं। वे दर्ज करते हैं कि कौन-से फ़ंक्शन अब भी चलते हैं और कौन-से रुक जाते हैं।
ऑफ़लाइन ज़रूरत की सटीक परिभाषा होनी चाहिए। जो फ़ंक्शन किसी आंतरिक सर्वर का इस्तेमाल करता है, उसे फिर भी होटल के लोकल नेटवर्क की ज़रूरत हो सकती है। जब तक ज़रूरी भाषाएँ और फ़ंक्शन उसी हार्डवेयर पर इंस्टॉल और टेस्ट न हो जाएँ, टीम को ऑफ़लाइन स्पीच अनुवाद का वादा नहीं करना चाहिए।
वैकल्पिक तरीका सरल भाषा में लिखा जाता है: रुकें, समस्या समझाएँ और होटल का स्वीकृत विकल्प इस्तेमाल करें। स्टाफ़ को पता होना चाहिए कि कब किसी सहकर्मी को या भाषा संबंधी मदद के किसी दूसरे उपयुक्त स्रोत को बुलाना है।
रिकॉर्ड के आधार पर रोलआउट का फ़ैसला करें
यह उदाहरण फ़ैसले की एक चेकलिस्ट के साथ खत्म होता है, किसी गढ़ी हुई सफलता की कहानी के साथ नहीं। क्या स्टाफ़ तय काम पूरे कर सकता है? क्या वे सेशन सही तरह से खत्म कर सकते हैं? क्या अगली शिफ़्ट काम शुरू कर सकती है? क्या कनेक्शन की सीमाएँ, डेटा का प्रबंधन, सपोर्ट और लागत स्पष्ट हैं?
अगर कोई जवाब अनिश्चित है, तो विस्तार से पहले होटल दायरा छोटा करता है या सेटअप बदलता है। एक छोटा सफल डेमो सबूत का सिर्फ़ एक हिस्सा है।
ऐसे ही किसी पायलट पर बात करने के लिए Vavus को अपने रोज़मर्रा के काम, ज़रूरी भाषाएँ, मौजूदा डिवाइस मॉडल और सर्विस पॉइंट की अनुमानित संख्या भेजें। शुरुआती पूछताछ में निजी रिकॉर्ड और गोपनीय दस्तावेज़ शामिल न करें।