本文へスキップ
ブログ

航空券と一緒にツアーパッケージをオンライン販売する方法

Tekravel 編集部

砂漠サファリも、ダウ船ディナーも、空港送迎も、あなたはすでに売っている。ガイドも車両も自社のもので、火曜朝の市内観光を一本回すのにいくらかかるか、ディルハム単位で把握している。あなたが握っていないのは、お客様をあなたのもとへ運ぶ航空便だ。長いあいだ、それは問題にならなかった。お客様は航空券を別の場所で買い、そのまま現地に現れたからだ。いま問われているのは、自社サイトで航空券と一緒にツアーパッケージをオンライン販売し、ひとつのカートにまとめるかどうか。ドバイ4泊のプログラムを求めていた人が、航空券を探しに出ていき、競合のパッケージを手に戻ってくる事態を避けるためにである。

それは可能だ。ただし、自社の地上商品を他社のリアルタイム在庫の隣に置いた瞬間、利益がどこに乗るのか、価格が動いたときに誰がリスクを負うのかが変わる。ツアーオペレーターがつまずく問題の多くは、この二つを同じ種類のものとして扱うことから生まれる。

ひとつのカートに入る二種類の在庫

地上商品は、あなたが所有しているか契約している在庫だ。サファリの座席をallotmentとして確保しているか、車両の定員までfree-saleで売っている。予約を受け付ける最終時点であるcut-offを決め、ホテルの客室を契約で押さえているなら、売れ残った部屋をホテルに返すrelease periodもある。価格はあなたのものだ。お客様が価格を見た瞬間から支払う瞬間まで、あなたが変えない限り変わらない。

航空券はそのどれにも当てはまらない。航空会社が申請した運賃を、検索の瞬間に仕入れ先が返してくるもので、その座席、その運賃クラス、その一分に対して値付けされている。仕入れ先のホテル料金はその中間にある。固定の契約料金もあれば、航空運賃のように動くリアルタイムの料金もある。

間違いは、両者をひとつの商品にまとめ、固定価格をひとつ付けてしまうことだ。お客様は望みどおり数字をひとつだけ見る。だがその裏で、あなたは予約するまで原価のわからないものに価格を約束している。閑散期の週なら、運賃は予想どおりの位置にある。街で大きなイベントがある週はそうはいかず、その差額はサファリの利益から出ていく。

だから最初の設計判断は、ウェブサイトとはまったく関係がない。この旅のどの部分が「自分で決める価格」で、どの部分が「受け取る価格」なのか、という問いだ。

一部がリアルタイム価格のときのパッケージ価格

構成要素のひとつが動くカートを、誠実に扱う方法は三つある。

航空券込みの固定パッケージ価格地上パッケージは固定、航空券は決済時にリアルタイム価格予約は別々、旅程表はひとつ
運賃の変動を負うのは誰かすべてあなた予約時点のお客様お客様
お客様に見えるもの数字がひとつ地上価格と航空券価格、ページ上で合計される確認書が二、三通
利益の置き場所混ざっていて、航空券の利益だけを切り分けて見られない地上部分へのマークアップと、運賃に乗せるマークアップ予約ごとに別々
取消規定自分で作らなければならない一組のルール各要素が自分の規定を持ち続ける各要素が自分の規定を持ち続ける
向いているケース支払い済みのチャーター便やブロック座席定期便を売る大半のツアーオペレータースタッフが対応する高額または複雑な旅

大半のオペレーターが出発点にすべきなのは真ん中の列で、これは妥協ではない。お客様は相変わらず一回の決済で、合計額をひとつ見る。あなたは相変わらず、自社の写真とプログラムが載ったパッケージページを持つ。変わるのは、航空券の部分がリアルタイムの検索結果から見積もられ、あなたのマークアップがマークアップとして適用されることだ。三週間前には正しかった丸い数字の中に埋もれるのではなく、レポートの上で見える形になる。

左の列は、座席を本当に所有している場合のためのものだ。航空会社にすでに代金を払ったチャーター便やブロックである。そのとき航空券の原価は固定なので、固定のパッケージ価格は誠実だ。定期便の座席を固定パッケージ価格で売るのは運賃への賭けであり、勝ったかどうかは発券の時点でようやくわかる。

真ん中の列について、もうひとつ。地上部分は原価が発生する通貨で値付けし、表示通貨はお客様のものにしておくこと。ガイドにAEDで支払っているドバイのオペレーターが、東京のお客様に円で表示するとき、換算が地上の利益を静かに削っていくのは避けたいはずだ。サイトが複数の通貨を表示するときに利益がどこから漏れるかは、多通貨の予約サイトについての記事で詳しく書いた。

一枚のバウチャーでお客様が見るもの

航空券が仕入れ先から来て、サファリがあなたから来ていることなど、お客様は気にしない。気にするのは、いつどこにいればいいかを教えてくれる書類が一枚あるかどうかだ。その書類を設計するのはあなたであり、ツアーオペレーターがいちばん素人っぽく見えてしまうのがここだ。

よくできた統合旅程表は四つのことをする。

  • すべての要素を、予約した順ではなく、お客様が体験する順に並べる。往路便、送迎、ホテル、各ツアー、復路便。
  • 各要素それぞれの番号を載せる。航空便には航空会社のPNR、ホテルにはホテルの確認番号、地上サービスには自社の予約番号。チェックインカウンターのお客様に必要なのはPNRであって、あなたの社内番号ではない。
  • 何を誰に連絡すべきかを書く。出発当日のスケジュール変更は航空会社へ、現地のことはすべてあなたへ。すべての窓口を一本化したいなら、そう書き、そのための人員を置くこと。
  • 各要素の取消規定を一行で示す。何かが起きてから初めてお客様が読むような、法律文の段落ではなく。

どれも、三つの要素があなたのシステム上でひとつの予約である必要はない。ひとつの旅として提示されていればいい。

別々の予約のままにしておくべきとき

そもそも一緒にしないのが正解のこともある。

お客様が理解できない形で取消規定がぶつかるなら、分けておく。払い戻し不可の運賃と全額返金可能なサファリの組み合わせは問題ない。一方、払い戻し可能な運賃と、キャンプ側にすでに支払った払い戻し不可の五日間砂漠キャンプの組み合わせは、返金トラブルが起きるのを待っているようなものだ。「一部だけ返金可能」なパッケージとして説明するより、二つの購入として説明するほうがずっと簡単である。

一緒にすることであなたの法的な立場が変わる場合も、分けておく。欧州連合をはじめいくつかの市場では、交通と宿泊をひとつの旅として一緒に売ると、パッケージの主催者と見なされ、自分が運営していない部分も含めて全体に消費者保護上の義務を負うことがある。これはパッケージを避ける理由ではない。決済画面を設計する前に、販売先の市場でそれぞれの商品がその線のどちら側にあるのかを知り、推測せずに現地で旅行法を扱う専門家に確認する理由だ。

そして、航空券がそもそも自社の売り物でない場合も、分けておく。お客様の多くが自分で手配して来るオペレーターなら、ツアーやアトラクションを単体で売り、航空券は入口ではなくオプションの追加にしたほうがうまくいくかもしれない。

間違えたときの代償

ここで高くつく失敗が、技術的な理由であることはまれだ。

定期便の運賃の上に組んだ固定価格のパッケージは、市場が不利に動くたびに運賃の差額をあなたに負わせる。しかもパッケージ価格は数字ひとつなので、月次レポートが出るまで気づかないことが多い。取消規定をひとつに混ぜた統合予約は、航空会社がスケジュールを変え、お客様がツアー代金まで返してほしいと言うたびに、揉め事を生む。そして自社の番号しか載っていない旅程表は、朝5時に空港カウンターからかかってくる電話という形で返ってくる。最初から渡しておくべきだった番号を尋ねる電話だ。

レポートに現れないコストは、二度と戻ってこないお客様である。たった一度何かが動いたとき、それが旅のどの部分なのか、誰も教えてくれなかったからだ。

航空券と一緒にツアーパッケージをオンライン販売するのに必要なもの

リストは短い。オペレーターが考えすぎてしまうのが、まさにここだからだ。サイトは、自社のツアーパッケージとアトラクションを自社商品として見せ、その隣に仕入れ先の航空券とホテルを並べ、あなた自身がマークアップを設定し、自社の予約とレポートを確認できる必要がある。このプラットフォームでは、航空券、ホテル、ツアーパッケージ、アトラクションはそれぞれ独立したサービスで、サイトごとにオンにする。サイトには販売しているサービスだけが表示される。だから、まだ航空券を売る準備ができていないオペレーターは、ツアーとアトラクションで立ち上げ、航空券のサービスは後から追加できる。

こうしたプラットフォームと自社システムの開発とで迷っているなら、ホワイトレーベルと予約エンジン自社開発の比較が、この記事で扱わなかった部分をカバーしている。自社の地上商品を載せたサイトがどう見えるのか確かめたいなら、登録ウィザードからひとつ作ってみてほしい。プラットフォームのサブドメイン上にブランドサイトを用意し、カードの登録は求めない。

ソフトウェアは簡単なほうの半分だ。難しいほうの半分は、売っているものひとつひとつについて、それが誰の価格なのかを決めること。そして、ページ上で整って見える数字ひとつではなく、その答えを軸にカートを組み立てることだ。

Tekravel 編集部

旅行テクノロジー担当

Tekravelの旅行テクノロジー担当は、業界の読者に向けて書いています。旅行会社の経営者、ホールセラー、そして両者をつなぐ開発者です。すべての記事は、公開前に記事が扱うプラットフォーム上で確認されます。