જ્યારે મધ્યસ્થી જ દીવાલ બની જાય

જ્યારે મધ્યસ્થી જ દીવાલ બની જાય

તાજેતરમાં એક મુસાફરે AirAsia MOVE પ્લેટફોર્મ દ્વારા IndiGo ની ફ્લાઇટ બુક કરી હતી. જ્યારે યોજનાઓ બદલાઈ, ત્યારે તેણે પ્રવાસ રદ કરવા માટે વિનંતી કરી. એરલાઇન સંમત થઈ ગઈ. વાર્તા ત્યાં જ પૂરી થઈ જવી જોઈતી હતી. તેના બદલે, પ્લેટફોર્મે પોતે જ રદ કરવાની પ્રક્રિયા કરવાનો ઇનકાર કરી દીધો, જેના કારણે મુસાફર બે કંપનીઓ વચ્ચેના અંતરાલમાં ફસાયો રહ્યો. તેણે પોતાની હતાશા જાહેર કરી અને સિસ્ટમને નકામી અને મૂર્ખ ગણાવી. તેનો ગુસ્સો તીવ્ર હતો, પરંતુ તે એક એવી સમસ્યા તરફ નિર્દેશ કરતો હતો જે લાખો મુસાફરોને અસર કરે છે જેઓ પોતાનું જીવન સરળ બનાવવા માટે એગ્રીગેટર્સ (aggregators) પર નિર્ભર છે.

આ ઘટના ઓનલાઇન ટ્રાવેલની વિશાળ મશીનરીમાં એક નાની ઘટના છે, છતાં તે એક મોટો ચેતવણીરૂપ સંદેશ આપે છે. અમે એરલાઇન વેબસાઇટ્સ, પેમેન્ટ ગેટવે અને કન્ફર્મેશન કોડ્સ વચ્ચેની ઝંઝટથી બચવા માટે આ એપ્સ ડાઉનલોડ કરીએ છીએ. અમે અપેક્ષા રાખીએ છીએ કે મધ્યસ્થી કામ સરળ બનાવે, તેને અટકાવે નહીં. જ્યારે કોઈ પ્લેટફોર્મ એવા કેન્સલેશનને અમલમાં મૂકી શકતું નથી જેને એરલાઇને પહેલેથી જ મંજૂરી આપી દીધી હોય, ત્યારે તે તેનું એકમાત્ર સાચું કામ કરવામાં નિષ્ફળ જાય છે: વપરાશકર્તાથી સર્વિસ પ્રોવાઈડર સુધી અને ફરી પાછું માહિતીને વફાદારીપૂર્વક પહોંચાડવાનું.

શું ખામી સર્જાઈ

આ કેસની વિગતો સીધી અને સરળ છે, અને તે જ બાબત તેને ચિંતાજનક બનાવે છે. મુસાફરે કોઈ છુપા ચાર્જ વિશે વિવાદ કર્યો ન હતો કે પોલિસીની ખામી સામે લડ્યા ન હતા. તેણે એક સામાન્ય પ્રક્રિયા કરી—ફ્લાઇટ રદ કરવી—અને એવી ભૂલનો સામનો કર્યો જે હોવી જ ન જોઈએ. IndiGo એ કેન્સલેશન સ્વીકાર્યું. AirAsia MOVE એ નહીં. પરિણામ એક ક્લાસિક 'લોસ-લોસ' (બંનેનું નુકસાન) પરિસ્થિતિ હતી. મુસાફરે સમય અને માનસિક શાંતિ ગુમાવી. પ્લેટફોર્મે વિશ્વસનીયતા ગુમાવી.

આ પ્રકારની નિષ્ફળતા સામાન્ય રીતે એવા ઊંડા તકનીકી માળખામાં થાય છે જે મુસાફરો ક્યારેય જોઈ શકતા નથી. ઓનલાઇન ટ્રાવેલ એજન્સીઓ અને સુપર એપ્સ એરલાઇન ઇન્વેન્ટરી તેમના પોતાના સર્વર્સ પર સંગ્રહિત કરતી નથી. તેઓ application programming interfaces, અથવા APIs દ્વારા એરલાઇન્સ સાથે જોડાય છે જે ડેટાની આપ-લે કરે છે. જ્યારે તમે “cancel” પર ટેપ કરો છો, ત્યારે તમારી વિનંતી તમારા ફોનથી એગ્રીગેટરના બેકએન્ડ (backend) પર જાય છે, અને પછી એરલાઇનની રિઝર્વેશન સિસ્ટમ પર જાય છે. એરલાઇન બુકિંગ સ્ટેટસ અપડેટ કરે છે અને કન્ફર્મેશન મોકલે છે. એગ્રીગેટરે તે ફેરફાર તરત જ દર્શાવવો જોઈએ અને તમારા રિફંડ અથવા ટ્રાવેલ ક્રેડિટ્સની પ્રક્રિયા કરવી જોઈએ.

ક્યાંક તે સાંકળમાં, AirAsia MOVE અટકી ગયું. કદાચ API એ IndiGo ની સિસ્ટમમાંથી અપડેટ થયેલ સ્ટેટસ મેળવવામાં નિષ્ફળતા અનુભવી હશે. કદાચ એપના આંતરિક લોજિકમાં કોઈ એવો હાર્ડકોડેડ (hardcoded) નિયમ હતો જેણે એરલાઇનના પ્રતિસાદને અવગણ્યો હોય. કદાચ કસ્ટમર સર્વિસ એજન્ટો તેમની સ્ક્રીન પર વિસંગતતા જોઈ શકતા હતા પરંતુ કેન્સલેશનને ફરજિયાત રીતે અમલમાં મૂકવા માટે તેમની પાસે પરવાનગી નહોતી. અમને ચોક્કસ બગ (bug) વિશે ખબર નથી, પરંતુ અમને પરિણામ ખબર છે: એક માણસ સોફ્ટવેર લૂપમાં ફસાઈ ગયો હતો, જે એવા વ્યવહારને રદ કરવામાં અસમર્થ હતો જેના માટે દરેક પક્ષ સંમત હતો.

કોડ ફિક્સ કરતા વિશ્વાસ શા માટે ઝડપથી ઘટે છે

મુસાફરો અણઘડ ઇન્ટરફેસ સહન કરે છે. તેઓ લોડ થવામાં લાગતા સમયને સહન કરે છે. પરંતુ જ્યારે પૈસા અને યોજનાઓનો સવાલ હોય ત્યારે તેઓ લાચારી સહન કરશે નહીં. કેન્સલેશન એ કોઈ ક્ષુલ્લક વિનંતી નથી. તે સામાન્ય રીતે કોઈ કટોકટી પછી આવે છે—તબીબી સમસ્યા, કૌટુંબિક ઇમરજન્સી અથવા કામમાં અચાનક આવેલો અવરોધ. વપરાશકર્તા પહેલેથી જ તણાવમાં હોય છે. એપની ભૂમિકા બેકએન્ડની જટિલતા સંભાળીને તે તણાવ ઘટાડવાની છે. જ્યારે તે તેના બદલે નવો અવરોધ ઊભો કરે છે, ત્યારે તેની ભાવનાત્મક કિંમત ઘણી વધારે હોય છે.

આથી જ મુસાફરનો આ જાહેર વિરોધ મહત્વનો છે. તેણે કોઈ લોયલ્ટી પોઈન્ટ ગુમાવવા અથવા વિલંબિત પુશ નોટિફિકેશન વિશે ફરિયાદ કરી ન હતી. તેણે પ્લેટફોર્મને નકામું ગણાવ્યું કારણ કે, જ્યારે તેને તેની સૌથી વધુ જરૂર હતી, ત્યારે તેણે સક્રિયપણે એક કાયદેસરની વિનંતીને રોકી દીધી હતી. ડિજિટલ સેવાઓમાં વિશ્વાસ એ માન્યતા પર બનેલો છે કે પરિસ્થિતિ બદલાય તો પણ સિસ્ટમ તમારા ઈરાદાનું સન્માન કરશે. તે વચનનું એક પણ ભંગ દસ સરળ બુકિંગ્સ દ્વારા સુધારી શકાય તેટલું નુકસાન કરી શકે છે.

આ સમસ્યા એ પણ દર્શાવે છે કે ઘણા ટ્રાવેલ પ્લેટફોર્મ કેવી રીતે બનાવવામાં આવે છે તેમાં એક વ્યૂહાત્મક ખામી (blind spot) છે. એન્જિનિયરિંગ ટીમો ઘણીવાર ફ્રન્ટ એન્ડ (front end) માં સંસાધનો ખર્ચતી હોય છે: ઝડપી સર્ચ, સુંદર કેલેન્ડર, વન-ટેપ ચેકઆઉટ, પર્સનલાઇઝ્ડ ડીલ્સ. આ એવા ફીચર્સ છે જે ડાઉનલોડ્સ વધારે છે. બુકિંગ પછીની કામગીરી—ફેરફાર, કેન્સલેશન, રિફંડ—તેમને ગૌણ ગણવામાં આવે છે. તેમને જૂના APIs, ઓછું મોનિટરિંગ અને ઓછા ફોલબેક (fallback) વિકલ્પો મળે છે. પરંતુ તે જ જગ્યા છે જ્યાં વપરાશકર્તાઓ શોધી કાઢે છે કે એપ ખરેખર એક સાચું સાધન છે કે માત્ર એક ચમકતું બ્રોશર છે.

ટ્રાવેલ પ્લેટફોર્મ્સ માટે શું સાચું કરવું જરૂરી છે

ગ્રાહકો અને એરલાઇન્સ વચ્ચે રહેતી કોઈપણ કંપની માટે અહીં સ્પષ્ટ પાઠ છે.

રદ કરવાની પ્રક્રિયાને બુકિંગ જેટલી જ સરળ બનાવો. જો વપરાશકર્તા ત્રણ ટેપમાં સીટ રિઝર્વ કરી શકતા હોય, તો તેઓએ ચેટબોટ્સ, છુપાયેલા મેનુઓ અને અસમર્થ ફોર્મ્સના જાળમાં ફસાયા વગર તેને રદ કરવાની ક્ષમતા હોવી જોઈએ. રદ કરવાની પ્રક્રિયા (cancellation flow) સ્પષ્ટ હોવી જોઈએ, ફી વિશે પ્રમાણિક હોવી જોઈએ, અને એવા 'ડાર્ક પેટર્ન્સ'થી મુક્ત હોવી જોઈએ જે મુસાફરોને અપરાધિત અનુભવ કરાવીને અથવા મૂંઝવણમાં મૂકીને એવી રિઝર્વેશન રાખવા માટે મજબૂર કરે જે તેઓ વાપરી શકતા નથી.

એવા મેન્યુઅલ ઓવરરાઈડ્સ બનાવો જે ખરેખર કામ કરે. ઓટોમેશન ત્યાં સુધી અદભૂત છે જ્યાં સુધી તે નિષ્ફળ ન જાય. જ્યારે API રિટર્ન કોન્ફ્લિક્ટ અથવા સિંક એરર થાય, ત્યારે કસ્ટમર સર્વિસ એજન્ટો પાસે તેમાં દરમિયાનગીરી કરવા માટે સત્તા અને ઇન્ટરફેસ હોવો જોઈએ. ઘણા બધા પ્લેટફોર્મ્સ માનવીય હસ્તક્ષેપ માટે કોઈ દરવાજા વગરના સંપૂર્ણ ઓટોમેટેડ કિલ્લાઓ જેવું ડિઝાઇન કરે છે. એજન્ટો અંતે સ્ક્રિપ્ટ વાંચતા રહી જાય છે, અનંત ક્ષમાપના કરે છે, અને ટિકિટો એવી જગ્યાએ (black holes) મોકલી દે છે જ્યાંથી કોઈ પ્રતિસાદ મળતો નથી. ઉપયોગી ઓવરરાઈડનો અર્થ એ છે કે એજન્ટ એરલાઇનનું મંજૂરી જોઈ શકે, તેને અટકેલી બુકિંગ સાથે મેળવી શકે અને રીઅલ ટાઇમમાં રદ કરવાની પ્રક્રિયા પૂર્ણ કરી શકે.

સોફ્ટવેરને એરલાઇનની વાસ્તવિકતા સાથે સુસંગત રાખો. ટ્રાવેલ પ્લેટફોર્મ્સ બૅચ અપડેટ્સ અને ધીમા પોલિંગ સાયકલથી દૂર થવાની જરૂર છે. જો એરલાઇન ટિકિટને રદ કરી શકાય તેવી (cancellable), રિફંડપાત્ર (refundable) અથવા રિશૅડ્યુલ કરી શકાય તેવી તરીકે માર્ક કરે, તો એગ્રીગેટરને તેના વિશે કલાકોમાં નહીં પણ મિનિટોમાં ખબર હોવી જોઈએ. તે માટે મજબૂત webhook આર્કિટેક્ચર, નિષ્ફળ થયેલા હેન્ડશેક માટે રીટ્રાય લોજિક અને યુઝરને ખબર પડે તે પહેલાં વિસંગતતાઓને ઓળખી કાઢતા રિકોન્સિલિએશન જોબ્સની જરૂર છે. પ્લેટફોર્મ તેના પોતાના ઉત્પાદનની સ્થિતિ જાણવામાં ક્યારેય છેલ્લું ન હોવું જોઈએ.

મુસાફરો અત્યારે શું કરી શકે છે

જ્યાં સુધી ઉદ્યોગ આ ખામીઓને સુધારે નહીં, ત્યાં સુધી મુસાફરોએ પોતાનું રક્ષણ કરવાની જરૂર છે. જો તમે AirAsia MOVE જેવા મોટા પ્લેટફોર્મ્સ સહિત કોઈપણ થર્ડ-પાર્ટી એપ દ્વારા બુકિંગ કરી રહ્યા હોવ, તો પુરાવા (paper trail) રાખો. તમારા કન્ફર્મેશન નંબર, કેન્સલેશન પોલિસી અને એરલાઇન તરફથી થયેલા કોઈપણ સંવાદના સ્ક્રીનશોટ લો. ખરીદતા પહેલા એરલાઇનની પોતાની પોલિસી જાણો; કેટલાક કેરિયર્સ પાર્ટનર્સ દ્વારા વેચાયેલી ટિકિટો માટે પણ તેમની વેબસાઇટ દ્વારા સીધા ફેરફાર કરવાની મંજૂરી આપે છે. જો એપ નિષ્ફળ જાય, તો સીધો એરલાઇનનો સંપર્ક કરો. જ્યારે જાહેર પોસ્ટ્સ (public posts) ચર્ચામાં આવે છે, ત્યારે કંપનીઓ ખાનગી સપોર્ટ ચેનલો કરતા વધુ ઝડપથી પગલાં લેવાનું શરૂ કરે છે. અને જો મોટી રકમ અટકી હોય, તો કન્ઝ્યુમર પ્રોટેક્શન ફોરમ અથવા ચાર્જબેક મિકેનિઝમ દ્વારા ફરિયાદ કરવામાં અચકાશો નહીં.

મુખ્ય વાત (The Real Takeaway)

કસ્ટમર એક્સપિરિયન્સ એ કોડ લખાયા પછી લગાવવામાં આવતું માત્ર ઉપરનું પોલિશ નથી. તે એ કોડ છે જે જીવનની મુશ્કેલીઓ દરમિયાન પણ યોગ્ય રીતે કામ કરે છે. જે બુકિંગ પ્લેટફોર્મ ફ્લાઇટ રદ કરી શકતું નથી તે રિવર્સ ગિયર વગરની કાર જેવું છે. તે આગળ તો સુંદર રીતે દોડી શકે છે, પરંતુ વહેલા કે મોડા તમારે પાછા આવવાની જરૂર પડશે જ.

મુસાફરો જાદુ નથી માંગતા. તેઓ એવા સાધનો માંગે છે જે તેમને ગેરમાર્ગે દોર્યા (gaslighting) વગર મૂળભૂત આદેશોનું પાલન કરે. IndiGo એ પહેલેથી જ સ્વીકારી લીધેલ કેન્સલેશનને માન્ય રાખવામાં AirAsia MOVE ની નિષ્ફળતા એ યાદ અપાવે છે કે સુવિધા ત્યારે જ સાચી છે જ્યારે આખી પ્રક્રિયા (pipeline) યોગ્ય રીતે કામ કરે. જ્યાં સુધી ટ્રાવેલ પ્લેટફોર્મ્સ ગ્રાહકો મેળવવાના માર્ગો (acquisition funnels) જેટલું જ રોકાણ ખરીદી પછીની વિશ્વસનીયતા (post-purchase reliability) માં નહીં કરે, ત્યાં સુધી વપરાશકર્તાઓ સાવધ રહેશે. અને તેઓએ રહેવું જ જોઈએ.