ಮಧ್ಯವರ್ತಿ ಅಡೆತಡೆಯಾಗಿದಾಗ
ಇತ್ತೀಚೆಗೆ ಒಬ್ಬ ಪ್ರಯಾಣಿಕರು AirAsia MOVE ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಮೂಲಕ IndiGo ವಿಮಾನದ ಟಿಕೆಟ್ ಕಾಯ್ದಿರಿಸಿದ್ದರು. ಯೋಜನೆಗಳು ಬದಲಾದಾಗ, ಅವರು ಪ್ರಯಾಣವನ್ನು ರದ್ದುಗೊಳಿಸಲು ಕೇಳಿದರು. ವಿಮಾನಯಾನ ಸಂಸ್ಥೆಯು ಅದಕ್ಕೆ ಒಪ್ಪಿಗೆ ನೀಡಿತು. ಅಲ್ಲಿಗೆ ಕಥೆ ಮುಗಿಯಬೇಕಿತ್ತು. ಆದರೆ, ಬದಲಾಗಿ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಸ್ವತಃ ರದ್ದತಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಡೆಸಲು ನಿರಾಕರಿಸಿತು, ಇದರಿಂದ ಪ್ರಯಾಣಿಕರು ಎರಡು ಕಂಪನಿಗಳ ನಡುವಿನ ಅಂತರದಲ್ಲಿ ಸಿಲುಕಿಕೊಂಡರು. ಅವರು ತಮ್ಮ ಅಸಮಾಧಾನವನ್ನು ಸಾರ್ವಜನಿಕವಾಗಿ ವ್ಯಕ್ತಪಡಿಸಿ, ಈ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರುಪಯುಕ್ತ ಮತ್ತು ಮೂರ್ಖತನದ್ದು ಎಂದು ಕರೆದರು. ಅವರ ಕೋಪವು ತೀವ್ರವಾಗಿತ್ತು, ಆದರೆ ಅದು ಲಕ್ಷಾಂತರ ಪ್ರಯಾಣಿಕರ ಜೀವನವನ್ನು ಸರಳಗೊಳಿಸಲು ಅಸೆಗ್ರೆಗೇಟರ್ಗಳ (aggregators) ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವ ಒಂದು ಸಮಸ್ಯೆಯನ್ನು ಎತ್ತಿ ತೋರಿಸಿತು.
ಈ ಘಟನೆಯು ಆನ್ಲೈನ್ ಪ್ರಯಾಣದ ವಿಶಾಲ ಯಂತ್ರದಲ್ಲಿ ಒಂದು ಸಣ್ಣ ಘಟನೆಯಾಗಿದ್ದರೂ, ಇದು ಒಂದು ದೊಡ್ಡ ಎಚ್ಚರಿಕೆಯನ್ನು ನೀಡುತ್ತದೆ. ವಿಮಾನಯಾನ ಸಂಸ್ಥೆಗಳ ವೆಬ್ಸೈಟ್ಗಳು, ಪೇಮೆಂಟ್ ಗೇಟ್ವೇಗಳು ಮತ್ತು ಕನ್ಫರ್ಮೇಷನ್ ಕೋಡ್ಗಳ ನಡುವೆ ಅಲೆಯುವುದನ್ನು ತಪ್ಪಿಸಲು ನಾವು ಈ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಡೌನ್ಲೋಡ್ ಮಾಡುತ್ತೇವೆ. ಮಧ್ಯವರ್ತಿಯು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸುಗಮಗೊಳಿಸಬೇಕೆಂದು ನಾವು ನಿರೀಕ್ಷಿಸುತ್ತೇವೆ ಹೊರತು, ಅದನ್ನು ತಡೆಯಬಾರದು. ವಿಮಾನಯಾನ ಸಂಸ್ಥೆಯು ಈಗಾಗಲೇ ಅನುಮೋದಿಸಿದ ರದ್ದತಿಯನ್ನು ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ, ಅದು ತನ್ನ ಏಕೈಕ ನಿಜವಾದ ಕೆಲಸದಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ: ಅಂದರೆ ಬಳಕೆದಾರರಿಂದ ಸೇವಾ ಪೂರೈಕೆದಾರರಿಗೆ ಮತ್ತು ವಾಪಸ್ ಮಾಹಿತಿಯನ್ನು ನಿಖರವಾಗಿ ತಲುಪಿಸುವುದು.
ಏನದು ವಿಫಲವಾಯಿತು
ಈ ಪ್ರಕರಣದ ವಿವರಗಳು ಸರಳವಾಗಿವೆ, ಮತ್ತು ಅದೇ ವಿಷಯವನ್ನು ಆತಂಕಕಾರಿಯಾಗಿಸುತ್ತದೆ. ಪ್ರಯಾಣಿಕರು ಯಾವುದೇ ಗುಪ್ತ ಶುಲ್ಕದ ಬಗ್ಗೆ ವಿವಾದ ಮಾಡಲಿಲ್ಲ ಅಥವಾ ಪಾಲಿಸಿಯ ಲೋಪದೋಷಗಳ ಬಗ್ಗೆ ಹೋರಾಡಲಿಲ್ಲ. ಅವರು ಒಂದು ಸಾಮಾನ್ಯ ಕ್ರಮವನ್ನು ಮಾಡಿದರು—ವಿಮಾನ ರದ್ದುಗೊಳಿಸುವುದು—ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿರಬಾರದು ಎನ್ನಬೇಕಾದ ದೋಷವನ್ನು ಎದುರಿಸಿದರು. IndiGo ರದ್ದತಿಯನ್ನು ಒಪ್ಪಿಕೊಂಡಿತು. AirAsia MOVE ಒಪ್ಪಲಿಲ್ಲ. ಇದರ ಪರಿಣಾಮವು ಎಲ್ಲರಿಗೂ ನಷ್ಟ ತರುವ ಪರಿಸ್ಥಿತಿಯಾಯಿತು. ಪ್ರಯಾಣಿಕರು ಸಮಯ ಮತ್ತು ನೆಮ್ಮದಿಯನ್ನು ಕಳೆದುಕೊಂಡರು. ಪ್ಲಾಟ್ಫಾರ್ಮ್ ತನ್ನ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಕಳೆದುಕೊಂಡಿತು.
ಇಂತಹ ವೈಫಲ್ಯಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರಯಾಣಿಕರಿಗೆ ಕಾಣಿಸದ ವ್ಯವಸ್ಥೆಯ ಆಳದಲ್ಲಿ ಸಂಭವಿಸುತ್ತವೆ. ಆನ್ಲೈನ್ ಟ್ರಾವೆಲ್ ಏಜೆನ್ಸಿಗಳು ಮತ್ತು superapps ವಿಮಾನಯಾನ ಸಂಸ್ಥೆಗಳ ಇನ್ವೆಂಟರಿಯನ್ನು ತಮ್ಮ ಸ್ವಂತ ಸರ್ವರ್ಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸುವುದಿಲ್ಲ. ಅವು ಡೇಟಾವನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುವ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಇಂಟರ್ಫೇಸ್ಗಳು ಅಥವಾ APIs ಮೂಲಕ ವಿಮಾನಯಾನ ಸಂಸ್ಥೆಗಳೊಂದಿಗೆ ಸಂಪರ್ಕ ಸಾಧಿಸುತ್ತವೆ. ನೀವು “cancel” ಮೇಲೆ ಟ್ಯಾಪ್ ಮಾಡಿದಾಗ, ನಿಮ್ಮ ವಿನಂತಿಯು ನಿಮ್ಮ ಫೋನ್ನಿಂದ ಅಸೆಗ್ರೆಗಟರ್ನ backend ಮೂಲಕ ವಿಮಾನಯಾನ ಸಂಸ್ಥೆಯ reservation system ಗೆ ತಲುಪುತ್ತದೆ. ವಿಮಾನಯಾನ ಸಂಸ್ಥೆಯು ಬುಕಿಂಗ್ ಸ್ಥಿತಿಯನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ದೃಢೀಕರಣವನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಅಸೆಗ್ರೆಗಟರ್ ಆ ಬದಲಾವಣೆಯನ್ನು ತಕ್ಷಣವೇ ಪ್ರತಿಬಿಂಬಿಸಬೇಕು ಮತ್ತು ನಿಮ್ಮ ಹಣದ ಮರುಪಾವತಿ ಅಥವಾ ಟ್ರಾವೆಲ್ ಕ್ರೆಡಿಟ್ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕು.
ಆ ಸರಪಳಿಯ ಯಾವುದೋ ಒಂದು ಹಂತದಲ್ಲಿ, AirAsia MOVE ಸ್ಥಗಿತಗೊಂಡಿತು. ಬಹುಶಃ API ಇಂದ IndiGo ಸಿಸ್ಟಮ್ನಿಂದ ಅಪ್ಡೇಟ್ ಆದ ಸ್ಥಿತಿಯನ್ನು ಪಡೆಯಲು ವಿಫಲವಾಗಿರಬಹುದು. ಬಹುಶಃ ಅಪ್ಲಿಕೇಶನ್ನ ಆಂತರಿಕ ತರ್ಕವು (internal logic) ವಿಮಾನಯಾನ ಸಂಸ್ಥೆಯ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಮೀರಿ ನಿಲ್ಲುವಂತಹ ಯಾವುದೋ ಹಾರ್ಡ್ಕೋಡ್ ಮಾಡಲಾದ ನಿಯಮವನ್ನು ಹೊಂದಿರಬಹುದು. ಬಹುಶಃ ಗ್ರಾಹಕ ಸೇವಾ ಪ್ರತಿನಿಧಿಗಳು ತಮ್ಮ ಪರದೆಯ ಮೇಲೆ ವ್ಯತ್ಯಾಸವನ್ನು ನೋಡಬಹುದಾಗಿತ್ತು ಆದರೆ ರದ್ದತಿಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಅವರಿಗೆ ಅನುಮತಿ ಇರಲಿಲ್ಲ. ನಮಗೆ ನಿಖರವಾದ ದೋಷ (bug) ತಿಳಿಯದೇ ಇರಬಹುದು, ಆದರೆ ನಮಗೆ ಅದರ ಫಲಿತಾಂಶ ತಿಳಿದಿದೆ: ಎಲ್ಲಾ ಕಡೆಯೂ ಒಪ್ಪಿಕೊಂಡಿದ್ದ ವ್ಯವಹಾರವನ್ನು ಹಿಂಪಡೆಯಲು ಸಾಧ್ಯವಾಗದೆ, ಒಬ್ಬ ಮನುಷ್ಯ ಸಾಫ್ಟ್ವೇರ್ ಲೂಪ್ನೊಳಗೆ ಸಿಲುಕಿಕೊಂಡಿದ್ದನು.
ಕೋಡ್ ಸರಿಪಡಿಸುವುದಕ್ಕಿಂತ ವಿಶ್ವಾಸವು ಏಕೆ ವೇಗವಾಗಿ ಕುಸಿಯುತ್ತದೆ
ಪ್ರಯಾಣಿಕರು ಕಷ್ಟಕರವಾದ ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ಸಹಿಸಿಕೊಳ್ಳುತ್ತಾರೆ. ಅವರು ನಿಧಾನಗತಿಯ ಲೋಡ್ ಸಮಯವನ್ನು ಸಹಿಸಿಕೊಳ್ಳುತ್ತಾರೆ. ಆದರೆ ಹಣ ಮತ್ತು ಯೋಜನೆಗಳು ಪಣಕ್ಕಿದ್ದಾಗ ಅವರು ಅಸಹಾಯಕತೆಯನ್ನು ಸಹಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ. ರದ್ದತಿಯು ಒಂದು ಕ್ಷುಲ್ಲಕ ವಿನಂತಿಯಲ್ಲ. ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ಬಿಕ್ಕಟ್ಟಿನ ನಂತರ ಬರುತ್ತದೆ—ವೈದ್ಯಕೀಯ ಸಮಸ್ಯೆ, ಕೌಟುಂಬಿಕ ತುರ್ತು ಪರಿಸ್ಥಿತಿ ಅಥವಾ ಕೆಲಸದ ಅನಿರೀಕ್ಷಿತ ವ್ಯತ್ಯಾಸ. ಬಳಕೆದಾರರು ಈಗಾಗಲೇ ಒತ್ತಡದಲ್ಲಿದ್ದಾರೆ. backend ಸಂಕೀರ್ಣತೆಯನ್ನು ನಿಭಾಯಿಸುವ ಮೂಲಕ ಆ ಒತ್ತಡವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ಅಪ್ಲಿಕೇಶನ್ನ ಪಾತ್ರವಾಗಿದೆ. ಬದಲಾಗಿ ಅದು ಹೊಸ ಅಡೆತಡೆಯನ್ನು ಸೃಷ್ಟಿಸಿದಾಗ, ಅದರ ಭಾವನಾತ್ಮಕ ಪರಿಣಾಮವು ತುಂಬಾ ದೊಡ್ಡದಾಗಿರುತ್ತದೆ.
ಇದೇ ಕಾರಣಕ್ಕೆ ಪ್ರಯಾಣಿಕನ ಸಾರ್ವಜನಿಕ ಆಕ್ರೋಶವು ಮುಖ್ಯವಾಗಿದೆ. ಅವನು ಕಳೆದುಹೋದ ಲಾಯಲ್ಟಿ ಪಾಯಿಂಟ್ ಅಥವಾ ವಿಳಂಬವಾದ ನೋಟಿಫಿಕೇಶನ್ ಬಗ್ಗೆ ದೂರು ನೀಡಲಿಲ್ಲ. ಬದಲಾಗಿ, ಅವನಿಗೆ ಅತಿ ಹೆಚ್ಚು ಅಗತ್ಯವಿದ್ದ ಸಮಯದಲ್ಲಿ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಒಂದು ಕಾನೂನುಬದ್ಧ ವಿನಂತಿಯನ್ನು ತಡೆಯಲು ಪ್ರಯತ್ನಿಸಿದ ಕಾರಣ ಅದನ್ನು ನಿರುಪಯುಕ್ತ ಎಂದು ಕರೆದನು. ಡಿಜಿಟಲ್ ಸೇವೆಗಳ ಮೇಲಿನ ವಿಶ್ವಾಸವು, ಸಂದರ್ಭಗಳು ಬದಲಾದಾಗಲೂ ವ್ಯವಸ್ಥೆಯು ನಿಮ್ಮ ಉದ್ದೇಶವನ್ನು ಗೌರವಿಸುತ್ತದೆ ಎಂಬ ನಂಬಿಕೆಯ ಮೇಲೆ ನಿರ್ಮಿತವಾಗಿದೆ. ಆ ಭರವಸೆಯ ಒಂದು ಉಲ್ಲಂಘನೆಯು ಹತ್ತು ಸುಗಮ ಬುಕಿಂಗ್ಗಳಿಗಿಂತ ಹೆಚ್ಚು ಹಾನಿಯನ್ನು ಮಾಡುತ್ತದೆ.
ಈ ಸಮಸ್ಯೆ ಅನೇಕ ಪ್ರಯಾಣ ಪ್ಲಾಟ್ಫಾರ್ಮ್ಗಳನ್ನು ನಿರ್ಮಿಸುವಲ್ಲಿರುವ ಒಂದು ಕಾರ್ಯತಂತ್ರದ ಅಂಧತೆಯನ್ನು (strategic blind spot) ಸಹ ಬಯಲು ಮಾಡುತ್ತದೆ. ಎಂಜಿನಿಯರಿಂಗ್ ತಂಡಗಳು ಹೆಚ್ಚಾಗಿ front end ಮೇಲೆ ಸಂಪನ್ಮೂಲಗಳನ್ನು ವ್ಯಯಿಸುತ್ತವೆ: ವೇಗದ ಹುಡುಕಾಟ, ಸುಂದರವಾದ ಕ್ಯಾಲೆಂಡರ್ಗಳು, ಒನ್-ಟ್ಯಾಪ್ ಚೆಕ್ಔಟ್, ವೈಯಕ್ತಿಕಗೊಳಿಸಿದ ಡೀಲ್ಗಳು. ಇವುಗಳು ಅಪ್ಲಿಕೇಶನ್ ಡೌನ್ಲೋಡ್ ಮಾಡಲು ಪ್ರೇರೇಪಿಸುವ ವೈಶಿಷ್ಟ್ಯಗಳಾಗಿವೆ. ಬುಕಿಂಗ್ ನಂತರದ ಕಾರ್ಯಾಚರಣೆಗಳು—ಬದಲಾವಣೆಗಳು, ರದ್ದತಿಗಳು, ಮರುಪಾವತಿಗಳು—ಅವುಗಳನ್ನು ಕೇವಲ ನಂತರದ ವಿಚಾರಗಳೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಅವುಗಳಿಗೆ ಹಳೆಯ APIs, ಕಡಿಮೆ ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ಕಡಿಮೆ ಪರ್ಯಾಯ ಆಯ್ಕೆಗಳನ್ನು ನೀಡಲಾಗುತ್ತದೆ. ಆದರೆ ಬಳಕೆದಾರರು ಒಂದು ಅಪ್ಲಿಕೇಶನ್ ನಿಜವಾದ ಸಾಧನವೇ ಅಥವಾ ಕೇವಲ ಹೊಳೆಯುವ ಬ್ರೋಷರ್ ಆಗಿದೆಯೇ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಇದೇ ಹಂತದಲ್ಲಿ.
ಪ್ರಯಾಣ ಪ್ಲಾಟ್ಫಾರ್ಮ್ಗಳು ಏನನ್ನು ಸರಿಯಾಗಿ ಮಾಡಬೇಕು
ಗ್ರಾಹಕರು ಮತ್ತು ವಿಮಾನಯಾನ ಸಂಸ್ಥೆಗಳ ನಡುವೆ ಇರುವ ಯಾವುದೇ ಕಂಪನಿಗೆ ಇಲ್ಲಿ ಸ್ಪಷ್ಟವಾದ ಪಾಠಗಳಿವೆ.
ರದ್ದತಿಗಳನ್ನು ಬುಕಿಂಗ್ಗಳಷ್ಟೇ ಸರಳವಾಗಿಸಿ. ಬಳಕೆದಾರರು ಮೂರು ಟ್ಯಾಪ್ಗಳಲ್ಲಿ ಸೀಟನ್ನು ಕಾಯ್ದಿರಿಸಬಹುದಾದರೆ, ಅವರು ಚಾಟ್ಬಾಟ್ಗಳು, ಅಡಗಿರುವ ಮೆನುಗಳು ಮತ್ತು ಬೆಂಬಲವಿಲ್ಲದ ಫಾರ್ಮ್ಗಳಂತಹ ಸಂಕೀರ್ಣ ಹಾದಿಯಲ್ಲಿ ಅಲೆಯದೆ ಅದನ್ನು ರದ್ದುಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗಬೇಕು. ರದ್ದತಿ ಪ್ರಕ್ರಿಯೆಯು ಸ್ಪಷ್ಟವಾಗಿರಬೇಕು, ಶುಲ್ಕಗಳ ಬಗ್ಗೆ ಪ್ರಾಮಾಣಿಕವಾಗಿರಬೇಕು ಮತ್ತು ಪ್ರಯಾಣಿಕರು ತಮಗೆ ಬಳಸಲಾಗದ ಮೀಸಲಾತಿಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವಂತೆ ಮಾಡಲು ಅವರನ್ನು ದೂಷಿಸುವ ಅಥವಾ ಗೊಂದಲಕ್ಕೀಡುಮಾಡುವ ಡಾರ್ಕ್