LINEに頼らずサブエージェントへネット運賃を配布する方法

月曜の朝、運賃表が配られます。PDFか、スプレッドシートのスクリーンショットが、数十社のサブエージェントが参加するLINEグループに投げ込まれます。月曜の午後には、そのうち二つの運賃がすでに航空会社側で変わり、あるエージェントは「価格を見てもらうため」に運賃表を法人顧客へ転送し、福岡の誰かがホノルル行きの運賃に二個目の受託手荷物がまだ含まれているかを尋ねています。多くのコンソリデーターがいまもこうしてサブエージェントにネット運賃を配っており、それは稼ぎより損失が大きくなるその週までは、うまく回っています。
この記事は、その配布をメッセージから外し、自社のルールを確実に適用するシステムへ移す話です。誰がどの運賃を、いくらで、どれだけの与信枠の中で見られるのか。ソフトウェアが流行っているからではありません。以下の三つの失敗は、どれもサブエージェントではなく、あなたのBSP精算書に跳ね返ってくるからです。
運賃がメッセージで流れると起きる三つのこと
どれも、起きた当日には大した問題に見えません。そこが問題なのです。
運賃はもう古い
ネット運賃は、動き続ける座席在庫のある瞬間を切り取った写真です。画像としてシステムを離れた瞬間、更新は止まります。サブエージェントが火曜に家族客へ見積もりを出し、家族は水曜に支払い、その運賃の前提だった予約クラスは月曜の夜に閉まっていた。こうなると、運賃を出し直してエージェントの信頼を失うか、そのまま守って差額を自社でかぶるかのどちらかです。エージェントは、どのコンソリデーターが古い運賃表を守ってくれるかをすぐに覚え、いちばん厄介な予約をそこへ回します。
ネット価格が漏れる
運賃表は、誰が読んでいるかを知りません。一度転送されれば、エージェントがいくら払っているかを正確に知った一般顧客に届き、二度転送されれば、あなたがいくら払っているかを正確に知った競合コンソリデーターに届きます。どちらも取り消せません。その顧客に対するエージェントの利幅は崩れ、次の航空会社との交渉でのあなたの立場は以前より弱くなります。
監査の記録が残らない
運賃規則違反でADMが届いたとき、最初に問われるのは、誰が、どの条件で、何時に、何を売ったかです。その答えが三人のスタッフの携帯に散らばったトーク履歴の中にあるなら、期限が迫るなかでスクリーンショットをつなぎ合わせて再構成するしかありません。エージェントが請求書に異議を唱えたときも同じです。あなたの言い分、相手の言い分、そしてボイスメッセージがひとつ。
これらを合計すると、ここで失敗したときのコストはソフトウェア予算の一行ではありません。誰がどの規則で発券したかを証明できず差し戻せないADM、良いエージェントを引き留めるためにかぶる古い運賃の差額、そしてネット価格が出回っているせいで自ら弱めてしまう航空会社との交渉です。
サブエージェントへのネット運賃配布は、メッセージではなくルールで
代わりの仕組みは地味なものです。サブエージェントがそれぞれログインし、リアルタイムで検索し、あなたが見せると決めた価格を見るポータルです。運賃が文書になることはないので、古くなることも転送されることもありません。運賃は検索のたびに、あなたのマークアップとルールのもとで計算し直される結果です。
このプラットフォームでは、コンソリデーター用のページからコンソリデーターのアカウントを開設でき、その一つのアカウントで、コンソリデーターとして動きながら、自社のサプライヤーコンテンツをネットワークと共有し、自社ブランドを持ちたい旅行会社にwhite-labelサイトを販売できます。サブエージェントは法人顧客として登録され、必要なら手動での審査を挟めます。ストアフロントは検索前のログインを必須にできるため、承認していない相手に運賃が表示されることはありません。このポータルが一般向けサイトとどう並立するかをより広く知りたい方は、サブエージェント向けB2B旅行ポータルについての別記事をご覧ください。
エージェントごとの表示範囲と価格
すべてのエージェントがすべてを見る必要はありません。取引開始一か月目の新規エージェントに、最も条件の良いホテル契約料金は要りません。名古屋の大口エージェントが、二週間に一枚しか発券しない相手と同じマークアップを払うのも、おそらく筋が違います。ポータルがLINEより優れているといえるのは、こうした違いを均してしまわずにルールとして書き込めるときだけです。
ここでの表示範囲は、一対一の取り決めではなくサプライヤーグループで決まります。tenantは自分のグループに付与されたサプライヤーだけを見られ、それ以外は見えません。これが「誰が何を見るか」を決めるレバーです。価格はもう一つのレバーで、コンソリデーターが最も時間をかけて考えるべきところです。エージェントに説明しやすいマークアップの論理こそ、エージェントがあなたを他社と比べたときに生き残るからです。詳しくはマークアップ戦略の記事にあり、要点はこの表のとおりです。
| 問い | チャットグループの運賃表 | 自社ルールで動くポータル |
|---|---|---|
| 誰が運賃を見られるか | 運賃表が届いた人なら誰でも | 承認済みでログインしたエージェントだけ |
| 価格はどれだけ新しいか | 運賃表を作った時点のもの | 検索した時点のもの |
| エージェントごとに違う条件 | 別々の運賃表を手作業で管理 | 一度設定すれば検索ごとに適用 |
| 何を誰に売ったかの証拠 | トーク履歴 | エージェントごとの予約記録 |
| 新しいエージェントの追加 | グループのメンバーが一人増える | 自分で管理する承認手続き |
| 静かな日曜日の見積もり | 誰かが返事をすれば速い | 誰が返事をしてもしなくても速い |
| 複雑な周遊旅程 | 人が考えて組む | 多くの場合いまもその人が必要 |
最後の行は議論になりがちで、それももっともです。込み入ったルートを人に考えてほしいエージェントにとっては、よく回っているLINEの窓口がどんなポータルにも勝ります。そうした案件のために窓口は残しましょう。成田–ソウルのような日常的な発券は、そこから外してください。
与信管理は配布の一部であり、その後始末ではない
多くのコンソリデーターは与信を経理の問題として扱います。エージェントが予約し、請求書が出て、月末に誰かが督促する。この順番は逆さまです。エージェントに掛けでの発券を許す一枚一枚が小さな貸し付けであり、貸すかどうかの判断は、経理がスプレッドシートを開くときではなく、発券するその瞬間に下されています。
だから与信枠は、予約が起きる場所に置かなければなりません。このプラットフォームでは、サブエージェントの与信枠と精算請求はスプレッドシートではなくシステムの正式な機能です。枠はエージェントに紐づき、精算はエージェントが予約したのと同じシステムの中にあります。配布と与信が一つのシステムを共有していれば、「このエージェントはいまこの航空券を発券してよいか」という問いには、航空券が生まれる前に答えが出ます。発券後の電話一本ではなく。
エージェントとの会話も変わります。「与信枠に達しました。未払いの請求を精算すれば再び発券できます」は、相手にも見えるルールです。「経理がだめだと言っています」は、わだかまりになります。
手放してはいけないもの
ポータルに移ることは、商売上の判断をベンダーに預けることであってはなりません。何かに申し込む前に、もちろんこのプラットフォームも含めて、次のものがまだ自分の手にあるかを確かめてください。
- どのエージェントが存在するか。 初回の検索前に一社ずつ手動で審査するかどうかは、あなたが決めます。
- 各グループに何が見えるか。 サプライヤーとコンテンツはグループ単位で付与され、全員に一斉に開放されるわけではありません。
- あなたのマークアップ。 自社の管理画面で、予約・顧客・レポートと並べて、あなた自身が設定します。
- スタッフの誰がそれを変えられるか。 ロールに基づく権限なので、発券担当者が自動的にマークアップを編集できる人にはなりません。
- 与信。 エージェントごとの枠と、スプレッドシートに頼らない精算請求。
- 関係そのもの。 エージェントがいずれ自社ブランドのサイトを欲しがったら、それはあなたが売る商品であるべきで、あなたから離れる理由であってはいけません。
最後の点は見落とされがちです。チャットグループを最も早く卒業するのは最も優秀なエージェントで、彼らは一般向けサイトが欲しくなった瞬間にさまざまなプラットフォームと話し始めます。彼らのブランドで、あなたのコンテンツの上に、あなたが用意してあげられるなら、彼らはあなたのネットワークにとどまります。
どこから始めるか
一週間で全エージェントを移そうとしないでください。予約の多い数社を選んでポータルで承認し、しばらくはLINEグループと並行して運用します。彼らがまだグループで何を尋ねているかを観察してください。その一覧こそ、あなたのルールがまだカバーしていない部分です。ビジネスモデルそのものをまだ検討中なら、航空券コンソリデーターになる方法がこの一歩手前を扱っています。そこを越えているなら、コンソリデーターアカウントがポータルの出発点です。