যখন মধ্যস্থতাকারী নিজেই বাধা হয়ে দাঁড়ায়
সম্প্রতি একজন যাত্রী AirAsia MOVE প্ল্যাটফর্মের মাধ্যমে একটি IndiGo ফ্লাইট বুক করেছিলেন। পরিকল্পনা পরিবর্তন হওয়ায় তিনি ট্রিপটি বাতিল করার অনুরোধ জানান। এয়ারলাইনটি তাতে রাজি হয়। গল্পটি সেখানেই শেষ হওয়ার কথা ছিল। কিন্তু পরিবর্তে, প্ল্যাটফর্মটি নিজেই বাতিল প্রক্রিয়া সম্পন্ন করতে অস্বীকার করে, যার ফলে যাত্রীটি দুটি কোম্পানির মাঝখানে আটকে পড়েন। তিনি তার ক্ষোভ জনসমক্ষে প্রকাশ করেন এবং সিস্টেমটিকে অকেজো ও বোকা বলে অভিহিত করেন। তার রাগ ছিল তীব্র, কিন্তু এটি এমন একটি সমস্যার দিকে ইঙ্গিত করে যা লক্ষ লক্ষ ভ্রমণকারীকে প্রভাবিত করে যারা জীবন সহজ করতে অ্যাগ্রিগেটরদের (aggregators) ওপর নির্ভর করেন।
অনলাইন ট্রাভেলের বিশাল যন্ত্রপাতির মধ্যে এই ঘটনাটি একটি ছোট বিষয় মাত্র, তবুও এটি একটি বড় সতর্কবার্তা বহন করে। আমরা এয়ারলাইন ওয়েবসাইট, পেমেন্ট গেটওয়ে এবং কনফার্মেশন কোড নিয়ে হিমশিম খাওয়া এড়াতে এই অ্যাপগুলো ডাউনলোড করি। আমরা আশা করি মধ্যস্থতাকারী প্রক্রিয়াটিকে সহজ করবে, বাধা দেবে না। যখন একটি প্ল্যাটফর্ম সেই বাতিলকরণ প্রক্রিয়াটি সম্পন্ন করতে পারে না যা এয়ারলাইন ইতিমধ্যে অনুমোদন করেছে, তখন এটি তার একমাত্র আসল কাজটিতে ব্যর্থ হয়: ব্যবহারকারীর কাছ থেকে পরিষেবা প্রদানকারীর কাছে এবং পুনরায় ব্যবহারকারীর কাছে তথ্য সঠিকভাবে পৌঁছে দেওয়া।
কী সমস্যা হয়েছিল
এই মামলার বিবরণ অত্যন্ত সহজ, আর এটাই বিষয়টিকে উদ্বেগজনক করে তুলেছে। যাত্রী কোনো লুকানো ফি নিয়ে বিতর্ক করেননি বা কোনো পলিসির ফাঁকফোকর নিয়ে লড়াই করেননি। তিনি একটি সাধারণ কাজ করেছিলেন—একটি ফ্লাইট বাতিল করা—এবং এমন একটি ত্রুটির সম্মুখীন হন যা থাকার কথা নয়। IndiGo বাতিলকরণটি গ্রহণ করেছিল। AirAsia MOVE করেনি। এর ফলাফল ছিল একটি চিরাচরিত 'লস-লস' (lose-lose) পরিস্থিতি। যাত্রী তার সময় এবং মানসিক শান্তি হারিয়েছেন। প্ল্যাটফর্মটি তার বিশ্বাসযোগ্যতা হারিয়েছে।
এই ধরনের ব্যর্থতা সাধারণত সেই জটিল প্রক্রিয়ার গভীরে ঘটে যা ভ্রমণকারীরা কখনও দেখতে পান না। অনলাইন ট্রাভেল এজেন্সি এবং সুপারঅ্যাপগুলো তাদের নিজস্ব সার্ভারে এয়ারলাইনের ইনভেন্টরি জমা রাখে না। তারা API-এর মাধ্যমে এয়ারলাইনের সাথে সংযুক্ত থাকে, যা তথ্য আদান-প্রদান করে। আপনি যখন “cancel” ট্যাপ করেন, আপনার অনুরোধ আপনার ফোন থেকে অ্যাগ্রিগেটরের ব্যাকএন্ডে যায়, তারপর এয়ারলাইনের রিজার্ভেশন সিস্টেমে পৌঁছায়। এয়ারলাইন বুকিংয়ের স্ট্যাটাস আপডেট করে এবং একটি কনফার্মেশন পাঠায়। অ্যাগ্রিগেটরের কাজ হলো সেই পরিবর্তনটি সাথে সাথে প্রতিফলিত করা এবং আপনার রিফান্ড বা ট্রাভেল ক্রেডিট প্রসেস করা।
সেই চেইনের কোথাও AirAsia MOVE থমকে গিয়েছিল। সম্ভবত APIটি IndiGo-র সিস্টেম থেকে আপডেট হওয়া স্ট্যাটাসটি সংগ্রহ করতে ব্যর্থ হয়েছিল। সম্ভবত অ্যাপের অভ্যন্তরীণ লজিকের মধ্যে এমন কোনো হার্ডকোডেড (hardcoded) নিয়ম ছিল যা এয়ারলাইনের রেসপন্সকে অগ্রাহ্য করে। সম্ভবত কাস্টমার সার্ভিস এজেন্টরা তাদের স্ক্রিনে অমিলটি দেখতে পাচ্ছিলেন কিন্তু বাতিলকরণটি জোরপূর্বক সম্পন্ন করার অনুমতি তাদের ছিল না। আমরা সঠিক বাগ (bug) সম্পর্কে জানি না, তবে আমরা ফলাফল জানি: একজন মানুষ একটি সফটওয়্যার লুপের মধ্যে আটকা পড়েছিলেন, এমন একটি লেনদেন বাতিল করতে অক্ষম ছিলেন যা প্রতিটি পক্ষই বাতিল করতে সম্মত হয়েছিল।
কেন কোড ফিক্সের চেয়ে দ্রুত বিশ্বাস নষ্ট হয়
ভ্রমণকারীরা অগোছালো ইন্টারফেস সহ্য করেন। তারা ধীরগতির লোডিং টাইম সহ্য করেন। কিন্তু যখন টাকা এবং পরিকল্পনা ঝুঁকির মুখে থাকে, তখন তারা অসহায়ত্ব সহ্য করবেন না। একটি বাতিলকরণ কোনো তুচ্ছ অনুরোধ নয়। এটি সাধারণত কোনো সংকট—যেমন চিকিৎসা সংক্রান্ত সমস্যা, পারিবারিক জরুরি অবস্থা বা হঠাৎ কাজের চাপের পর আসে। ব্যবহারকারী ইতিমধ্যে মানসিক চাপে থাকেন। ব্যাকএন্ডের জটিলতা সামলে সেই চাপ কমানোই অ্যাপের কাজ। যখন এটি পরিবর্তে নতুন বাধা তৈরি করে, তখন এর মানসিক প্রভাব অনেক বেশি হয়।
এই কারণেই যাত্রীর জনসমক্ষে ক্ষোভ প্রকাশ করাটা গুরুত্বপূর্ণ। তিনি কোনো মিসিং লয়্যালটি পয়েন্ট বা বিলম্বিত পুশ নোটিফিকেশন নিয়ে অভিযোগ করেননি। তিনি প্ল্যাটফর্মটিকে অকেজো বলেছিলেন কারণ, যখন তার এটি সবচেয়ে বেশি প্রয়োজন ছিল, তখন এটি একটি বৈধ অনুরোধকে সক্রিয়ভাবে বাধা দিয়েছিল। ডিজিটাল পরিষেবার ওপর বিশ্বাস গড়ে ওঠে এই বিশ্বাসে যে, পরিস্থিতি পরিবর্তন হলেও সিস্টেম আপনার উদ্দেশ্যকে সম্মান করবে। সেই প্রতিশ্রুতির একটি মাত্র লঙ্ঘন দশটি মসৃণ বুকিংয়ের চেয়েও বেশি ক্ষতি করতে পারে।
এই সমস্যাটি অনেক ট্রাভেল প্ল্যাটফর্ম কীভাবে তৈরি করা হয় তার একটি কৌশলগত অন্ধত্বকেও প্রকাশ করে। ইঞ্জিনিয়ারিং টিমগুলো প্রায়ই ফ্রন্ট এন্ডের (front end) পেছনে প্রচুর সম্পদ ব্যয় করে: দ্রুত সার্চ, সুন্দর ক্যালেন্ডার, ওয়ান-ট্যাপ চেকআউট, ব্যক্তিগতকৃত ডিল। এগুলোই হলো সেই ফিচার যা ডাউনলোড বাড়াতে সাহায্য করে। বুকিং পরবর্তী কার্যক্রম—পরিবর্তন, বাতিলকরণ, রিফান্ড—সেগুলোকে অবহেলিত বিষয় হিসেবে দেখা হয়। এগুলো পুরনো API, কম মনিটরিং এবং কম বিকল্প সুবিধা পায়। কিন্তু ঠিক এখানেই ব্যবহারকারীরা আবিষ্কার করেন যে একটি অ্যাপ কি সত্যিই একটি কার্যকর টুল নাকি কেবল একটি চকচকে ব্রোশার।
ট্রাভেল প্ল্যাটফর্মগুলোকে যা সঠিকভাবে করতে হবে
গ্রাহক এবং এয়ারলাইনের মাঝে অবস্থানকারী যেকোনো কোম্পানির জন্য এখানে স্পষ্ট শিক্ষা রয়েছে।
বাতিল করার প্রক্রিয়াকেও বুকিংয়ের মতোই সহজ করুন। যদি একজন ব্যবহারকারী মাত্র তিনটি ট্যাপে একটি আসন বুক করতে পারেন, তবে চ্যাটবট, লুকানো মেনু এবং অকার্যকর ফর্মের গোলকধাঁধায় না হারিয়েই তাদের সেটি বাতিল করার সুযোগ থাকা উচিত। বাতিলের প্রক্রিয়াটি দৃশ্যমান হওয়া উচিত, ফি সম্পর্কে স্বচ্ছ হওয়া উচিত এবং এমন কোনো 'ডার্ক প্যাটার্ন' (dark patterns) মুক্ত হওয়া উচিত যা ভ্রমণকারীদের অপরাধবোধে ভোগিয়ে বা বিভ্রান্ত করে এমন একটি রিজার্ভেশন রাখতে বাধ্য করে যা তারা ব্যবহার করতে পারবেন না।
কার্যকর ম্যানুয়াল ওভাররাইড (manual overrides) তৈরি করুন। অটোমেশন ততক্ষণই চমৎকার যতক্ষণ না এটি ব্যর্থ হয়। যখন কোনো API রিটার্ন কনফ্লিক্ট বা সিঙ্ক (sync) ত্রুটি ঘটে, তখন কাস্টমার সার্ভিস এজেন্টদের হস্তক্ষেপ করার জন্য প্রয়োজনীয় ক্ষমতা এবং ইন্টারফেস থাকা আবশ্যক। অনেক প্ল্যাটফর্ম এমনভাবে সম্পূর্ণ স্বয়ংক্রিয় দুর্গ তৈরি করে যেখানে মানুষের হস্তক্ষেপের কোনো সুযোগ থাকে না। ফলে এজেন্টরা কেবল স্ক্রিপ্ট পড়ে যান, অন্তহীন ক্ষমা প্রার্থনা করেন এবং এমন সব টিকিট ফাইল করেন যা কোনো সমাধান ছাড়াই হারিয়ে যায়। একটি কার্যকর ওভাররাইড মানে হলো একজন এজেন্ট এয়ারলাইন্সের অনুমোদন দেখতে পাবেন, আটকে থাকা বুকিংয়ের সাথে তা মিলিয়ে দেখতে পারবেন এবং রিয়েল টাইমে বাতিল করার প্রক্রিয়াটি সম্পন্ন করতে পারবেন।
সফটওয়্যারকে এয়ারলাইন্সের বাস্তবতার সাথে সামঞ্জস্যপূর্ণ রাখুন। ট্রাভেল প্ল্যাটফর্মগুলোকে ব্যাচ আপডেট এবং ধীরগতির পোলিং সাইকেল (polling cycles) থেকে বেরিয়ে আসতে হবে। যদি কোনো এয়ারলাইন্স একটি টিকিট বাতিলযোগ্য, রিফান্ডযোগ্য বা পুনঃনির্ধারিত (rescheduled) হিসেবে চিহ্নিত করে, তবে অ্যাগ্রিগেটরটির তা কয়েক ঘণ্টার বদলে কয়েক মিনিটের মধ্যেই জানা উচিত। এর জন্য প্রয়োজন শক্তিশালী webhook আর্কিটেকচার, ব্যর্থ হ্যান্ডশেকের জন্য রিট্রাই লজিক (retry logic) এবং রিকনসিলিয়েশন জবস (reconciliation jobs) যা ব্যবহারকারী জানার আগেই অমিলগুলো শনাক্ত করতে পারে। প্ল্যাটফর্মটিকে কখনোই তার নিজস্ব পণ্যের স্ট্যাটাস জানার ক্ষেত্রে সবার শেষে থাকা উচিত নয়।
ভ্রমণকারীরা এখন যা করতে পারেন
যতক্ষণ না এই শিল্পটি এই ত্রুটিগুলো সংশোধন করছে, ততক্ষণ যাত্রীদের নিজেদের সুরক্ষা নিশ্চিত করতে হবে। আপনি যদি AirAsia MOVE-এর মতো বড় কোনো থার্ড-পার্টি অ্যাপের মাধ্যমে বুকিং করেন, তবে সবকিছুর প্রমাণ বা রেকর্ড রাখুন। আপনার কনফার্মেশন নম্বর, বাতিলের নীতিমালা এবং এয়ারলাইন্স থেকে আসা যেকোনো যোগাযোগের স্ক্রিনশট নিয়ে রাখুন। কেনার আগে এয়ারলাইন্সের নিজস্ব নীতিমালা জেনে নিন; কিছু এয়ারলাইন্স পার্টনারদের মাধ্যমে বিক্রি করা টিকিটের ক্ষেত্রেও তাদের ওয়েবসাইটের মাধ্যমে সরাসরি পরিবর্তন করার সুযোগ দেয়। যদি অ্যাপটি কাজ না করে, তবে সরাসরি এয়ারলাইন্সের সাথে যোগাযোগ করুন। যখন পাবলিক পোস্টগুলো মানুষের দৃষ্টি আকর্ষণ করে, তখন কোম্পানিগুলো ব্যক্তিগত সাপোর্ট চ্যানেলের তুলনায় দ্রুত পদক্ষেপ নিতে বাধ্য হয়। আর যদি বড় অঙ্কের টাকা আটকে থাকে, তবে কনজিউমার প্রোটেকশন ফোরাম বা চার্জব্যাক মেকানিজমের মাধ্যমে বিষয়টি গুরুত্বের সাথে উত্থাপন করতে দ্বিধা করবেন না।
মূল শিক্ষা
কাস্টমার এক্সপেরিয়েন্স বা গ্রাহক অভিজ্ঞতা হলো কোড লেখার পর উপরে লাগানো কোনো পলিশ নয়। এটি হলো জীবন যখন জটিল হয়ে ওঠে, তখন কোডটি সঠিকভাবে কাজ করা। যে বুকিং প্ল্যাটফর্ম একটি ফ্লাইট বাতিল করতে পারে না, তা রিভার্স গিয়ারহীন গাড়ির মতো। এটি হয়তো সামনে খুব সুন্দরভাবে চলতে পারে, কিন্তু আজ হোক বা কাল, আপনার একটি জায়গা থেকে পেছনে আসার প্রয়োজন হবেই।
ভ্রমণকারীরা কোনো জাদুর দাবি করেন না। তারা এমন টুলস চান যা তাদের বিভ্রান্ত না করে সাধারণ কমান্ডগুলো কার্যকর করতে পারে। IndiGo ইতিমধ্যে একটি বাতিলকরণ গ্রহণ করার পরেও AirAsia MOVE-এর তা মেনে নিতে ব্যর্থ হওয়া একটি অনুস্মারক যে, সুবিধা তখনই প্রকৃত হয় যখন পুরো পাইপলাইনটি সঠিকভাবে কাজ করে। ট্রাভেল প্ল্যাটফর্মগুলো যতক্ষণ না পণ্য কেনার পরবর্তী নির্ভরযোগ্যতায় (post-purchase reliability) পণ্য সংগ্রহের কৌশলের (acquisition funnels) মতো সমানভাবে বিনিয়োগ করবে, ততক্ষণ ব্যবহারকারীরা সতর্ক থাকবে। এবং তাদের সতর্ক থাকা উচিত।