जब बिचौलिया ही दीवार बन जाए
हाल ही में एक यात्री ने AirAsia MOVE प्लेटफॉर्म के माध्यम से IndiGo की एक फ्लाइट बुक की। जब योजनाएं बदलीं, तो उसने यात्रा रद्द करने का अनुरोध किया। एयरलाइन मान गई। कहानी यहीं खत्म हो जानी चाहिए थी। इसके बजाय, प्लेटफॉर्म ने खुद रद्दीकरण (cancellation) की प्रक्रिया को करने से इनकार कर दिया, जिससे यात्री दो कंपनियों के बीच के अंतर में फंस गया। उसने अपनी हताशा सार्वजनिक रूप से व्यक्त की और सिस्टम को बेकार और मूर्ख बताया। उसका गुस्सा जायज था, लेकिन यह उस समस्या की ओर इशारा करता है जो उन लाखों यात्रियों को प्रभावित करती है जो अपने जीवन को सरल बनाने के लिए एग्रीगेटर्स (aggregators) पर भरोसा करते हैं।
यह घटना ऑनलाइन यात्रा की विशाल मशीनरी में एक छोटी सी घटना है, फिर भी यह एक बड़ी चेतावनी देती है। हम एयरलाइन वेबसाइटों, पेमेंट गेटवे और कन्फर्मेशन कोड के झंझट से बचने के लिए इन ऐप्स को डाउनलोड करते हैं। हम उम्मीद करते हैं कि बिचौलिया काम को आसान बनाएगा, न कि उसमें बाधा डालेगा। जब कोई प्लेटफॉर्म उस रद्दीकरण को पूरा नहीं कर पाता जिसे एयरलाइन पहले ही मंजूरी दे चुकी है, तो वह अपने एकमात्र वास्तविक काम में विफल हो जाता है: उपयोगकर्ता से सेवा प्रदाता तक और वापस जानकारी को ईमानदारी से पहुँचाना।
क्या गड़बड़ हुई
इस मामले का विवरण सीधा है, और यही बात इसे चिंताजनक बनाती है। यात्री ने किसी छिपे हुए शुल्क पर विवाद नहीं किया या किसी पॉलिसी के लूपहोल (loophole) से नहीं लड़ा। उसने एक मानक कार्य किया—फ्लाइट रद्द करना—और एक ऐसी त्रुटि का सामना किया जो होनी ही नहीं चाहिए थी। IndiGo ने रद्दीकरण स्वीकार कर लिया। AirAsia MOVE ने नहीं। परिणाम एक क्लासिक 'हार-हार' (lose-lose) वाली स्थिति थी। यात्री ने अपना समय और मानसिक शांति खो दी। प्लेटफॉर्म ने अपनी विश्वसनीयता खो दी।
इस तरह की विफलता आमतौर पर उस तकनीकी ढांचे (plumbing) में गहराई में होती है जिसे यात्री कभी नहीं देख पाते। ऑनलाइन ट्रैवल एजेंसियां और सुपरऐप्स अपने सर्वर पर एयरलाइन इन्वेंट्री स्टोर नहीं करते हैं। वे एप्लिकेशन प्रोग्रामिंग इंटरफेस, या APIs के माध्यम से एयरलाइनों से जुड़ते हैं, जो डेटा को आगे-पीछे भेजते हैं। जब आप “cancel” पर टैप करते हैं, तो आपका अनुरोध आपके फोन से एग्रीगेटर के बैकएंड तक जाता है, और फिर एयरलाइन के रिजर्वेशन सिस्टम तक पहुँचता है। एयरलाइन बुकिंग स्टेटस अपडेट करती है और एक कन्फर्मेशन भेजती है। एग्रीगेटर से यह अपेक्षा की जाती है कि वह उस बदलाव को तुरंत प्रतिबिंबित करे और आपके रिफंड या ट्रैवल क्रेडिट की प्रक्रिया शुरू करे।
कहीं न कहीं उस श्रृंखला में, AirAsia MOVE अटक गया। शायद API, IndiGo के सिस्टम से अपडेटेड स्टेटस प्राप्त करने में विफल रहा। शायद ऐप के आंतरिक लॉजिक में कोई ऐसा हार्डकोडेड नियम था जिसने एयरलाइन की प्रतिक्रिया को दरकिनार कर दिया। शायद कस्टमर सर्विस एजेंट अपनी स्क्रीन पर विसंगति देख पा रहे थे लेकिन रद्दीकरण को जबरन लागू करने के लिए उनके पास अनुमति नहीं थी। हम सटीक बग (bug) नहीं जानते, लेकिन हम परिणाम जानते हैं: एक इंसान सॉफ्टवेयर लूप में फंस गया था, जो उस लेनदेन को रद्द करने में असमर्थ था जिसे रद्द करने के लिए सभी पक्ष सहमत थे।
भरोसा कोड सुधारों की तुलना में तेजी से क्यों टूटता है
यात्री खराब इंटरफेस को सहन कर लेते हैं। वे धीमी लोडिंग को सहन कर लेते हैं। लेकिन जब पैसा और योजनाएं दांव पर हों, तो वे लाचारी को सहन नहीं करेंगे। रद्दीकरण कोई मामूली अनुरोध नहीं है। यह आमतौर पर किसी संकट के बाद होता है—कोई चिकित्सा समस्या, पारिवारिक आपात स्थिति, या अचानक काम का टकराव। उपयोगकर्ता पहले से ही तनाव में होता है। ऐप की भूमिका बैकएंड की जटिलता को संभालकर उस तनाव को कम करना है। जब यह इसके बजाय एक नई बाधा खड़ी कर देता है, तो इसका भावनात्मक प्रभाव बहुत अधिक होता है।
यही कारण है कि यात्री का सार्वजनिक आक्रोश महत्वपूर्ण है। उसने किसी गायब लॉयल्टी पॉइंट या देरी से आए पुश नोटिफिकेशन के बारे में शिकायत नहीं की। उसने प्लेटफॉर्म को बेकार बताया क्योंकि जिस क्षण उसे इसकी सबसे अधिक आवश्यकता थी, उसने सक्रिय रूप से एक वैध अनुरोध को रोक दिया। डिजिटल सेवाओं में भरोसा इस विश्वास पर टिका होता है कि परिस्थितियां बदलने पर भी सिस्टम आपके इरादे का सम्मान करेगा। उस वादे का एक भी उल्लंघन दस सफल बुकिंगों की तुलना में अधिक नुकसान पहुंचाता है।
यह समस्या यह भी उजागर करती है कि कई ट्रैवल प्लेटफॉर्म कैसे बनाए जाते हैं, इसमें एक रणनीतिक कमी (blind spot) है। इंजीनियरिंग टीमें अक्सर फ्रंट एंड पर संसाधन लगाती हैं: तेज़ खोज, सुंदर कैलेंडर, वन-टैप चेकआउट, व्यक्तिगत सौदे। ये वे विशेषताएं हैं जो डाउनलोड बढ़ाती हैं। बुकिंग के बाद के कार्यों—बदलाव, रद्दीकरण, रिफंड—को बाद की सोच (afterthoughts) के रूप में माना जाता है। उन्हें पुराने APIs, कम निगरानी और कम विकल्प मिलते हैं। लेकिन यही वह जगह है जहाँ उपयोगकर्ता यह पता लगाते हैं कि कोई ऐप वास्तव में एक उपयोगी उपकरण है या सिर्फ एक चमकदार ब्रोशर।
ट्रैवल प्लेटफॉर्म्स को किन चीजों में सही होना चाहिए
ग्राहकों और एयरलाइनों के बीच काम करने वाली किसी भी कंपनी के लिए यहाँ स्पष्ट सबक हैं।
रद्दीकरण (cancellations) को बुकिंग जितना ही सरल बनाएं। यदि कोई उपयोगकर्ता तीन टैप में सीट आरक्षित कर सकता है, तो उसे चैटबॉट्स, छिपे हुए मेनू और असमर्थित फॉर्मों की भूलभुलैया में फंसे बिना इसे रद्द करने में सक्षम होना चाहिए। रद्दीकरण की प्रक्रिया स्पष्ट होनी चाहिए, शुल्कों के बारे में ईमानदार होनी चाहिए, और उन 'डार्क पैटर्न्स' (dark patterns) से मुक्त होनी चाहिए जो यात्रियों को दोषी महसूस कराते हैं या भ्रमित करते हैं ताकि वे ऐसी बुकिंग बनाए रखें जिसका वे उपयोग नहीं कर सकते।
ऐसे मैनुअल ओवरराइड (manual overrides) बनाएं जो वास्तव में काम करें। ऑटोमेशन तब तक अद्भुत है जब तक कि वह विफल न हो जाए। जब कोई API रिटर्न संघर्ष या सिंक एरर (sync error) होता है, तो कस्टमर सर्विस एजेंटों के पास हस्तक्षेप करने का अधिकार और इंटरफ़ेस होना चाहिए। बहुत से प्लेटफॉर्म पूरी तरह से स्वचालित किले डिजाइन करते हैं जिनमें मानवीय हस्तक्षेप के लिए कोई रास्ता नहीं होता। एजेंट अंततः स्क्रिप्ट पढ़ते रह जाते हैं, अंतहीन माफी मांगते हैं, और टिकटों को ऐसे ब्लैक होल में डाल देते हैं जहाँ से कोई जवाब नहीं आता। एक उपयोगी ओवरराइड का अर्थ है कि एक एजेंट एयरलाइन की मंजूरी देख सके, उसे अटकी हुई बुकिंग से मिला सके, और वास्तविक समय (real time) में रद्दीकरण को पूरा कर सके।
सॉफ्टवेयर को एयरलाइन की वास्तविकता के साथ तालमेल में रखें। ट्रैवल प्लेटफॉर्म्स को बैच अपडेट और धीमे पोलिंग साइकिल (polling cycles) से दूर होने की जरूरत है। यदि कोई एयरलाइन टिकट को रद्द करने योग्य (cancellable), रिफंडेबल (refundable), या रीशेड्यूल (rescheduled) के रूप में चिह्नित करती है, तो एग्रीगेटर को घंटों के बजाय मिनटों के भीतर पता चल जाना चाहिए। इसके लिए मजबूत वेबहुक आर्किटेक्चर (webhook architecture), विफल हैंडशेक के लिए रिट्राय लॉजिक (retry logic), और रिकॉन्सिलिएशन जॉब्स (reconciliation jobs) की आवश्यकता होती है जो उपयोगकर्ता द्वारा पता लगाने से पहले ही विसंगतियों को चिह्नित कर दें। प्लेटफॉर्म को अपने ही उत्पाद की स्थिति जानने वाला अंतिम व्यक्ति कभी नहीं होना चाहिए।
यात्री अभी क्या कर सकते हैं
जब तक उद्योग इन कमियों को दूर नहीं करता, यात्रियों को खुद की सुरक्षा करने की आवश्यकता है। यदि आप AirAsia MOVE जैसे प्रमुख ऐप्स सहित किसी भी थर्ड-पार्टी ऐप के माध्यम से बुकिंग कर रहे हैं, तो प्रमाण (paper trail) सुरक्षित रखें। अपने कन्फर्मेशन नंबर, रद्दीकरण नीतियों और एयरलाइन से होने वाले किसी भी संचार का स्क्रीनशॉट लें। खरीदने से पहले एयरलाइन की अपनी नीति को जानें; कुछ एयरलाइंस पार्टनर्स द्वारा बेचे गए टिकटों के लिए भी सीधे अपनी वेबसाइट के माध्यम से बदलाव की अनुमति देती हैं। यदि ऐप विफल हो जाता है, तो सीधे एयरलाइन से संपर्क करें। जब सार्वजनिक पोस्ट (public posts) चर्चा में आते हैं, तो कंपनियां निजी सहायता चैनलों की तुलना में तेजी से काम करती हैं। और यदि बड़ी राशि फंसी हुई है, तो उपभोक्ता संरक्षण मंचों (consumer protection forums) या चार्जबैक तंत्र (chargeback mechanisms) के माध्यम से मामला आगे बढ़ाने में संकोच न करें।
असली निष्कर्ष
कस्टमर एक्सपीरियंस (Customer experience) कोड लिखे जाने के बाद लगाई जाने वाली पॉलिश की कोई परत नहीं है। यह तब कोड का सही ढंग से काम करना है जब परिस्थितियाँ कठिन हो जाएं। एक बुकिंग प्लेटफॉर्म जो उड़ान रद्द नहीं कर सकता, वह बिना रिवर्स गियर वाली कार की तरह है। यह आगे तो बहुत खूबसूरती से चल सकती है, लेकिन देर-सबेर आपको पीछे हटने की जरूरत पड़ेगी ही।
यात्री जादू नहीं मांगते। वे ऐसे टूल्स मांगते हैं जो उन्हें भ्रमित (gaslighting) किए बिना बुनियादी कमांड का पालन करें। AirAsia MOVE द्वारा उस रद्दीकरण को स्वीकार न करना जिसे IndiGo पहले ही स्वीकार कर चुका था, यह याद दिलाता है कि सुविधा तभी वास्तविक होती है जब पूरी प्रक्रिया (pipeline) सही ढंग से काम करती है। जब तक ट्रैवल प्लेटफॉर्म्स 'अधिग्रहण फनल' (acquisition funnels) में निवेश करने जितना ही भारी निवेश 'खरीद के बाद की विश्वसनीयता' (post-purchase reliability) में नहीं करते, तब तक उपयोगकर्ता सतर्क रहेंगे। और उन्हें रहना भी चाहिए।