仲介者が壁となる時
ある旅行者が最近、AirAsia MOVEプラットフォームを通じてIndiGoのフライトを予約しました。予定が変更になったため、彼は旅行のキャンセルを依頼しました。航空会社は同意しました。本来なら、それで話は終わるはずでした。しかし、プラットフォーム自体がキャンセルの処理を拒否し、乗客は2つの会社の間で板挟みになり、途方に暮れることになりました。彼はその不満を公に表明し、システムは役に立たず、愚かだと批判しました。彼の怒りは剥き出しでしたが、それは、生活を簡素化するためにアグリゲーターに頼っている何百万人もの旅行者に影響を与える問題を指摘していました。
この出来事は、オンライン旅行という巨大な仕組みの中では小さな出来事に過ぎませんが、大きな警告を含んでいます。私たちは、航空会社のウェブサイト、決済ゲートウェイ、確認コードなどを使い分ける手間を避けるために、これらのアプリをダウンロードします。私たちは、仲介者が物事を円滑に進めてくれることを期待しており、停滞させることを望んでいるわけではありません。航空会社がすでに承認したキャンセルをプラットフォームが実行できない場合、そのプラットフォームは唯一の本来の役割、つまりユーザーからサービスプロバイダーへ、そしてその逆へと情報を忠実に伝えるという役割を果たせていないことになります。
何が壊れていたのか
この事例の詳細は単純明快であり、それこそが懸念すべき点です。乗客は隠れた手数料について争ったり、ポリシーの抜け穴について戦ったりしたわけではありません。彼はフライトのキャンセルという標準的な操作を行っただけで、存在するはずのないエラーに直面したのです。IndiGoはキャンセルを受け入れましたが、AirAsia MOVEは受け入れませんでした。その結果、典型的な双方に不利益な状況が生まれました。旅行者は時間と心の平穏を失い、プラットフォームは信頼を失いました。
この種の失敗は、通常、旅行者が目にすることのない、システムの深部の仕組みの中で発生します。オンライン旅行代理店やスーパーアプリは、自社のサーバーに航空会社の在庫を保持しているわけではありません。データを受け渡すAPIを通じて航空会社に接続しています。「キャンセル」をタップすると、リクエストはスマートフォンからアグリゲーターのバックエンドへ送られ、そこから航空会社の予約システムへと渡されます。航空会社は予約ステータスを更新し、確認通知を送ります。アグリゲーターは、その変更を即座に反映し、返金やトラベルクレジットの処理を行うはずです。
その連鎖のどこかで、AirAsia MOVEが停止してしまいました。おそらく、APIがIndiGoのシステムから更新されたステータスを取得できなかったのかもしれません。あるいは、アプリの内部ロジックに、航空会社の応答を上書きしてしまうハードコードされたルールが含まれていたのかもしれません。あるいは、カスタマーサービスの担当者は画面上で不一致を確認できたものの、キャンセルを強制的に実行する権限がなかったのかもしれません。正確なバグの内容は分かりませんが、結果は明らかです。一人の人間がソフトウェアのループの中に閉じ込められ、全当事者が取り消すべきだと合意した取引を、取り消すことができなくなったのです。
なぜ信頼はコードの修正よりも早く損なわれるのか
旅行者は、使いにくいインターフェースには耐えられます。読み込みが遅いことにも耐えられます。しかし、お金や予定がかかっている時に、どうすることもできない無力感には耐えられません。キャンセルは軽微な要求ではありません。それは通常、病気、家族の緊急事態、突然の仕事の都合といった、危機的な状況に続いて行われるものです。ユーザーはすでにストレスを感じています。アプリの役割は、バックエンドの複雑さを処理することで、そのストレスを軽減することです。それどころか、アプリが新たな障害となる場合、その感情的なコストは計り知れません。
だからこそ、乗客の公の場での爆発が重要なのです。彼は、失われたロイヤリティポイントや遅れたプッシュ通知について不満を言ったのではありません。最も必要としていた瞬間に、プラットフォームが正当な要求を積極的にブロックしたため、プラットフォームを「役に立たない」と表現したのです。デジタルサービスへの信頼は、状況が変わってもシステムがユーザーの意図を尊重してくれるという信念の上に成り立っています。その約束が一度でも破られれば、10回のスムーズな予約では修復できないほどのダメージを与えます。
この問題はまた、多くの旅行プラットフォームが構築される際の戦略的な盲点も露呈させています。エンジニアリングチームは、迅速な検索、美しいカレンダー、ワンタップ決済、パーソナライズされた特典といった、ダウンロードを促進するフロントエンドの機能にリソースを投入しがちです。一方、予約後の操作（変更、キャンセル、返金）は、後回しにされがちです。それらには古いAPI、不十分なモニタリング、そして少ないフォールバックオプションしか用意されません。しかし、アプリが真のツールなのか、それとも単なる「光り輝くパンフレット」に過ぎないのかをユーザーが判断するのは、まさにその部分なのです。
旅行プラットフォームが正しく行うべきこと
顧客と航空会社の間に入るあらゆる企業にとって、ここには明確な教訓があります。
キャンセルを予約と同じくらい簡単にしましょう。 ユーザーが3タップで座席を予約できるのであれば、チャットボットの迷路や隠れたメニュー、サポート外のフォームを辿ることなく、その予約を取り消せるべきです。キャンセルフローは可視化され、手数料についても正直であり、利用できない予約を維持させるよう罪悪感を植え付けたり混乱させたりする「ダークパターン」は排除されるべきです。
実際に機能する手動オーバーライドを構築しましょう。 自動化は、それが失敗するまでは素晴らしいものです。APIの返り値の競合や同期エラーが発生した際、カスタマーサービスのエージェントには、介入するための権限とインターフェースが備わっていなければなりません。あまりにも多くのプラットフォームが、人間の介入を許さない「完全自動化された要塞」を設計してしまっています。その結果、エージェントは台本を読み上げ、謝罪を繰り返し、ブラックホールにチケットを投げ込むような作業を強いられます。有用なオーバーライドとは、エージェントが航空会社の承認を確認し、それを滞っている予約と照合して、リアルタイムでキャンセルを処理できることを意味します。
ソフトウェアを航空会社の現状と同期させ続けましょう。 旅行プラットフォームは、バッチ更新や低速なポーリングサイクルから脱却する必要があります。航空会社がチケットを「キャンセル可能」「払い戻し可能」「スケジュール変更済み」とマークした場合、アグリゲーターは数時間ではなく、数分以内にそれを知るべきです。そのためには、堅牢なWebhookアーキテクチャ、ハンドシェイク失敗時のリトライロジック、そしてユーザーが気づく前に不一致をフラグ立てする照合ジョブ（reconciliation jobs）が必要です。プラットフォームが、自社製品のステータスを知るのが最後になってはなりません。
旅行者が今できること
業界がこれらのギャップを解消するまで、乗客は自らを守る必要があります。AirAsia MOVEのような主要なものを含む、いかなるサードパーティ製アプリを通じて予約する場合でも、証拠（paper trail）を残しておきましょう。予約番号、キャンセルポリシー、航空会社からの連絡内容はすべてスクリーンショットを撮っておいてください。購入前に航空会社独自のポリシーを確認してください。パートナー経由で販売されたチケットであっても、航空会社のウェブサイトから直接変更できる場合があります。アプリが機能しない場合は、航空会社に直接連絡してください。公開の場での投稿が注目を集めると、企業はプライベートなサポートチャネルよりも迅速に動く傾向があります。また、多額の資金が滞っている場合は、消費者保護フォーラムやチャージバックの手続きを通じて、躊躇なくエスカレーションしてください。
真の教訓
カスタマーエクスペリエンスとは、コードを書いた後に適用する「仕上げの層」ではありません。それは、状況が悪化したときにコードが正しく機能することです。フライトをキャンセルできない予約プラットフォームは、バックギアのない車のようなものです。前進は美しくできるかもしれませんが、遅かれ早かれ、バックして出る必要がある場面が訪れます。
旅行者は魔法を求めているのではありません。彼らが求めているのは、ガスライティング（心理的な操作）をすることなく、基本的なコマンドを実行できるツールです。IndiGoがすでに承認したキャンセルをAirAsia MOVEが尊重できなかったことは、パイプライン全体が機能して初めて「利便性」が本物になるということを思い出させます。旅行プラットフォームが、顧客獲得ファネル（acquisition funnels）と同じくらい、購入後の信頼性に投資しない限り、ユーザーは警戒を解かないでしょう。そして、そうすべきなのです。