जेव्हा मध्यस्थच अडथळा ठरतो

जेव्हा मध्यस्थच अडथळा ठरतो

एका प्रवाशाने अलीकडेच AirAsia MOVE प्लॅटफॉर्मद्वारे IndiGo चे विमान बुक केले होते. जेव्हा योजना बदलल्या, तेव्हा त्याने सहल रद्द करण्याची विनंती केली. विमान कंपनीने त्याला संमती दिली. गोष्ट तिथेच संपायला हवी होती. पण त्याऐवजी, प्लॅटफॉर्मनेच रद्द करण्याची प्रक्रिया करण्यास नकार दिला, ज्यामुळे तो प्रवासी दोन कंपन्यांच्या मधल्या दरीमध्ये अडकून पडला. त्याने आपला संताप सार्वजनिक केला आणि या प्रणालीला निरुपयोगी आणि मूर्ख म्हटले. त्याचा राग तीव्र होता, परंतु तो अशा समस्येकडे निर्देश करत होता ज्याचा परिणाम अशा लाखो प्रवाशांवर होतो जे आपले जीवन सोपे करण्यासाठी ॲग्रीगेटर्सवर (aggregators) अवलंबून असतात.

ही घटना ऑनलाइन प्रवासाच्या अफाट यंत्रणेतील एक छोटीशी घटना आहे, तरीही ती एक मोठा इशारा देते. विमान कंपन्यांच्या वेबसाइट्स, पेमेंट गेटवे आणि कन्फर्मेशन कोड्सचा गोंधळ टाळण्यासाठी आपण हे ॲप्स डाउनलोड करतो. आपण मध्यस्थाकडून कामे सोपी करण्याची अपेक्षा करतो, अडथळे निर्माण करण्याची नाही. जेव्हा एखादे प्लॅटफॉर्म विमान कंपनीने आधीच मंजूर केलेली रद्द करण्याची प्रक्रिया पूर्ण करू शकत नाही, तेव्हा ते त्याचे एकमेव खरे काम करण्यात अपयशी ठरते: वापरकर्त्याकडून सेवा प्रदात्याकडे आणि पुन्हा वापरकर्त्याकडे माहिती विश्वासार्हतेने पोहोचवणे.

काय बिघडले

या प्रकरणाचा तपशील अगदी साधा आहे आणि तेच याला चिंताजनक बनवते. प्रवाशाने कोणत्याही लपलेल्या शुल्कावर (hidden fee) वाद घातला नाही किंवा पॉलिसीमधील त्रुटीबद्दल भांडण केले नाही. त्याने एक सामान्य कृती केली—विमान रद्द करणे—आणि त्याला अशा त्रुटीचा सामना करावा लागला जी अस्तित्वातच नसायला हवी होती. IndiGo ने रद्द करण्याची विनंती स्वीकारली, पण AirAsia MOVE ने नाही. याचा परिणाम म्हणजे दोन्ही बाजूंनी नुकसान झालेली परिस्थिती निर्माण झाली. प्रवाशाचा वेळ आणि मानसिक शांतता गेली, तर प्लॅटफॉर्मची विश्वासार्हता कमी झाली.

अशा प्रकारची त्रुटी सहसा प्रवाशांना न दिसणाऱ्या तांत्रिक रचनेच्या खोलवर घडते. ऑनलाइन ट्रॅव्हल एजन्सी आणि सुपरॲप्स (superapps) विमान कंपन्यांचा डेटा त्यांच्या स्वतःच्या सर्व्हरवर साठवून ठेवत नाहीत. ते application programming interfaces, किंवा APIs द्वारे विमान कंपन्यांशी जोडलेले असतात, जे डेटाची देवाणघेवाण करतात. जेव्हा तुम्ही “cancel” वर टॅप करता, तेव्हा तुमची विनंती तुमच्या फोनवरून ॲग्रीगेटरच्या बॅकएंडकडे (backend) आणि तिथून विमान कंपनीच्या रिझर्व्हेशन सिस्टमकडे जाते. विमान कंपनी बुकिंगची स्थिती अपडेट करते आणि कन्फर्मेशन पाठवते. ॲग्रीगेटरने ती बदल त्वरित प्रतिबिंबित करणे आणि तुमचा रिफंड किंवा ट्रॅव्हल क्रेडिट्सची प्रक्रिया करणे अपेक्षित असते.

त्या साखळीमध्ये कुठेतरी AirAsia MOVE मध्ये अडथळा निर्माण झाला. कदाचित API ने IndiGo च्या सिस्टममधून अपडेट केलेली स्थिती मिळवण्यात (poll) अपयश आले असावे. कदाचित ॲपच्या अंतर्गत लॉजिकमध्ये असा एखादा नियम (hardcoded rule) असावा ज्याने विमान कंपनीच्या प्रतिसादाला डावलले. कदाचित कस्टमर सर्विस एजंट्सना त्यांच्या स्क्रीनवर ही तफावत दिसत असावी, परंतु रद्द करण्याची प्रक्रिया पूर्ण करण्यासाठी त्यांच्याकडे आवश्यक अधिकार (permissions) नसतील. आम्हाला नेमकी त्रुटी (bug) माहित नाही, परंतु परिणाम मात्र स्पष्ट आहे: एक माणूस सॉफ्टवेअर लूपमध्ये अडकला होता, आणि ज्या व्यवहाराची रद्द करण्याची संमती सर्व पक्षांनी दिली होती, तो व्यवहार रद्द करण्यास तो असमर्थ ठरला.

कोडमधील सुधारणांपेक्षा विश्वास वेगाने का कमी होतो

प्रवासी क्लिष्ट इंटरफेस सहन करतात. ते लोडिंगचा संथ वेगही सहन करतात. परंतु जेव्हा पैसा आणि नियोजनाचा प्रश्न येतो, तेव्हा ते हतबलता सहन करत नाहीत. विमान रद्द करणे ही कोणतीही किरकोळ विनंती नसते. सहसा ही विनंती एखाद्या संकटातून येते—वैद्यकीय समस्या, कौटुंबिक आणीबाणी किंवा कामाचा अचानक आलेला ताण. वापरकर्ता आधीच तणावाखाली असतो. बॅकएंडमधील गुंतागुंत हाताळून तो तणाव कमी करणे ही ॲपची भूमिका असते. त्याऐवजी जेव्हा ते नवीन अडथळा निर्माण करते, तेव्हा त्याचा भावनिक परिणाम खूप मोठा असतो.

म्हणूनच त्या प्रवाशाने व्यक्त केलेला संताप महत्त्वाचा आहे. त्याने गमावलेल्या लॉयल्टी पॉईंटबद्दल किंवा उशिरा आलेल्या नोटिफिकेशनबद्दल तक्रार केली नाही. त्याने प्लॅटफॉर्मला निरुपयोगी म्हटले कारण ज्या क्षणी त्याला त्याची सर्वात जास्त गरज होती, त्याच वेळी प्लॅटफॉर्मने त्याच्या वैध विनंतीला अडथळा आणला. डिजिटल सेवांवरील विश्वास या कल्पनेवर आधारलेला असतो की परिस्थिती बदलली तरी सिस्टम तुमच्या हेतूचा आदर करेल. या आश्वासनातील एकही मोडतोड दहा यशस्वी बुकिंग्सपेक्षा जास्त नुकसान करू शकते.

ही समस्या अनेक ट्रॅव्हल प्लॅटफॉर्म्सच्या रचनेतील एक धोरणात्मक त्रुटी (strategic blind spot) देखील समोर आणते. इंजिनिअरिंग टीम्स अनेकदा फ्रंट एंडवर (front end) अधिक लक्ष केंद्रित करतात: जलद शोध, आकर्षक कॅलेंडर, वन-टॅप चेकआउट, वैयक्तिकृत ऑफर्स. हे असे फीचर्स आहेत ज्यामुळे ॲप डाउनलोड्स वाढतात. परंतु बुकिंगनंतरच्या प्रक्रिया—बदल, रद्द करणे, रिफंड—यांकडे दुय्यम मानले जाते. त्यांना जुने APIs, कमी देखरेख आणि मर्यादित पर्यायांचा सामना करावा लागतो. परंतु नेमक्या याच ठिकाणी वापरकर्त्यांना समजते की एखादे ॲप खरोखर उपयुक्त साधन आहे की केवळ एक चकचकीत ब्रोशर.

ट्रॅव्हल प्लॅटफॉर्म्सनी कोणत्या गोष्टींवर लक्ष केंद्रित करणे आवश्यक आहे

ग्राहक आणि विमान कंपन्यांच्या मधोमध असलेल्या कोणत्याही कंपनीसाठी येथे स्पष्ट धडे आहेत.

रद्द करण्याची प्रक्रिया बुकिंग इतकीच सोपी बनवा. जर एखादा वापरकर्ता तीन टॅप्समध्ये सीट आरक्षित करू शकत असेल, तर चॅटबॉट्स, लपलेले मेनू आणि असमर्थित फॉर्म्सच्या चक्रव्यूहात अडकल्याशिवाय त्यांना ते रद्द करता आले पाहिजे. रद्द करण्याची प्रक्रिया स्पष्ट असावी, शुल्काबाबत प्रामाणिक असावी आणि प्रवाशांना वापरता न येणारे आरक्षण ठेवण्यासाठी अपराधी वाटेल असे किंवा गोंधळात टाकणारे 'डार्क पॅटर्न' (dark patterns) त्यात नसावेत.

प्रत्यक्षात काम करतील असे 'मॅन्युअल ओव्हरराइड्स' (manual overrides) तयार करा. ऑटोमेशन (स्वयंचलन) जोपर्यंत यशस्वी होते तोपर्यंत उत्तम असते. जेव्हा API मध्ये संघर्ष किंवा सिंक (sync) त्रुटी येते, तेव्हा ग्राहक सेवा प्रतिनिधींकडे त्यात हस्तक्षेप करण्यासाठी आवश्यक अधिकार आणि इंटरफेस असणे आवश्यक आहे. अनेक प्लॅटफॉर्म्स मानवी हस्तक्षेपासाठी कोणतेही मार्ग न ठेवता पूर्णपणे स्वयंचलित किल्ले तयार करतात. परिणामी, प्रतिनिधींना फक्त स्क्रिप्ट वाचून सतत माफी मागावी लागते आणि त्यांनी तक्रारी अशा ठिकाणी नोंदवाव्या लागतात जिथे त्या कधीच सुटत नाहीत. एक उपयुक्त ओव्हरराइड म्हणजे प्रतिनिधी एअरलाईनची मंजुरी पाहू शकेल, ती अडकलेल्या बुकिंगशी जुळवून पाहू शकेल आणि रिअल-टाइममध्ये रद्द करण्याची प्रक्रिया पूर्ण करू शकेल.

सॉफ्टवेअर एअरलाईनच्या वास्तविक स्थितीशी सुसंगत ठेवा. ट्रॅव्हल प्लॅटफॉर्म्सनी बॅच अपडेट्स आणि संथ पोलिंग सायकलपासून दूर जाण्याची गरज आहे. जर एअरलाईनने तिकीट रद्द करण्यायोग्य, परतावा देण्यायोग्य किंवा पुनर्वेळापत्रक (rescheduled) म्हणून मार्क केले असेल, तर ॲग्रीगेटरला ते तासांत नाही तर मिनिटांत समजले पाहिजे. यासाठी मजबूत webhook आर्किटेक्चर, अयशस्वी हँडशेक्ससाठी 'रिट्राय लॉजिक' (retry logic) आणि वापरकर्त्याला समजण्यापूर्वीच विसंगती दर्शवणारी 'रिकॉन्सिलिएशन जॉब्स' (reconciliation jobs) आवश्यक आहेत. प्लॅटफॉर्मला त्याच्या स्वतःच्या उत्पादनाच्या स्थितीबद्दल सर्वात शेवटी माहिती मिळणे कधीही योग्य नाही.

प्रवासी आता काय करू शकतात

जोपर्यंत उद्योग या त्रुटी दूर करत नाही, तोपर्यंत प्रवाशांनी स्वतःचे संरक्षण करणे आवश्यक आहे. जर तुम्ही AirAsia MOVE सारख्या मोठ्या ॲप्ससह कोणत्याही थर्ड-पार्टी ॲपद्वारे बुकिंग करत असाल, तर सर्व पुराव्यांचा मागोवा ठेवा. तुमच्या कन्फर्मेशन नंबरचे, रद्द करण्याच्या धोरणांचे आणि एअरलाईनकडून झालेल्या कोणत्याही संवादाचे स्क्रीनशॉट काढून ठेवा. खरेदी करण्यापूर्वी एअरलाईनचे स्वतःचे धोरण जाणून घ्या; काही एअरलाईन्स भागीदारांद्वारे विकल्या गेलेल्या तिकिटांसाठी देखील त्यांच्या वेबसाइटद्वारे थेट बदल करण्याची परवानगी देतात. जर ॲप अयशस्वी ठरले, तर थेट एअरलाईनशी संपर्क साधा. जेव्हा सार्वजनिक पोस्ट्स प्रसिद्ध होतात, तेव्हा कंपन्या खाजगी सपोर्ट चॅनेलपेक्षा वेगाने काम करतात. आणि जर मोठी रक्कम अडकली असेल, तर ग्राहक संरक्षण मंच किंवा चॅजबॅक (chargeback) यंत्रणेद्वारे तक्रार करण्यास संकोच करू नका.

मुख्य निष्कर्ष

ग्राहक अनुभव (Customer experience) ही कोड लिहिल्यानंतर लावलेली केवळ एक वरवरची चमक नाही. जेव्हा परिस्थिती कठीण होते, तेव्हा कोडने योग्यरित्या काम करणे म्हणजे ग्राहक अनुभव होय. जे बुकिंग प्लॅटफॉर्म विमान रद्द करू शकत नाही, ते रिव्हर्स गिअर नसलेल्या कारसारखे आहे. ते पुढे उत्तम प्रकारे जाऊ शकते, पण लवकर किंवा उशिरा तुम्हाला मागे हटण्याची गरज पडेलच.

प्रवाशांना जादू नको असते. त्यांना अशी साधने हवी आहेत जी त्यांना दिशाभूल न करता मूलभूत आदेशांची अंमलबजावणी करतील. IndiGo ने आधीच स्वीकारलेले रद्द करण्याचे विनंती मान्य करण्यात AirAsia MOVE चे अपयश हे एक स्मरणपत्र आहे की, जेव्हा संपूर्ण प्रक्रिया (pipeline) व्यवस्थित काम करते, तेव्हाच सोय खऱ्या अर्थाने 'सोय' ठरते. जोपर्यंत ट्रॅव्हल प्लॅटफॉर्म्स खरेदीनंतरच्या विश्वासार्हतेमध्ये (post-purchase reliability) तितकाच मोठा गुंतवणूक करत नाहीत जितकी ते ग्राहकांना आकर्षित करण्यासाठी (acquisition funnels) करतात, तोपर्यंत वापरकर्ते सावध राहतील. आणि त्यांनी सावध राहिलेच पाहिजे.