ഇടനിലക്കാരൻ ഒരു തടസ്സമായി മാറുമ്പോൾ
ഒരു യാത്രക്കാരൻ അടുത്തിടെ AirAsia MOVE പ്ലാറ്റ്ഫോം വഴി ഒരു IndiGo വിമാന ടിക്കറ്റ് ബുക്ക് ചെയ്തു. പ്ലാനുകളിൽ മാറ്റം വന്നപ്പോൾ, യാത്ര റദ്ദാക്കാൻ അദ്ദേഹം ആവശ്യപ്പെട്ടു. വിമാന കമ്പനി അത് സമ്മതിച്ചു. അവിടെ കഥ അവസാനിക്കേണ്ടതായിരുന്നു. എന്നാൽ, പ്ലാറ്റ്ഫോം തന്നെ റദ്ദാക്കൽ നടപടികൾ നടത്താൻ വിസമ്മതിച്ചു, ഇത് രണ്ട് കമ്പനികൾക്കിടയിലുള്ള ഒരു വിടവിൽ യാത്രക്കാരനെ കുടുക്കി. തന്റെ നിരാശ അദ്ദേഹം പരസ്യമായി പ്രകടിപ്പിക്കുകയും സിസ്റ്റം ഉപയോഗശൂന്യവും വിഡ്ഢിയുമാണെന്ന് വിളിക്കുകയും ചെയ്തു. അദ്ദേഹത്തിന്റെ ദേഷ്യം സ്വാഭാവികമായിരുന്നു, എന്നാൽ ജീവിതം ലളിതമാക്കാൻ അഗ്രഗേറ്ററുകളെ (aggregators) ആശ്രയിക്കുന്ന ദശലക്ഷക്കണക്കിന് യാത്രക്കാരെ ബാധിക്കുന്ന ഒരു പ്രശ്നത്തിലേക്കാണ് അത് വിരൽ ചൂണ്ടുന്നത്.
ഓൺലൈൻ ട്രാവൽ മേഖലയിലെ വലിയ സംവിധാനത്തിൽ ഇതൊരു ചെറിയ സംഭവമാണെങ്കിലും, ഇത് വലിയൊരു മുന്നറിയിപ്പാണ് നൽകുന്നത്. വിമാന കമ്പനികളുടെ വെബ്സൈറ്റുകൾ, പേയ്മെന്റ് ഗേറ്റ്വേകൾ, കൺഫർമേഷൻ കോഡുകൾ എന്നിവ കൈകാര്യം ചെയ്യുന്നതിലെ ബുദ്ധിമുട്ട് ഒഴിവാക്കാനാണ് നമ്മൾ ഈ ആപ്പുകൾ ഡൗൺലോഡ് ചെയ്യുന്നത്. ഇടനിലക്കാരൻ കാര്യങ്ങൾ എളുപ്പമാക്കുമെന്നാണ് നമ്മൾ പ്രതീക്ഷിക്കുന്നത്, അല്ലാതെ തടസ്സങ്ങൾ സൃഷ്ടിക്കാനല്ല. വിമാന കമ്പനി നേരത്തെ തന്നെ അംഗീകരിച്ച ഒരു റദ്ദാക്കൽ നടപടി പ്ലാറ്റ്ഫോമിന് നടപ്പിലാക്കാൻ കഴിയുന്നില്ലെങ്കിൽ, അത് അതിന്റെ പ്രധാന ജോലിയിൽ പരാജയപ്പെടുന്നു: അതായത്, ഉപയോക്താവിൽ നിന്ന് സേവനദാതാവിലേക്കും തിരിച്ചും വിവരങ്ങൾ കൃത്യമായി എത്തിക്കുക എന്നത്.
എന്താണ് തകരാറിലായത്?
ഈ കേസിലെ വിവരങ്ങൾ വളരെ ലളിതമാണ്, ആ ലളിതതയാണ് ഇതിനെ ആശങ്കാജനകമാക്കുന്നത്. യാത്രക്കാരൻ ഒളിഞ്ഞിരിക്കുന്ന ഫീസിനെക്കുറിച്ചോ പോളിസിയിലെ പഴുതുകളെക്കുറിച്ചോ തർക്കിച്ചതല്ല. അദ്ദേഹം ഒരു സാധാരണ കാര്യം ചെയ്തു—ഒരു ഫ്ലൈറ്റ് റദ്ദാക്കി—എന്നാൽ നിലനിൽക്കാൻ പാടില്ലാത്ത ഒരു പിശക് നേരിട്ടു. IndiGo റദ്ദാക്കൽ അംഗീകരിച്ചു. AirAsia MOVE അംഗീകരിച്ചില്ല. ഇതിന്റെ ഫലം ഇരുവർക്കും നഷ്ടം വരുത്തുന്ന ഒരു സാഹചര്യമായി മാറി. യാത്രക്കാരന് സമയവും സമാധാനവും നഷ്ടപ്പെട്ടു. പ്ലാറ്റ്ഫോമിന് വിശ്വാസ്യത നഷ്ടപ്പെട്ടു.
ഇത്തരം പരാജയങ്ങൾ സാധാരണയായി യാത്രക്കാർക്ക് കാണാൻ കഴിയാത്ത സാങ്കേതിക സംവിധാനങ്ങളുടെ ഉള്ളിലാണ് സംഭവിക്കുന്നത്. ഓൺലൈൻ ട്രാവൽ ഏജൻസികളും സൂപ്പർ ആപ്പുകളും വിമാന കമ്പനികളുടെ വിവരങ്ങൾ (inventory) സ്വന്തം സെർവറുകളിൽ സൂക്ഷിക്കുന്നില്ല. വിവരങ്ങൾ കൈമാറുന്നതിനായി അവർ API-കളിലൂടെയാണ് വിമാന കമ്പനികളുമായി ബന്ധപ്പെടുന്നത്. നിങ്ങൾ “cancel” എന്ന് അമർത്തുമ്പോൾ, നിങ്ങളുടെ അഭ്യർത്ഥന ഫോണിൽ നിന്ന് അഗ്രഗേറ്ററുടെ ബാക്കെൻഡിലേക്കും, അവിടെ നിന്ന് വിമാന കമ്പനിയുടെ റിസർവേഷൻ സിസ്റ്റത്തിലേക്കും എത്തുന്നു. വിമാന കമ്പനി ബുക്കിംഗ് സ്റ്റാറ്റസ് പുതുക്കുകയും ഒരു കൺഫർമേഷൻ അയക്കുകയും ചെയ്യുന്നു. ആ മാറ്റം ഉടൻ തന്നെ പ്രതിഫലിപ്പിക്കാനും നിങ്ങളുടെ റീഫണ്ട് അല്ലെങ്കിൽ ട്രാവൽ ക്രെഡിറ്റുകൾ പ്രോസസ്സ് ചെയ്യാനും അഗ്രഗേറ്റർ ബാധ്യസ്ഥനാണ്.
ആ ശൃംഖലയിൽ എവിടെയോ വെച്ച് AirAsia MOVE തടസ്സപ്പെട്ടു. ഒരുപക്ഷേ IndiGo-യുടെ സിസ്റ്റത്തിൽ നിന്ന് പുതുക്കിയ സ്റ്റാറ്റസ് ശേഖരിക്കുന്നതിൽ API പരാജയപ്പെട്ടതാകാം. ഒരുപക്ഷേ ആപ്പിന്റെ ഇന്റേണൽ ലോജിക്കിൽ വിമാന കമ്പനിയുടെ മറുപടിയെ മറികടക്കുന്ന തരത്തിലുള്ള ഒരു നിയമം ഉണ്ടായിരിക്കാം. ഒരുപക്ഷേ കസ്റ്റമർ സർവീസ് ഏജന്റുമാർക്ക് അവരുടെ സ്ക്രീനിൽ ഈ വ്യത്യാസം കാണാൻ കഴിഞ്ഞിട്ടുണ്ടാകാം, പക്ഷേ റദ്ദാക്കൽ പൂർത്തിയാക്കാൻ അവർക്ക് അനുമതി ഉണ്ടായിരുന്നില്ല. കൃത്യമായ ബഗ്ഗ് (bug) ഏതാണെന്ന് നമുക്കറിയില്ല, പക്ഷേ അതിന്റെ ഫലം നമുക്കറിയാം: എല്ലാ കക്ഷികളും റദ്ദാക്കാൻ സമ്മതിച്ച ഒരു ഇടപാടിൽ നിന്ന് പിന്മാറാൻ കഴിയാതെ ഒരു മനുഷ്യൻ ഒരു സോഫ്റ്റ്വെയർ ലൂപ്പിനുള്ളിൽ കുടുങ്ങിപ്പോയി.
കോഡ് പരിഹരിക്കുന്നതിനേക്കാൾ വേഗത്തിൽ വിശ്വാസം എങ്ങനെയൊന്ന് നഷ്ടപ്പെടുന്നു?
യാത്രക്കാർ മോശം ഇന്റർഫേസുകൾ സഹിക്കും. ലോഡിംഗ് സമയം വൈകുന്നത് അവർ സഹിക്കും. എന്നാൽ പണവും പ്ലാനുകളും അപകടത്തിലാകുമ്പോൾ അവർക്ക് നിസ്സഹായാവസ്ഥ സഹിക്കാനാവില്ല. ഒരു റദ്ദാക്കൽ എന്നത് നിസ്സാരമായ ഒരു അഭ്യർത്ഥനയല്ല. അത് സാധാരണയായി ഒരു പ്രതിസന്ധിയുടെ ഫലമായിട്ടായിരിക്കും—ഒരു ആരോഗ്യ പ്രശ്നം, കുടുംബത്തിലെ അടിയന്തിര സാഹചര്യം, അല്ലെങ്കിൽ പെട്ടെന്നുണ്ടാകുന്ന ജോലി സംബന്ധമായ തടസ്സങ്ങൾ എന്നിവയാകാം. ഉപയോക്താവ് ഇതിനകം തന്നെ സമ്മർദ്ദത്തിലായിരിക്കും. ബാക്കെൻഡ് സങ്കീർണ്ണതകൾ കൈകാര്യം ചെയ്തുകൊണ്ട് ആ സമ്മർദ്ദം കുറയ്ക്കുക എന്നതാണ് ആപ്പിന്റെ പങ്ക്. എന്നാൽ അത് പുതിയൊരു തടസ്സം സൃഷ്ടിക്കുമ്പോൾ, അതിന്റെ മാനസിക ആഘാതം വളരെ വലുതാണ്.
അതുകൊണ്ടാണ് യാത്രക്കാരന്റെ പരസ്യമായ പ്രതിഷേധം പ്രസക്തമാകുന്നത്. ഒരു ലോയൽറ്റി പോയിന്റ് നഷ്ടപ്പെട്ടതിനെക്കുറിച്ചോ വൈകിയ നോട്ടിഫിക്കേഷനെക്കുറിച്ചോ അല്ല അദ്ദേഹം പരാതിപ്പെട്ടത്. അദ്ദേഹത്തിന് ഏറ്റവും ആവശ്യമുള്ള സമയത്ത് ഒരു നിയമാനുസൃതമായ അഭ്യർത്ഥനയെ ആ പ്ലാറ്റ്ഫോം തടഞ്ഞതുകൊണ്ടാണ് അദ്ദേഹം അതിനെ ഉപയോഗശൂന്യമെന്ന് വിശേഷിപ്പിച്ചത്. സാഹചര്യങ്ങൾ മാറിയാലും നിങ്ങളുടെ ഉദ്ദേശ്യം സിസ്റ്റം മാനിക്കുമെന്ന വിശ്വാസത്തിലാണ് ഡിജിറ്റൽ സേവനങ്ങളിലുള്ള വിശ്വാസം നിലനിൽക്കുന്നത്. ആ വാഗ്ദാനത്തിലെ ഒരു വീഴ്ച പത്ത് സുഗമമായ ബുക്കിംഗുകൾ കൊണ്ട് പോലും പരിഹരിക്കാൻ കഴിയാത്തത്ര നാശനഷ്ടങ്ങൾ ഉണ്ടാക്കും.
പല ട്രാവൽ പ്ലാറ്റ്ഫോമുകളും നിർമ്മിച്ചിരിക്കുന്ന രീതിയിലെ ഒരു തന്ത്രപരമായ വീഴ്ചയും ഈ പ്രശ്നം വെളിപ്പെടുത്തുന്നു. എഞ്ചിനീയറിംഗ് ടീമുകൾ പലപ്പോഴും ഫ്രണ്ട് എൻഡിൽ (front end) ആണ് കൂടുതൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നത്: വേഗതയേറിയ സെർച്ച്, മനോഹരമായ കലണ്ടറുകൾ, വൺ-ടാപ്പ് ചെക്കൗട്ട്, പേഴ്സണലൈസ്ഡ് ഡീലുകൾ എന്നിവ ഇതിൽ ഉൾപ്പെടുന്നു. ഡൗൺലോഡുകൾ വർദ്ധിപ്പിക്കുന്നത് ഇത്തരം ഫീച്ചറുകളാണ്. ബുക്കിംഗിന് ശേഷമുള്ള പ്രവർത്തനങ്ങൾ—മാറ്റങ്ങൾ, റദ്ദാക്കലുകൾ, റീഫണ്ടുകൾ—എന്നിവ പലപ്പോഴും അവഗണിക്കപ്പെടുന്നു. അവയ്ക്ക് പഴയ API-കളും കുറഞ്ഞ നിരീക്ഷണവും പരിമിതമായ ഓപ്ഷനുകളുമാണ് ലഭിക്കുന്നത്. എന്നാൽ ഒരു ആപ്പ് യഥാർത്ഥത്തിൽ ഉപകാരപ്രദമാണോ അതോ വെറുമൊരു ആകർഷകമായ പരസ്യം മാത്രമാണോ എന്ന് ഉപയോക്താക്കൾ തിരിച്ചറിയുന്നത് ഇവിടെ വെച്ചാണ്.
ട്രാവൽ പ്ലാറ്റ്ഫോമുകൾ ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ
ഉപഭോക്താക്കൾക്കും വിമാന കമ്പനികൾക്കും ഇടയിൽ പ്രവർത്തിക്കുന്ന ഏതൊരു കമ്പനിക്കും ഇതിൽ നിന്ന് വ്യക്തമായ പാഠങ്ങളുണ്ട്.
ബുക്കിംഗുകൾ പോലെ തന്നെ ലളിതമാക്കുക റദ്ദാക്കലുകളും. ഒരു ഉപയോക്താവിന് മൂന്ന് ടാപ്പുകളിലൂടെ ഒരു സീറ്റ് റിസർവ് ചെയ്യാൻ കഴിയുമെങ്കിൽ, ചാറ്റ്ബോട്ടുകളുടെയും മറഞ്ഞിരിക്കുന്ന മെനുകളുടെയും പിന്തുണയില്ലാത്ത ഫോമുകളുടെയും ഒരു കുരുക്കിലൂടെ കടന്നുപോകാതെ തന്നെ അത് റദ്ദാക്കാൻ അവർക്ക് കഴിയണം. റദ്ദാക്കൽ പ്രക്രിയ സുതാര്യവും, ഫീസുകളെക്കുറിച്ച് സത്യസന്ധവും, യാത്രക്കാരെ കുറ്റബോധത്തിലാഴ്ത്തിക്കൊണ്ടോ ആശയക്കുഴപ്പത്തിലാഴ്ത്തിക്കൊണ്ടോ ഉപയോഗിക്കാൻ കഴിയാത്ത ഒരു റിസർവേഷൻ നിലനിർത്താൻ പ്രേരിപ്പിക്കുന്ന ഡാർക്ക് പാറ്റേണുകളിൽ (dark patterns) നിന്ന് മുക്തവുമാകണം.
യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്ന മാനുവൽ ഓവർറൈഡുകൾ (manual overrides) നിർമ്മിക്കുക. ഓട്ടോമേഷൻ അത് പരാജയപ്പെടുന്നത് വരെ അത് അത്ഭുതകരമാണ്. ഒരു API റിട്ടേൺ കോൺഫ്ലിക്റ്റോ സിങ്ക് എററോ (sync error) സംഭവിക്കുമ്പോൾ, ഇടപെടാൻ ആവശ്യമായ അധികാരവും ഇന്റർഫേസും കസ്റ്റമർ സർവീസ് ഏജന്റുമാർക്ക് ഉണ്ടായിരിക്കണം. മനുഷ്യ ഇടപെടലിന് വാതിലുകളില്ലാത്ത പൂർണ്ണമായും ഓട്ടോമേറ്റഡ് കോട്ടകളായാണ് പല പ്ലാറ്റ്ഫോമുകളും രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്. ഏജന്റുമാർ സ്ക്രിപ്റ്റുകൾ വായിച്ചുകൊണ്ടും നിരന്തരം മാപ്പ് പറഞ്ഞുകൊണ്ടും ടിക്കറ്റുകൾ ഒരു ബ്ലാക്ക് ഹോൾ പോലെ അപ്രത്യക്ഷമാകുന്ന അവസ്ഥയിലേക്ക് മാറുന്നു. ഒരു ഉപയോഗപ്രദമായ ഓവർറൈഡ് എന്നാൽ, ഒരു ഏജന്റിന് എയർലൈനിന്റെ അനുമതി കാണാനും, തടസ്സപ്പെട്ട ബുക്കിംഗുമായി അത് ഒത്തുനോക്കാനും, തത്സമയം റദ്ദാക്കൽ നടപടി പൂർത്തിയാക്കാനും കഴിയുന്നു എന്നാണ് അർത്ഥമാക്കുന്നത്.
സോഫ്റ്റ്വെയറിനെ എയർലൈൻ യാഥാർത്ഥ്യങ്ങളുമായി ഒത്തുപോകുന്നതാക്കി നിലനിർത്തുക. ട്രാവൽ പ്ലാറ്റ്ഫോമുകൾ ബാച്ച് അപ്ഡേറ്റുകളിൽ നിന്നും സാവധാനത്തിലുള്ള പോളിംഗ് സൈക്കിളുകളിൽ നിന്നും മാറി മാറേണ്ടതുണ്ട്. ഒരു എയർലൈൻ ഒരു ടിക്കറ്റ് റദ്ദാക്കാവുന്നതോ (cancellable), റീഫണ്ട് ചെയ്യാവുന്നതോ (refundable), അല്ലെങ്കിൽ പുനഃക്രമീകരിക്കാവുന്നതോ (rescheduled) ആണെന്ന് അടയാളപ്പെടുത്തിയാൽ, മണിക്കൂറുകളല്ല, മിനിറ്റുകൾക്കുള്ളിൽ തന്നെ അഗ്രഗേറ്റർ അത് അറിയണം. ഇതിനായി ശക്തമായ webhook ആർക്കിടെക്ചർ, പരാജയപ്പെട്ട ഹാൻഡ്ഷേക്കുകൾക്കായി റീട്രൈ ലോജിക് (retry logic), ഉപയോക്താവ് കണ്ടെത്തുന്നതിന് മുമ്പ് തന്നെ വ്യത്യാസങ്ങൾ അടയാളപ്പെടുത്തുന്ന റീകൺസിലിയേഷൻ ജോബുകൾ എന്നിവ ആവശ്യമാണ്. സ്വന്തം ഉൽപ്പന്നത്തിന്റെ അവസ്ഥ അറിയാൻ പ്ലാറ്റ്ഫോം ഏറ്റവും ഒടുവിൽ അറിയുന്ന ഒന്നാകരുത്.
യാത്രക്കാർക്ക് ഇപ്പോൾ ചെയ്യാൻ കഴിയുന്ന കാര്യങ്ങൾ
ഈ പോരായ്മകൾ പരിഹരിക്കപ്പെടുന്നത് വരെ, യാത്രക്കാർ സ്വയം സംരക്ഷിക്കേണ്ടതുണ്ട്. AirAsia MOVE പോലുള്ള പ്രമുഖ ആപ്പുകൾ ഉൾപ്പെടെ ഏതെങ്കിലും തേർഡ് പാർട്ടി ആപ്പിലൂടെയാണ് നിങ്ങൾ ബുക്ക് ചെയ്യുന്നതെങ്കിൽ, അതിന്റെ രേഖകൾ സൂക്ഷിക്കുക. നിങ്ങളുടെ കൺഫർമേഷൻ നമ്പറുകൾ, റദ്ദാക്കൽ നയങ്ങൾ, എയർലൈനിൽ നിന്നുള്ള ഏതൊരു ആശയവിനിമയവും സ്ക്രീൻഷോട്ട് എടുത്ത് വെക്കുക. ടിക്കറ്റ് വാങ്ങുന്നതിന് മുമ്പ് എയർലൈനിന്റെ സ്വന്തം നയം മനസ്സിലാക്കുക; പങ്കാളികൾ വഴി വിൽക്കപ്പെടുന്ന ടിക്കറ്റുകൾക്ക് പോലും അവരുടെ വെബ്സൈറ്റ് വഴി നേരിട്ട് മാറ്റങ്ങൾ വരുത്താൻ ചില എയർലൈനുകൾ അനുവദിക്കാറുണ്ട്. ആപ്പ് പരാജയപ്പെട്ടാൽ, നേരിട്ട് എയ