زمانی که واسطه به دیوار تبدیل میشود
مسافری اخیراً یک پرواز IndiGo را از طریق پلتفرم AirAsia MOVE رزرو کرده بود. وقتی برنامهها تغییر کرد، او درخواست لغو سفر را داد. ایرلاین موافقت کرد. این باید پایان داستان میبود. اما در عوض، خودِ پلتفرم از انجام لغو درخواست خودداری کرد و مسافر را در شکاف میان دو شرکت سردرگم رها کرد. او ناراحتی خود را به صورت عمومی ابراز کرد و سیستم را بیفایده و احمق خواند. خشم او خالصانه بود، اما به مشکلی اشاره داشت که میلیونها مسافر را که برای سادهتر کردن زندگی خود به تجمیعکنندهها (aggregators) متکی هستند، تحت تأثیر قرار میدهد.
این حادثه اتفاق کوچکی در ماشینآلات عظیم سفر آنلاین است، اما هشدار بلندی به همراه دارد. ما این اپلیکیشنها را دانلود میکنیم تا از سر و کله زدن با وبسایتهای ایرلاینها، درگاههای پرداخت و کدهای تأیید بینیاز شویم. ما انتظار داریم واسطه چرخها را روان کند، نه اینکه آنها را قفل کند. وقتی یک پلتفرم نمیتواند لغوی را که ایرلاین قبلاً تأیید کرده است اجرا کند، در تنها وظیفه واقعی خود شکست میخورد: انتقال صادقانه اطلاعات از کاربر به ارائهدهنده خدمات و بازگشت آن.
چه چیزی از کار افتاد
جزئیات این مورد ساده است و دقیقاً همین موضوع آن را نگرانکننده میکند. مسافر بر سر یک هزینه پنهان بحث نکرد یا با یک loophole (رخنه) در سیاستها مبارزه نکرد. او یک اقدام استاندارد انجام داد — لغو یک پرواز — و با خطایی مواجه شد که نباید وجود داشته باشد. IndiGo لغو را پذیرفت، اما AirAsia MOVE نه. نتیجه یک موقعیت کلاسیکِ باخت-باخت بود. مسافر زمان و آرامش خود را از دست داد و پلتفرم اعتبار خود را.
این نوع شکست معمولاً در اعماق زیرساختهای پنهانی رخ میدهد که مسافران هرگز نمیبینند. آژانسهای آنلاین سفر و superapps، موجودی ایرلاینها را در سرورهای خود ذخیره نمیکنند. آنها از طریق رابطهای برنامهنویسی کاربردی یا همان APIها به ایرلاینها متصل میشوند که دادهها را به صورت رفت و برگشتی منتقل میکنند. وقتی روی «لغو» (cancel) ضربه میزنید، درخواست شما از گوشی شما به backend تجمیعکننده و سپس به سیستم رزرو ایرلاین ارسال میشود. ایرلاین وضعیت رزرو را بهروزرسانی کرده و تأییدیهای میفرستد. تجمیعکننده باید آن تغییر را بلافاصله منعکس کرده و بازپرداخت یا اعتبار سفر شما را پردازش کند.
در جایی از این زنجیره، AirAsia MOVE از کار افتاد. شاید API در دریافت وضعیت بهروز شده از سیستم IndiGo شکست خورده بود. شاید منطق داخلی اپلیکیشن حاوی یک قانون hardcoded بود که پاسخ ایرلاین را نادیده میگرفت. شاید کارشناسان خدمات مشتری میتوانستند عدم تطابق را در صفحهشان ببینند اما اجازه اجبار برای انجام لغو را نداشتند. ما باگ دقیق را نمیدانیم، اما نتیجه را میدانیم: یک انسان در یک حلقه نرمافزاری گرفتار شده بود، در حالی که قادر نبود تراکنشی را که همه طرفها بر لغو آن توافق داشتند، لغو کند.
چرا اعتماد سریعتر از اصلاح کدها فرسوده میشود
مسافران رابطهای کاربری دشوار را تحمل میکنند. آنها زمان بارگذاری کند را تحمل میکنند. اما وقتی پول و برنامهها در خطر باشند، درماندگی را تحمل نخواهند کرد. لغو یک درخواست بیاهمیت نیست. معمولاً پس از یک بحران رخ میدهد — یک مشکل پزشکی، یک وضعیت اضطراری خانوادگی یا یک تداخل کاری ناگهانی. کاربر از قبل تحت استرس است. نقش اپلیکیشن این است که با مدیریت پیچیدگیهای backend، آن استرس را کاهش دهد. وقتی اپلیکیشن در عوض مانع جدیدی ایجاد میکند، هزینه عاطفی آن بسیار سنگین است.
به همین دلیل است که خشم علنی این مسافر اهمیت دارد. او درباره گم شدن یک امتیاز وفاداری یا تأخیر در یک push notification شکایت نکرد. او پلتفرم را بیفایده توصیف کرد زیرا در لحظهای که بیش از هر زمان دیگری به آن نیاز داشت، فعالانه یک درخواست قانونی را مسدود کرد. اعتماد به خدمات دیجیتال بر این باور استوار است که سیستم حتی زمانی که شرایط تغییر میکند، به قصد و نیت شما احترام میگذارد. یک بار نقض این وعده، آسیب بیشتری نسبت به ده رزرو بینقص دارد که میتواند ترمیم کند.
این مشکل همچنین یک نقطه کور استراتژیک را در نحوه ساخت بسیاری از پلتفرمهای سفر آشکار میکند. تیمهای مهندسی اغلب منابع خود را صرف بخش front end میکنند: جستجوی سریع، تقویمهای زیبا، پرداخت با یک ضربه و پیشنهادهای شخصیسازی شده. اینها ویژگیهایی هستند که باعث دانلود اپلیکیشن میشوند. عملیاتهای پس از رزرو — تغییرات، لغوها و بازپرداختها — به عنوان مسائل ثانویه در نظر گرفته میشوند. آنها از APIهای قدیمیتر، نظارت کمتر و گزینههای جایگزین کمتری برخوردارند. اما دقیقاً همینجاست که کاربران کشف میکنند آیا یک اپلیکیشن یک ابزار واقعی است یا فقط یک بروشور براق.
آنچه پلتفرمهای سفر باید به درستی انجام دهند
درسهای روشنی برای هر شرکتی که بین مشتریان و ایرلاینها قرار دارد، در اینجا وجود دارد.
لغو کردن را به سادگیِ رزرو کنید. اگر کاربر میتواند با سه ضربه صندلی رزرو کند، باید بتواند بدون سردرگمی در هزارتوی چتباتها، منوهای پنهان و فرمهای پشتیبانینشده، آن را لغو کند. فرآیند لغو باید شفاف باشد، درباره هزینهها صادق باشد و فاقد الگوهای تاریک (dark patterns) باشد که مسافران را با ایجاد احساس گناه یا گیج کردن، مجبور به نگه داشتن رزروی میکنند که نمیتوانند از آن استفاده کنند.
سیستمهای جایگزین دستی بسازید که واقعاً کار کنند. اتوماسیون تا زمانی که شکست نخورد، فوقالعاده است. وقتی تداخل در پاسخ API یا خطای همگامسازی (sync error) رخ میدهد، کارشناسان خدمات مشتری باید اختیار و رابط کاربری لازم برای مداخله را داشته باشند. بسیاری از پلتفرمها قلعههایی کاملاً خودکار طراحی میکنند که هیچ دری برای مداخله انسانی ندارند. در نهایت کارشناسان مجبور میشوند از روی متنهای از پیش تعیینشده بخوانند، بیپایان عذرخواهی کنند و تیکتهایی را ثبت کنند که در سیاهچالهها گم میشوند. یک سیستم جایگزین کاربردی به این معناست که کارشناس بتواند تأییدیه ایرلاین را ببیند، آن را با رزرو متوقفشده مطابقت دهد و لغو را بهصورت آنی (real time) انجام دهد.
نرمافزار را با واقعیتِ ایرلاینها همگام نگه دارید. پلتفرمهای سفر باید از بهروزرسانیهای دستهای (batch updates) و چرخههای کندِ پرسوجو (polling cycles) فاصله بگیرند. اگر یک ایرلاین بلیطی را به عنوان قابللغو، قابلاسترداد یا قابلزمانبندی مجدد علامتگذاری کند، پلتفرم واسط (aggregator) باید ظرف چند دقیقه، و نه چند ساعت، از آن مطلع شود. این امر مستلزم معماری وبهوک (webhook) قدرتمند، منطق تلاش مجدد (retry logic) برای دستدادنهای (handshakes) ناموفق، و فرآیندهای تطبیق (reconciliation jobs) است که ناهماهنگیها را پیش از آنکه کاربر متوجه شود، شناسایی کنند. پلتفرم هرگز نباید آخرین کسی باشد که از وضعیت محصول خودش باخبر میشود.
مسافران در حال حاضر چه کاری میتوانند انجام دهند
تا زمانی که این صنعت این شکافها را برطرف نکند، مسافران باید از خود محافظت کنند. اگر از طریق هر اپلیکیشن شخص ثالثی، از جمله اپلیکیشنهای بزرگی مانند AirAsia MOVE رزرو میکنید، ردپای مستندات را حفظ کنید. از شمارههای تأیید، سیاستهای لغو و هرگونه مکاتبه با ایرلاین اسکرینشات بگیرید. قبل از خرید، از سیاستهای خودِ ایرلاین مطلع شوید؛ برخی از شرکتهای هواپیمایی اجازه میدهند تغییرات مستقیماً از طریق وبسایت خودشان انجام شود، حتی برای بلیطهایی که توسط شرکا فروخته شدهاند. اگر اپلیکیشن کار نکرد، مستقیماً با ایرلاین تماس بگیرید. وقتی پستهای عمومی مورد توجه قرار میگیرند، شرکتها معمولاً سریعتر از کانالهای پشتیبانی خصوصی اقدام میکنند. و اگر مبلغ قابلتوجهی درگیر شده است، در پیگیری از طریق انجمنهای حمایت از مصرفکننده یا مکانیزمهای استرداد وجه (chargeback) تردید نکنید.
نکته اصلی
تجربه مشتری، لایهای از پرداختگی نیست که پس از نوشته شدن کد به آن اضافه کنید. بلکه کد است که وقتی شرایط دشوار میشود، بهدرستی کار میکند. یک پلتفرم رزرو که نمیتواند یک پرواز را لغو کند، مانند خودرویی بدون دنده عقب است. ممکن است بهزیبایی به جلو حرکت کند، اما دیر یا زود نیاز خواهید داشت که از جایی عقبگرد کنید.
مسافران خواهان معجزه نیستند. آنها ابزارهایی میخواهند که دستورات پایه را بدون فریب دادن یا سردرگم کردن آنها (gaslighting) اجرا کنند. ناتوانی AirAsia MOVE در پذیرش لغوی که IndiGo قبلاً تأیید کرده بود، یادآوری این نکته است که راحتی تنها زمانی واقعی است که کل فرآیند بهدرستی کار کند. تا زمانی که پلتفرمهای سفر به اندازه جذب کاربر (acquisition funnels)، روی قابلیت اطمینان پس از خرید سرمایهگذاری نکنند، کاربران همچنان محتاط خواهند بود. و باید هم باشند.