عندما يتحول الوسيط إلى جدار
قام أحد المسافرين مؤخرًا بحجز رحلة على متن طيران IndiGo عبر منصة AirAsia MOVE. وعندما تغيرت الخطط، طلب إلغاء الرحلة، ووافقت شركة الطيران. وكان من المفترض أن تنتهي القصة عند هذا الحد. ولكن بدلاً من ذلك، رفضت المنصة نفسها معالجة الإلغاء، مما ترك المسافر عالقًا في فجوة بين شركتين. وقد عبّر عن إحباطه علنًا واصفًا النظام بأنه عديم الفائدة وغبي. كان غضبه شديدًا، لكنه سلط الضوء على مشكلة تؤثر على ملايين المسافرين الذين يعتمدون على منصات التجميع (aggregators) لتسهيل حياتهم.
تعد هذه الحادثة حدثًا صغيرًا في الآلة الضخمة للسفر عبر الإنترنت، ومع ذلك فهي تحمل تحذيرًا مدويًا. نحن نحمل هذه التطبيقات لتجنب التنقل بين مواقع شركات الطيران، وبوابات الدفع، ورموز التأكيد. نتوقع من الوسيط أن يسهل الإجراءات، لا أن يعرقلها. عندما تعجز منصة عن تنفيذ عملية إلغاء وافقت عليها شركة الطيران بالفعل، فإنها تفشل في مهمتها الحقيقية الوحيدة: نقل المعلومات بأمانة من المستخدم إلى مزود الخدمة وبالعكس.
ما الذي تعطل
تفاصيل هذه الحالة واضحة ومباشرة، وهذا هو بالضبط ما يجعلها مثيرة للقلق. لم يعترض المسافر على رسوم خفية أو يجادل في ثغرة في السياسات؛ بل قام بإجراء قياسي —إلغاء رحلة— فواجه خطأً لا ينبغي أن يكون موجودًا. وافقت IndiGo على الإلغاء، لكن AirAsia MOVE لم تفعل. وكانت النتيجة موقفًا خاسرًا للطرفين؛ فقد خسر المسافر وقته وراحة باله، وفقدت المنصة مصداقيتها.
يحدث هذا النوع من الفشل عادةً في أعماق الأنظمة التقنية التي لا يراها المسافرون أبدًا. وكالات السفر عبر الإنترنت والتطبيقات الشاملة (superapps) لا تخزن مخزون شركات الطيران على خوادمها الخاصة، بل تتصل بشركات الطيران من خلال واجهات برمجة التطبيقات (APIs) التي تنقل البيانات ذهابًا وإيابًا. عندما تضغط على "إلغاء"، ينتقل طلبك من هاتفك إلى النظام الخلفي (backend) لمنصة التجميع، ثم إلى نظام الحجز الخاص بشركة الطيران. تقوم شركة الطيران بتحديث حالة الحجز وترسل تأكيدًا، ومن المفترض أن تعكس منصة التجميع هذا التغيير فورًا وتعالج عملية استرداد الأموال أو رصيد السفر الخاص بك.
وفي مكان ما على طول هذا التسلسل، تعطلت AirAsia MOVE. ربما فشلت الـ API في جلب الحالة المحدثة من نظام IndiGo. ربما احتوى المنطق البرمجي الداخلي للتطبيق على قاعدة ثابتة (hardcoded rule) تجاوزت رد شركة الطيران. ربما تمكن وكلاء خدمة العملاء من رؤية عدم التطابق على شاشاتهم ولكنهم افتقروا إلى الصلاحيات لفرض عملية الإلغاء. نحن لا نعرف الخطأ البرمجي (bug) بدقة، لكننا نعرف النتيجة: وقع إنسان في فخ حلقة برمجية، عاجزًا عن إلغاء معاملة اتفقت جميع الأطراف على وجوب إلغائها.
لماذا تتآكل الثقة بشكل أسرع من إصلاح الأكواد
يتحمل المسافرون الواجهات المعقدة، ويتحملون بطء وقت التحميل، لكنهم لن يتحملوا العجز عندما تكون الأموال والخطط على المحك. الإلغاء ليس طلبًا تافهًا؛ فعادة ما يأتي بعد أزمة —مشكلة طبية، أو حالة طوارئ عائلية، أو تعارض مفاجئ في العمل. يكون المستخدم مضطربًا بالفعل، ودور التطبيق هو تقليل هذا التوتر من خلال التعامل مع تعقيدات النظام الخلفي. ولكن عندما يضيف التطبيق عائقًا جديدًا بدلاً من ذلك، تكون التكلفة النفسية باهظة.
ولهذا السبب يكتسب انفجار المسافر غضبًا علنيًا أهمية كبيرة. فهو لم يشتكِ من فقدان نقاط الولاء أو تأخر إشعار، بل وصف المنصة بأنها عديمة الفائدة لأنها، في اللحظة التي كان يحتاجها فيها بشدة، منعت طلبًا مشروعًا. تُبنى الثقة في الخدمات الرقمية على الاعتقاد بأن النظام سيحترم نيتك حتى عندما تتغير الظروف. وأي إخلال بهذا الوعد يسبب ضررًا أكبر مما يمكن لعشر عمليات حجز سلسة إصلاحه.
كما تكشف المشكلة أيضًا عن نقطة عمياء استراتيجية في كيفية بناء العديد من منصات السفر. فغالبًا ما تضخ الفرق الهندسية الموارد في الواجهة الأمامية (front end): البحث السريع، والتقاويم الجذابة، والدفع بنقرة واحدة، والعروض المخصصة. هذه هي الميزات التي تدفع عمليات التحميل. أما عمليات ما بعد الحجز —مثل التغييرات والإلغاءات واسترداد الأموال— فتُعامل كأفكار ثانوية؛ حيث تحصل على واجهات برمجة تطبيقات (APIs) قديمة، ومراقبة أقل، وخيارات بديلة محدودة. ولكن هذا هو المكان الذي يكتشف فيه المستخدمون ما إذا كان التطبيق أداة حقيقية أم مجرد كتيب دعائي لامع.
ما يجب على منصات السفر القيام به بشكل صحيح
هناك دروس واضحة هنا لأي شركة تعمل كوسيط بين العملاء وشركات الطيران.
اجعل عمليات الإلغاء بسيطة مثل عمليات الحجز. إذا كان بإمكان المستخدم حجز مقعد بثلاث نقرات، فيجب أن يكون قادرًا على التراجع عن ذلك دون التنقل في متاهة من روبوتات الدردشة، والقوائم المخفية، والنماذج غير المدعومة. يجب أن تكون عملية الإلغاء واضحة، وصادقة بشأن الرسوم، وخالية من "الأنماط المظلمة" التي تهدف إلى إشعار المسافرين بالذنب أو إرباكهم للاحتفاظ بحجز لا يمكنهم استخدامه.
ابنِ خيارات تجاوز يدوية تعمل بالفعل. الأتمتة رائعة حتى تفشل. عندما يحدث تعارض في استجابة الـ API أو خطأ في المزامنة، يجب أن يتمتع وكلاء خدمة العملاء بالسلطة والواجهة اللازمة للتدخل. تصمم الكثير من المنصات حصونًا مؤتمتة بالكامل دون أي أبواب للتدخل البشري. ينتهي الأمر بالوكلاء بقراءة نصوص جاهزة، والاعتذار بلا نهاية، وتقديم تذاكر دعم تضيع في "ثقوب سوداء". التجاوز المفيد يعني أن يتمكن الوكيل من رؤية موافقة شركة الطيران، ومطابقتها مع الحجز العالق، وإتمام عملية الإلغاء في الوقت الفعلي.
حافظ على مزامنة البرمجيات مع واقع شركات الطيران. تحتاج منصات السفر إلى الابتعاد عن التحديثات الجماعية (batch updates) ودورات الاستعلام البطيئة. إذا قامت شركة طيران بتحديد تذكرة على أنها قابلة للإلغاء، أو الاسترداد، أو إعادة الجدولة، فيجب أن يعلم مجمع الحجوزات بذلك في غضون دقائق، وليس ساعات. يتطلب ذلك بنية تحتية قوية لـ webhooks، ومنطق إعادة المحاولة لعمليات المصافحة (handshakes) الفاشلة، ومهام تسوية (reconciliation jobs) تحدد عدم التطابق قبل أن يكتشفه المستخدم. لا ينبغي للمنصة أبدًا أن تكون آخر من يعلم بحالة منتجها الخاص.
ما يمكن للمسافرين فعله الآن
إلى أن تعالج الصناعة هذه الفجوات، يحتاج الركاب إلى حماية أنفسهم. إذا كنت تحجز عبر أي تطبيق تابع لجهة خارجية، بما في ذلك التطبيقات الكبرى مثل AirAsia MOVE، فاحتفظ بسجل للعمليات. التقط صورًا لشاشة أرقام التأكيد، وسياسات الإلغاء، وأي مراسلات من شركة الطيران. تعرف على سياسة شركة الطيران الخاصة قبل الشراء؛ فبعض الناقلات تسمح بإجراء التغييرات مباشرة عبر موقعها الإلكتروني حتى بالنسبة للتذاكر التي تُباع من قبل الشركاء. إذا فشل التطبيق، فاتصل بشركة الطيران مباشرة. عندما تكتسب المنشورات العامة زخمًا، تميل الشركات إلى التحرك بشكل أسرع مما تفعله عبر قنوات الدعم الخاصة. وإذا كان هناك مبلغ كبير عالقًا، فلا تتردد في التصعيد عبر منتديات حماية المستهلك أو آليات استرداد المدفوعات (chargeback).
الخلاصة الحقيقية
تجربة العملاء ليست طبقة من التلميع تضعها بعد كتابة الكود. بل هي عمل الكود بشكل صحيح عندما تصبح الأمور معقدة. منصة الحجز التي لا تستطيع إلغاء رحلة تشبه سيارة بدون ترس للرجوع إلى الخلف؛ قد تسير للأمام بشكل رائع، ولكن عاجلاً أم آجلاً ستحتاج إلى التراجع من مكان ما.
المسافرون لا يطلبون السحر، بل يطلبون أدوات تنفذ الأوامر الأساسية دون تضليلهم. إن فشل AirAsia MOVE في احترام عملية إلغاء كانت شركة IndiGo قد قبلتها بالفعل هو تذكير بأن الراحة لا تكون حقيقية إلا عندما تعمل سلسلة العمليات بأكملها. وإلى أن تستثمر منصات السفر في موثوقية ما بعد الشراء بنفس القدر الذي تستثمره في قنوات جذب العملاء (acquisition funnels)، سيظل المستخدمون في حالة حذر. وهذا هو التصرف الصحيح.