公共交通機関
シートが予約制になっているケースで、仮に満席御礼の状態となっているとします。このとき、果たしてすべてのお客様は、自ら確保したシートにご満足されているでしょうか。
もし満足できていないお客様が、仮のシートを確保されているのであれば、そこにマッチング・アルゴリズムを適用して、より満足度を高めるための潜在的市場が見出せる可能性があります。
このような構造は、最低限の要望を満たされている状態に対して、さらに＋アルファの要望を満たすことにより、全体の満足度をより高められるという二段階の階層として表現することができます。
仮に、＋アルファの要望が、こだわりなし／通路際／連席という3つのカテゴリーに分類されるとき、理想的にはそれらの＋アルファが満たされていることが望ましいと言えます。
しかしながら、現実には一部のお客様の＋アルファ要望のみが満たされていることが多いのではないでしょうか。
ここで、より具体的な事例を考えてみます。あるお客様は、一般的な予約システムを利用して、窓際の席を希望しながら、12月8日にシートの予約を試みました。ところが、その日の段階で窓際の席はすべて予約済みとなっていたため、仕方なく通路際の「C 23」というシートを確保したとします。これにより最低限の要望は満たされました。
そして、20日後の12月28日に、不本意ながらも確保済みの「C 23」を利用する形になります。
ここで、一般的な予約システムに、「最適化オプション」という新しい機能を追加したとします。この機能は、最低限の要望を満たすために確保したシートを、さらにアップグレードして、よりよいシートに変更することをシステムに伝えるためのオプション機能として位置付けられます。
このオプションが選択されているとき、システムが行うのは、予約日から利用日までの期間に、お客様との直接対話的な調整を図るのではなく、確保済みのシートのうち、「最適化オプション」が選択されているシート間で調整を図ります。
このとき、各お客様がどのようなアップグレードを希望されるかについても、併せて伝えるものとします。むろん、過去の履歴情報を参照できるようにして、いつも窓際を希望しているお客様は、反対にいつもと違う要望がある場合のみ、具体的な要望を伝えるような仕様にすることもできます。
ここで、通路側のシート「C 23」を確保済みのお客様は、窓際のいずれかのシートであればアップグレードしたと考え、＋アルファの要望を満たせると考えることができます。
そこで、最適化オプション機能を持つ予約システムは、予約日から実際の利用日までの期間に、窓際のいずれかのシートに現在のシートから「C 23」に交換することを厭わない（無差別）、もしくはそのような交換を希望するオプションが含まれているものを探索します。
そして、そのような希望が何らかの循環型サイクルとして、うまく形成されればマッチングが成立し、シートの交換が実現されます。この事例では、最適化のプロセスを経て、シートを通路側の「C 23」から窓際の「A 23」にアップグレードできたことを示しています。
このような最適化プロセスには、一般的なレコメンデーション・エンジンを併用することも可能です。ここでは、最適化オプションを利用する際に、併せてアップグレードとしての希望を伝える、という仕様を前提に説明させて頂きました。