ਜਦੋਂ ਵਿਚੋਲਾ ਹੀ ਰੁਕਾਵਟ ਬਣ ਜਾਵੇ

ਜਦੋਂ ਵਿਚੋਲਾ ਹੀ ਰੁਕਾਵਟ ਬਣ ਜਾਵੇ

ਇੱਕ ਯਾਤਰੀ ਨੇ ਹਾਲ ਹੀ ਵਿੱਚ AirAsia MOVE ਪਲੇਟਫਾਰਮ ਰਾਹੀਂ ਇੱਕ IndiGo ਫਲਾਈਟ ਬੁੱਕ ਕੀਤੀ। ਜਦੋਂ ਯੋਜਨਾਵਾਂ ਬਦਲੀਆਂ, ਤਾਂ ਉਸਨੇ ਯਾਤਰਾ ਰੱਦ ਕਰਨ ਦੀ ਬੇਨਤੀ ਕੀਤੀ। ਏਅਰਲਾਈਨ ਮੰਨ ਗਈ। ਕਹਾਣੀ ਇੱਥੇ ਹੀ ਖ਼ਤਮ ਹੋ ਜਾਣੀ ਚਾਹੀਦੀ ਸੀ। ਪਰ, ਪਲੇਟਫਾਰਮ ਨੇ ਖ਼ੁਦ ਰੱਦ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਪੂਰਾ ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕਰ ਦਿੱਤਾ, ਜਿਸ ਨਾਲ ਯਾਤਰੀ ਦੋ ਕੰਪਨੀਆਂ ਦੇ ਵਿਚਕਾਰ ਫਸ ਗਿਆ। ਉਸਨੇ ਆਪਣੀ ਨਾਰਾਜ਼ਗੀ ਜਨਤਕ ਕੀਤੀ ਅਤੇ ਸਿਸਟਮ ਨੂੰ ਬੇਕਾਰ ਅਤੇ ਮੂਰਖ ਦੱਸਿਆ। ਉਸਦਾ ਗੁੱਸਾ ਸੱਚਾ ਸੀ, ਪਰ ਇਹ ਉਸ ਸਮੱਸਿਆ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰ ਰਿਹਾ ਸੀ ਜੋ ਲੱਖਾਂ ਯਾਤਰੀਆਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ ਜੋ ਆਪਣੀ ਜ਼ਿੰਦਗੀ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣ ਲਈ ਐਗਰੀਗੇਟਰਾਂ (aggregators) 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ।

ਇਹ ਘਟਨਾ ਆਨਲਾਈਨ ਟ੍ਰੈਵਲ ਦੀ ਵਿਸ਼ਾਲ ਮਸ਼ੀਨਰੀ ਵਿੱਚ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਘਟਨਾ ਹੈ, ਫਿਰ ਵੀ ਇਹ ਇੱਕ ਵੱਡੀ ਚੇਤਾਵਨੀ ਦਿੰਦੀ ਹੈ। ਅਸੀਂ ਏਅਰਲਾਈਨ ਵੈੱਬਸਾਈਟਾਂ, ਪੇਮੈਂਟ ਗੇਟਵੇਅ ਅਤੇ ਕਨਫਰਮੇਸ਼ਨ ਕੋਡਾਂ ਦੇ ਝੰਜਟ ਤੋਂ ਬਚਣ ਲਈ ਇਹ ਐਪਸ ਡਾਊਨਲੋਡ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹਾਂ ਕਿ ਵਿਚੋਲਾ ਕੰਮ ਨੂੰ ਸੁਖਾਲਾ ਬਣਾਏਗਾ, ਨਾ ਕਿ ਉਸਨੂੰ ਰੋਕੇਗਾ। ਜਦੋਂ ਕੋਈ ਪਲੇਟਫਾਰਮ ਉਸ ਰੱਦ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕਦਾ ਜਿਸ ਨੂੰ ਏਅਰਲਾਈਨ ਪਹਿਲਾਂ ਹੀ ਮਨਜ਼ੂਰੀ ਦੇ ਚੁੱਕੀ ਹੈ, ਤਾਂ ਇਹ ਆਪਣੇ ਇੱਕੋ ਇੱਕ ਅਸਲ ਕੰਮ ਵਿੱਚ ਅਸਫਲ ਰਹਿੰਦਾ ਹੈ: ਯੂਜ਼ਰ ਤੋਂ ਸਰਵਿਸ ਪ੍ਰੋਵਾਈਡਰ ਤੱਕ ਅਤੇ ਵਾਪਸ ਜਾਣਕਾਰੀ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਪਹੁੰਚਾਉਣਾ।

ਕੀ ਖਰਾਬ ਹੋਇਆ

ਕੇਸ ਦੇ ਵੇਰਵੇ ਸਿੱਧੇ ਹਨ, ਅਤੇ ਇਹੀ ਗੱਲ ਇਸਨੂੰ ਚਿੰਤਾਜਨਕ ਬਣਾਉਂਦੀ ਹੈ। ਯਾਤਰੀ ਨੇ ਕਿਸੇ ਲੁਕਵੀਂ ਫੀਸ 'ਤੇ ਵਿਵਾਦ ਨਹੀਂ ਕੀਤਾ ਜਾਂ ਕਿਸੇ ਨੀਤੀ ਦੀ ਕਮੀ ਨਾਲ ਲੜਾਈ ਨਹੀਂ ਕੀਤੀ। ਉਸਨੇ ਇੱਕ ਆਮ ਕਾਰਵਾਈ ਕੀਤੀ—ਫਲਾਈਟ ਰੱਦ ਕਰਨਾ—ਅਤੇ ਇੱਕ ਅਜਿਹੀ ਗਲਤੀ ਦਾ ਸਾਹਮਣਾ ਕੀਤਾ ਜੋ ਹੋਣੀ ਹੀ ਨਹੀਂ ਚਾਹੀਦੀ ਸੀ। IndiGo ਨੇ ਰੱਦ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਲਿਆ। AirAsia MOVE ਨੇ ਨਹੀਂ। ਨਤੀਜਾ ਇੱਕ ਅਜਿਹੀ ਸਥਿਤੀ ਸੀ ਜਿਸ ਵਿੱਚ ਦੋਵਾਂ ਦਾ ਨੁਕਸਾਨ ਹੋਇਆ। ਯਾਤਰੀ ਨੇ ਸਮਾਂ ਅਤੇ ਮਾਨਸਿਕ ਸ਼ਾਂਤੀ ਗੁਆ ਲਈ। ਪਲੇਟਫਾਰਮ ਨੇ ਆਪਣੀ ਭਰੋਸੇਯੋਗਤਾ ਗੁਆ ਦਿੱਤੀ।

ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਅਸਫਲਤਾ ਆਮ ਤੌਰ 'ਤੇ ਉਸ ਅੰਦਰੂਨੀ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਹੁੰਦੀ ਹੈ ਜਿਸ ਨੂੰ ਯਾਤਰੀ ਕਦੇ ਦੇਖ ਨਹੀਂ ਸਕਦੇ। ਆਨਲਾਈਨ ਟ੍ਰੈਵਲ ਏਜੰਸੀਆਂ ਅਤੇ ਸੁਪਰਐਪਸ (superapps) ਏਅਰਲਾਈਨ ਇਨਵੈਂਟਰੀ ਨੂੰ ਆਪਣੇ ਸਰਵਰਾਂ 'ਤੇ ਸਟੋਰ ਨਹੀਂ ਕਰਦੇ। ਉਹ application programming interfaces, ਜਾਂ APIs ਰਾਹੀਂ ਏਅਰਲਾਈਨਾਂ ਨਾਲ ਜੁੜਦੇ ਹਨ, ਜੋ ਡੇਟਾ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ “cancel” 'ਤੇ ਟੈਪ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੀ ਬੇਨਤੀ ਤੁਹਾਡੇ ਫ਼ੋਨ ਤੋਂ ਐਗਰੀਗੇਟਰ ਦੇ ਬੈਕਐਂਡ (backend) ਤੱਕ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਫਿਰ ਏਅਰਲਾਈਨ ਦੇ ਰਿਜ਼ਰਵੇਸ਼ਨ ਸਿਸਟਮ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ। ਏਅਰਲਾਈਨ ਬੁਕਿੰਗ ਸਟੇਟਸ ਨੂੰ ਅਪਡੇਟ ਕਰਦੀ ਹੈ ਅਤੇ ਇੱਕ ਕਨਫਰਮੇਸ਼ਨ ਭੇਜਦੀ ਹੈ। ਐਗਰੀਗੇਟਰ ਤੋਂ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਉਹ ਉਸ ਤਬਦੀਲੀ ਨੂੰ ਤੁਰੰਤ ਦਰਸਾਵੇ ਅਤੇ ਤੁਹਾਡੇ ਰਿਫੰਡ ਜਾਂ ਟ੍ਰੈਵਲ ਕ੍ਰੈਡਿਟ ਦੀ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰੇ।

ਸ਼ਾਇਦ ਉਸ ਚੇਨ ਵਿੱਚ ਕਿਤੇ AirAsia MOVE ਰੁਕ ਗਿਆ। ਸ਼ਾਇਦ API IndiGo ਦੇ ਸਿਸਟਮ ਤੋਂ ਅਪਡੇਟ ਕੀਤੇ ਸਟੇਟਸ ਨੂੰ ਲੈਣ ਵਿੱਚ ਅਸਫਲ ਰਿਹਾ। ਸ਼ਾਇਦ ਐਪ ਦੇ ਅੰਦਰੂਨੀ ਲੌਜਿਕ (logic) ਵਿੱਚ ਕੋਈ ਅਜਿਹਾ ਹਾਰਡਕੋਡਡ ਨਿਯਮ ਸੀ ਜਿਸ ਨੇ ਏਅਰਲਾਈਨ ਦੇ ਜਵਾਬ ਨੂੰ ਰੱਦ ਕਰ ਦਿੱਤਾ। ਸ਼ਾਇਦ ਕਸਟਮਰ ਸਰਵਿਸ ਏਜੰਟ ਆਪਣੀਆਂ ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਮਿਸਮੈਚ (mismatch) ਦੇਖ ਸਕਦੇ ਸਨ ਪਰ ਉਨ੍ਹਾਂ ਕੋਲ ਰੱਦ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਅੱਗੇ ਵਧਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਸੀ। ਅਸੀਂ ਸਹੀ ਬੱਗ (bug) ਬਾਰੇ ਨਹੀਂ ਜਾਣਦੇ, ਪਰ ਅਸੀਂ ਨਤੀਜਾ ਜਾਣਦੇ ਹਾਂ: ਇੱਕ ਇਨਸਾਨ ਸੌਫਟਵੇਅਰ ਲੂਪ ਵਿੱਚ ਫਸ ਗਿਆ ਸੀ, ਅਤੇ ਉਸ ਲੈਣ-ਦੇਣ ਨੂੰ ਰੱਦ ਕਰਨ ਵਿੱਚ ਅਸਮਰੱਥ ਸੀ ਜਿਸ ਨੂੰ ਰੱਦ ਕਰਨ ਲਈ ਹਰ ਪਾਰਟੀ ਸਹਿਮਤ ਸੀ।

ਭਰੋਸਾ ਕੋਡ ਫਿਕਸਾਂ ਨਾਲੋਂ ਤੇਜ਼ੀ ਨਾਲ ਕਿਉਂ ਘਟਦਾ ਹੈ

ਯਾਤਰੀ ਕੱਚੇ ਜਾਂ ਮਾੜੇ ਇੰਟਰਫੇਸਾਂ ਨੂੰ ਸਹਿ ਲੈਂਦੇ ਹਨ। ਉਹ ਲੋਡ ਹੋਣ ਵਿੱਚ ਲੱਗਣ ਵਾਲੇ ਸਮੇਂ ਨੂੰ ਸਹਿ ਲੈਂਦੇ ਹਨ। ਪਰ ਜਦੋਂ ਪੈਸੇ ਅਤੇ ਯੋਜਨਾਵਾਂ ਦਾ ਸਵਾਲ ਹੋਵੇ, ਤਾਂ ਉਹ ਬੇਵਸੀ ਨੂੰ ਸਹਿ ਨਹੀਂ ਸਕਦੇ। ਰੱਦ ਕਰਨ ਦੀ ਬੇਨਤੀ ਕੋਈ ਮਾਮੂਲੀ ਬੇਨਤੀ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਕਿਸੇ ਸੰਕਟ ਤੋਂ ਬਾਅਦ ਹੁੰਦੀ ਹੈ—ਜਿਵੇਂ ਕਿ ਕੋਈ ਡਾਕਟਰੀ ਸਮੱਸਿਆ, ਪਰਿਵਾਰਕ ਐਮਰਜੈਂਸੀ, ਜਾਂ ਅਚਾਨਕ ਕੰਮ ਦਾ ਕੋਈ ਟਕਰਾਅ। ਯੂਜ਼ਰ ਪਹਿਲਾਂ ਹੀ ਤਣਾਅ ਵਿੱਚ ਹੁੰਦਾ ਹੈ। ਐਪ ਦੀ ਭੂਮਿਕਾ ਬੈਕਐਂਡ ਦੀ ਗੁੰਝਲਤਾ ਨੂੰ ਸੰਭਾਲ ਕੇ ਉਸ ਤਣਾਅ ਨੂੰ ਘਟਾਉਣਾ ਹੈ। ਜਦੋਂ ਇਹ ਇਸ ਦੀ ਬਜਾਏ ਇੱਕ ਨਵੀਂ ਰੁਕਾਵਟ ਪੈਦਾ ਕਰਦੀ ਹੈ, ਤਾਂ ਇਸਦਾ ਭਾਵਨਾਤਮਕ ਨੁਕਸਾਨ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੁੰਦਾ ਹੈ।

ਇਸੇ ਕਰਕੇ ਯਾਤਰੀ ਦਾ ਜਨਤਕ ਰੋਸ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਉਸਨੇ ਕਿਸੇ ਗੁੰਮ ਹੋਏ ਲੋਇਲਟੀ ਪੁਆਇੰਟ ਜਾਂ ਦੇਰੀ ਨਾਲ ਆਉਣ ਵਾਲੇ ਪੁਸ਼ ਨੋਟੀਫਿਕੇਸ਼ਨ ਬਾਰੇ ਸ਼ਿਕਾਇਤ ਨਹੀਂ ਕੀਤੀ। ਉਸਨੇ ਪਲੇਟਫਾਰਮ ਨੂੰ ਬੇਕਾਰ ਦੱਸਿਆ ਕਿਉਂਕਿ ਜਦੋਂ ਉਸਨੂੰ ਇਸਦੀ ਸਭ ਤੋਂ ਵੱਧ ਲੋੜ ਸੀ, ਤਾਂ ਇਸਨੇ ਇੱਕ ਜਾਇਜ਼ ਬੇਨਤੀ ਨੂੰ ਰੋਕ ਦਿੱਤਾ। ਡਿਜੀਟਲ ਸੇਵਾਵਾਂ ਵਿੱਚ ਭਰੋਸਾ ਇਸ ਵਿਸ਼ਵਾਸ 'ਤੇ ਬਣਿਆ ਹੁੰਦਾ ਹੈ ਕਿ ਹਾਲਾਤ ਬਦਲਣ 'ਤੇ ਵੀ ਸਿਸਟਮ ਤੁਹਾਡੇ ਇਰਾਦੇ ਦਾ ਸਤਿ

ਰੱਦ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਬੁਕਿੰਗ ਵਾਂਗ ਹੀ ਸਰਲ ਬਣਾਓ। ਜੇਕਰ ਕੋਈ ਯੂਜ਼ਰ ਤਿੰਨ ਟੈਪਾਂ ਵਿੱਚ ਸੀਟ ਬੁੱਕ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਚੈਟਬੋਟਾਂ, ਲੁਕੀਆਂ ਹੋਈਆਂ ਮੀਨੂਆਂ ਅਤੇ ਅਸਮਰਥਿਤ ਫਾਰਮਾਂ ਦੀ ਭਿਆਨਕ ਗੁੰਝਲ ਵਿੱਚ ਫਸੇ ਬਿਨਾਂ ਇਸਨੂੰ ਰੱਦ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਰੱਦ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ (cancellation flow) ਸਾਫ਼ ਦਿਖਾਈ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ, ਫੀਸਾਂ ਬਾਰੇ ਇਮਾਨਦਾਰ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਇਸ ਵਿੱਚ ਅਜਿਹੇ 'ਡਾਰਕ ਪੈਟਰਨਜ਼' (dark patterns) ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ ਜੋ ਯਾਤਰੀਆਂ ਨੂੰ ਦੋਸ਼ੀ ਮਹਿਸੂਸ ਕਰਵਾ ਕੇ ਜਾਂ ਉਲਝਾ ਕੇ ਅਜਿਹੀ ਰਿਜ਼ਰਵੇਸ਼ਨ ਰੱਖਣ ਲਈ ਮਜਬੂਰ ਕਰਨ ਜੋ ਉਹ ਵਰਤ ਨਹੀਂ ਸਕਦੇ।

ਅਜਿਹੇ ਮੈਨੂਅਲ ਓਵਰਰਾਈਡਸ (manual overrides) ਬਣਾਓ ਜੋ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰਨ। ਆਟੋਮੇਸ਼ਨ ਉਦੋਂ ਤੱਕ ਸ਼ਾਨਦਾਰ ਹੈ ਜਦੋਂ ਤੱਕ ਇਹ ਫੇਲ ਨਹੀਂ ਹੁੰਦੀ। ਜਦੋਂ ਕੋਈ API ਰਿਟਰਨ ਕੰਫਲਿਕਟ ਜਾਂ ਸਿੰਕ (sync) ਐਰਰ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਕਸਟਮਰ ਸਰਵਿਸ ਏਜੰਟਾਂ ਕੋਲ ਦਖਲ ਦੇਣ ਲਈ ਅਧਿਕਾਰ ਅਤੇ ਇੰਟਰਫੇਸ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਪਲੇਟਫਾਰਮ ਅਜਿਹੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਆਟੋਮੇਟਡ ਕਿਲ੍ਹੇ ਬਣਾਉਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਮਨੁੱਖੀ ਦਖਲਅੰਦਾਜ਼ੀ ਲਈ ਕੋਈ ਦਰਵਾਜ਼ਾ ਨਹੀਂ ਹੁੰਦਾ। ਏਜੰਟ ਅੰਤ ਵਿੱਚ ਸਿਰਫ਼ ਸਕ੍ਰਿਪਟਾਂ ਪੜ੍ਹਦੇ ਹਨ, ਲਗਾਤਾਰ ਮੁਆਫੀ ਮੰਗਦੇ ਹਨ, ਅਤੇ ਟਿਕਟਾਂ ਅਜਿਹੇ 'ਬਲੈਕ ਹੋਲ' ਵਿੱਚ ਭੇਜ ਦਿੰਦੇ ਹਨ ਜਿੱਥੋਂ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਆਉਂਦਾ। ਇੱਕ ਲਾਭਦਾਇਕ ਓਵਰਰਾਈਡ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕ ਏਜੰਟ ਏਅਰਲਾਈਨ ਦੀ ਮਨਜ਼ੂਰੀ ਦੇਖ ਸਕਦਾ ਹੈ, ਉਸਦੀ ਤੁਲਨਾ ਰੁਕੀ ਹੋਈ ਬੁਕਿੰਗ ਨਾਲ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਰੀਅਲ-ਟਾਈਮ ਵਿੱਚ ਰੱਦ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਪੂਰਾ ਕਰ ਸਕਦਾ ਹੈ।

ਸੌਫਟਵੇਅਰ ਨੂੰ ਏਅਰਲਾਈਨ ਦੀ ਅਸਲੀਅਤ ਦੇ ਨਾਲ ਸਿੰਕ (sync) ਰੱਖੋ। ਟ੍ਰੈਵਲ ਪਲੇਟਫਾਰਮਾਂ ਨੂੰ ਬੈਚ ਅਪਡੇਟਸ ਅਤੇ ਹੌਲੀ ਪੋਲਿੰਗ ਸਾਈਕਲਜ਼ ਤੋਂ ਦੂਰ ਹੋਣ ਦੀ ਲੋੜ ਹੈ। ਜੇਕਰ ਕੋਈ ਏਅਰਲਾਈਨ ਟਿਕਟ ਨੂੰ ਰੱਦ ਕਰਨਯੋਗ (cancellable), ਰਿਫੰਡਯੋਗ (refundable), ਜਾਂ ਰੀ-ਸ਼ਡਿਊਲ ਕਰਨਯੋਗ ਵਜੋਂ ਮਾਰਕ ਕਰਦੀ ਹੈ, ਤਾਂ ਐਗਰੀਗੇਟਰ ਨੂੰ ਘੰਟਿਆਂ ਦੀ ਬਜਾਏ ਮਿੰਟਾਂ ਵਿੱਚ ਪਤਾ ਲੱਗ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਲਈ ਮਜ਼ਬੂਤ ਵੈੱਬਹੂਕ ਆਰਕੀਟੈਕਚਰ (webhook architecture), ਫੇਲ ਹੋਏ ਹੈਂਡਸ਼ੇਕਸ ਲਈ ਰੀਟ੍ਰਾਈ ਲੌਜਿਕ (retry logic), ਅਤੇ ਰੀਕੰਸੀਲੀਏਸ਼ਨ ਜੌਬਸ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਯੂਜ਼ਰ ਦੇ ਪਤਾ ਲਗਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਗਲਤੀਆਂ ਨੂੰ ਫੜ ਲੈਣ। ਪਲੇਟਫਾਰਮ ਨੂੰ ਆਪਣੇ ਖੁਦ ਦੇ ਉਤਪਾਦ ਦੀ ਸਥਿਤੀ ਬਾਰੇ ਸਭ ਤੋਂ ਆਖਰੀ ਵਿੱਚ ਪਤਾ ਨਹੀਂ ਲੱਗਣਾ ਚਾਹੀਦਾ।

ਯਾਤਰੀ ਹੁਣ ਕੀ ਕਰ ਸਕਦੇ ਹਨ

ਜਦੋਂ ਤੱਕ ਉਦਯੋਗ ਇਹਨਾਂ ਕਮੀਆਂ ਨੂੰ ਸੁਧਾਰਦਾ ਨਹੀਂ ਹੈ, ਯਾਤਰੀਆਂ ਨੂੰ ਆਪਣੀ ਸੁਰੱਖਿਆ ਖੁਦ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਤੀਜੀ-ਪਾਰਟੀ ਐਪ ਰਾਹੀਂ ਬੁਕਿੰਗ ਕਰ ਰਹੇ ਹੋ, ਜਿਸ ਵਿੱਚ AirAsia MOVE ਵਰਗੀਆਂ ਵੱਡੀਆਂ ਐਪਸ ਵੀ ਸ਼ਾਮਲ ਹਨ, ਤਾਂ ਸਾਰੇ ਸਬੂਤ (paper trail) ਆਪਣੇ ਕੋਲ ਰੱਖੋ। ਆਪਣੇ ਕਨਫਰਮੇਸ਼ਨ ਨੰਬਰਾਂ, ਰੱਦ ਕਰਨ ਦੀਆਂ ਨੀਤੀਆਂ, ਅਤੇ ਏਅਰਲਾਈਨ ਤੋਂ ਹੋਈ ਕਿਸੇ ਵੀ ਗੱਲਬਾਤ ਦੇ ਸਕ੍ਰੀਨਸ਼ੌਟ ਲੈ ਕੇ ਰੱਖੋ। ਟਿਕਟ ਖਰੀਦਣ ਤੋਂ ਪਹਿਲਾਂ ਏਅਰਲਾਈਨ ਦੀ ਆਪਣੀ ਨੀਤੀ ਬਾਰੇ ਜਾਣੋ; ਕੁਝ ਕੈਰੀਅਰ ਭਾਵੇਂ ਪਾਰਟਨਰਾਂ ਦੁਆਰਾ ਵੇਚੀਆਂ ਗਈਆਂ ਟਿਕਟਾਂ ਲਈ ਵੀ ਆਪਣੀ ਵੈੱਬਸਾਈਟ ਰਾਹੀਂ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਬਦਲਾਅ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ। ਜੇਕਰ ਐਪ ਕੰਮ ਨਹੀਂ ਕਰਦੀ, ਤਾਂ ਸਿੱਧਾ ਏਅਰਲਾਈਨ ਨਾਲ ਸੰਪਰਕ ਕਰੋ। ਜਦੋਂ ਜਨਤਕ ਪੋਸਟਾਂ (public posts) ਪ੍ਰਭਾਵ ਪਾਉਂਦੀਆਂ ਹਨ, ਤਾਂ ਕੰਪਨੀਆਂ ਨਿੱਜੀ ਸਪੋਰਟ ਚੈਨਲਾਂ ਨਾਲੋਂ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। ਅਤੇ ਜੇਕਰ ਕੋਈ ਵੱਡੀ ਰਕਮ ਫਸੀ ਹੋਈ ਹੈ, ਤਾਂ ਉਪਭੋਗਤਾ ਸੁਰੱਖਿਆ ਫੋਰਮਾਂ (consumer protection forums) ਜਾਂ ਚਾਰਜਬੈਕ ਮਕੈਨਿਜ਼ਮ ਰਾਹੀਂ ਸ਼ਿਕਾਇਤ ਕਰਨ ਤੋਂ ਨਾ ਝਿਜਕੋ।

ਅਸਲ ਸਿੱਖਿਆ

ਕਸਟਮਰ ਐਕਸਪੀਰੀਅੰਸ ਕੋਈ ਅਜਿਹੀ ਚੀਜ਼ ਨਹੀਂ ਹੈ ਜੋ ਕੋਡ ਲਿਖਣ ਤੋਂ ਬਾਅਦ ਸਿਰਫ਼ ਸੁੰਦਰਤਾ ਲਈ ਲਗਾਈ ਜਾਂਦੀ ਹੈ। ਇਹ ਉਹ ਕੋਡ ਹੈ ਜੋ ਉਦੋਂ ਸਹੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਸਥਿਤੀਆਂ ਉਲਝ ਜਾਂਦੀਆਂ ਹਨ। ਇੱਕ ਬੁਕਿੰਗ ਪਲੇਟਫਾਰਮ ਜੋ ਉਡਾਣ ਰੱਦ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਉਹ ਬਿਨਾਂ ਰਿਵਰਸ ਗੇਅਰ ਵਾਲੀ ਕਾਰ ਵਾਂਗ ਹੈ। ਇਹ ਅੱਗੇ ਤਾਂ ਬਹੁਤ ਵਧੀਆ ਚੱਲ ਸਕਦੀ ਹੈ, ਪਰ ਜਲਦੀ ਜਾਂ ਦੇਰ ਤੁਹਾਨੂੰ ਪਿੱਛੇ ਹਟਣ ਦੀ ਲੋੜ ਪਵੇਗੀ।

ਯਾਤਰੀ ਜਾਦੂ ਦੀ ਮੰਗ ਨਹੀਂ ਕਰਦੇ। ਉਹ ਅਜਿਹੇ ਸਾਧਨਾਂ ਦੀ ਮੰਗ ਕਰਦੇ ਹਨ ਜੋ ਉਹਨਾਂ ਨੂੰ ਉਲਝਾਏ ਬਿਨਾਂ ਬੁਨਿਆਦੀ ਕਮਾਂਡਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ। AirAsia MOVE ਦੀ ਉਸ ਰੱਦ ਕਰਨ ਦੀ ਬੇਨਤੀ ਨੂੰ ਨਾ ਮੰਨਣਾ ਜਿਸਨੂੰ IndiGo ਪਹਿਲਾਂ ਹੀ ਸਵੀਕਾਰ ਕਰ ਚੁੱਕਾ ਸੀ, ਇਹ ਯਾਦ ਦਿਵਾਉਂਦਾ ਹੈ ਕਿ ਸਹੂਲਤ ਉਦੋਂ ਹੀ ਅਸਲੀ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਪੂਰੀ ਪ੍ਰਕਿਰਿਆ (pipeline) ਸਹੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ। ਜਦੋਂ ਤੱਕ ਟ੍ਰੈਵਲ ਪਲੇਟਫਾਰਮ ਖਰੀਦ ਤੋਂ ਬਾਅਦ ਦੀ ਭਰੋਸੇਯੋਗਤਾ (post-purchase reliability) ਵਿੱਚ ਉਨਾ ਹੀ ਨਿਵੇਸ਼ ਨਹੀਂ ਕਰਦੇ ਜਿੰਨਾ ਉਹ ਗਾਹਕਾਂ ਨੂੰ ਜੋੜਨ (acquisition funnels) ਵਿੱਚ ਕਰਦੇ ਹਨ, ਉਦੋਂ ਤੱਕ ਯੂਜ਼ਰ ਸਾਵਧਾਨ ਰਹਿਣਗੇ। ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਸਾਵਧਾਨ ਰਹਿਣਾ ਵੀ ਚਾਹੀਦਾ ਹੈ।