お客様の導入事例
Travel Horizontal：顧客とパートナーのための一つのマーケットプレイス業務フロー
旅行者と取引パートナーの両方に販売するグローバル旅行マーケットプレイスが運用を再構築し、二つのチャネルが同じフローに沿い、より少ない管理拠点から運用され、エスカレーションも減るようにしました。
- グローバル
- B2B + B2C
- マーケットプレイス運用の刷新
- 2024 年に公開
マーケットプレイス
Travel Horizontal 導入事例の概要
Travel Horizontal は、二種類の購入者を持つグローバル旅行マーケットプレイスを運営しています。自分のために予約する旅行者と、自社の顧客に代わって予約する取引パートナーです。両チャネルは同じ旅行商品を販売していますが、時間とともに各予約の裏側の処理方法が分かれていきました。
このプロジェクトはマーケットプレイス運用の刷新でした。目的は新しい店頭ではなく、その下にあるより整理されたプラットフォームのフローです。顧客とパートナーの予約を一つの方法で扱い、管理する場所を減らし、毎日発生するケースに標準手順を用意すること。
PHPTRAVELS 上に構築されており、オンライン旅行会社 と B2B旅行ポータル のページを支えるものと同じ予約エンジンです。
- 業種
- 旅行マーケットプレイス
- 地域
- グローバル
- モデル
- B2B + B2C
- 範囲
- マーケットプレイス運用の刷新
- 公開
- 2024
一つのマーケットプレイス業務フロー
- 検索
- 予約
- 管理
- サポート
課題から成果へ
マーケットプレイスが挙げた三つの課題と、その変化
それぞれの流れは Travel Horizontal が説明した課題から始まり、同社が自らの言葉で報告した成果で終わります。
ジャーニーの一貫性
課題
チャネル間の不一致顧客とパートナーのジャーニーが運用上ばらばらに扱われていました。成果
揃ったチャネルフロー顧客とパートナーの予約が同じフローを通るようになり、チームは同じ方法で対応しています。運用管理
課題
分散した管理ポイントチームはつながりのない多すぎる管理画面をまたいで作業していました。成果
すっきりした管理日々の管理が別々の画面に散らばらず、つながった少数の場所にまとまりました。サポート効率
課題
エスカレーションの多い業務手順が標準化されていなかったため、よくあるケースもエスカレーションされていました。成果
エスカレーションの減少標準手順により、よくあるケースを最初に受けた人がその場で解決できます。
成果は Travel Horizontal の報告によるものです。このプロジェクトの数値は公表されていません。
チャネルの同等性
顧客とパートナーのジャーニーを同じレールに
チャネルを揃えることは、同一にすることではありません。手順とルールは共通にし、各チャネルは本当に必要なものを残します。たとえば、パートナーが自分の エージェントウォレット から支払う仕組みです。表示を切り替えて比較してください。
表示する立場
- 検索両チャネル共通同じ在庫と同じ検索フロー。B2CB2Bマーケットプレイスのサイトに公開価格。パートナーのログイン後にパートナー価格を表示。
- 予約両チャネル共通すべての販売で一つの予約レコード形式。B2CB2B旅行者が自分のために予約。パートナーが顧客に代わって予約。
- 支払い両チャネル共通すべての予約に一つの支払いステータス。B2CB2B旅行者はチェックアウト時にオンラインで支払い。パートナーはアカウント残高から支払い可能。
- 管理両チャネル共通同じステータスと同じ変更手順。B2CB2B旅行者は自分のアカウントで予約を確認。パートナーはダッシュボードで全予約を確認。
- サポート両チャネル共通よくある依頼には一つの標準手順。B2CB2B依頼は旅行者から直接届く。依頼はパートナーから届き、そのアカウントに紐づく。
PHPTRAVELS が共通手順とチャネル固有の手順を分ける方法の例であり、Travel Horizontal の設定ではありません。
一つの管理画面
分散した拠点から一つのマーケットプレイス管理コンソールへ
分散した管理ポイントが二つ目の課題でした。顧客の予約、パートナーの依頼、支払い、サポートがそれぞれ別の場所にあると、日々の作業はまず正しい画面を探すことから始まります。
以前：別々の場所
- 顧客の予約
- パートナーの依頼
- 支払い確認
- サポート受信箱
現在：一つのコンソール
- 顧客とパートナーの予約を一つのリストに表示し、チャネルタグで区別。
- パートナー、顧客、サプライヤー、支払いを同じ管理画面で管理。
- 予約ごとにステータスは一つなので、別の画面を確認する必要がありません。
顧客とパートナーの記録は、その後 旅行業向けCRM でのフォローアップに活用できます。
- 予約
- 顧客
- パートナー
- サプライヤー
- 支払い
- 設定
予約
| 番号 | チャネル | 商品 | ステータス |
|---|---|---|---|
| #2041 | B2C | 航空券 | 確定 |
| #2042 | B2B | ホテル | 保留中 |
| #2043 | B2B | ツアー | 確定 |
| #2044 | B2C | ホテル | 変更済み |
サンプル予約を使った説明用の管理画面であり、Travel Horizontal の管理画面のスクリーンショットではありません。
エスカレーションの減少
よくあるケースは最初の段で解決
エスカレーションの多い業務が三つ目の課題でした。日々の依頼を扱う標準の方法があれば、本当に珍しいケースだけが上に上がります。ケースを選んで、どこで対応されるかを確認してください。
ケースを選択
刷新前は、標準手順がなかったため、こうしたよくあるケースの多くが上の段へ上がっていました。
- プラットフォームチームマーケットプレイスの仕組みそのものの変更ここで対応
- 運用責任者判断が必要な例外ここで対応
- 一次対応日常のケースを標準手順で対応ここで対応
Travel Horizontal が説明した原則の例であり、実際のサポート体制ではありません。
お客様の声
プラットフォームチームの声
チャネルをまたぐフローが管理しやすくなり、日々の運用もより予測しやすくなりました。
どのチャネルから来ても一つの予約レコード
プロジェクトは PHP、MySQL、JavaScript と REST API で動いており、パートナーの予約と顧客の予約が同じ構造を共有します。システム連携については 旅行API連携 のページをご覧ください。
GET /api/bookings/2042
{
"channel": "b2b",
"product": "hotel",
"status": "pending",
"payment": "unpaid"
}説明用のリクエストとレスポンスであり、Travel Horizontal の実際の API ではありません。
技術スタック
PHPMySQLJavaScriptREST API
マーケットプレイス運用を磨き上げる
B2B と B2C の業務フローを一つの一貫したシステムに統合します。PHPTRAVELS はセルフホスト型で、商用ライセンスのもとソースコードが付属します。
関連ソリューション
旅行者と取引パートナーの両方に販売するグローバル旅行マーケットプレイスの Travel Horizontal が、PHPTRAVELS 上で運用を刷新し、チャネルを揃え、管理を集約し、エスカレーションを減らした経緯を紹介しています。
マーケットプレイスは旅行者に直接販売し（B2C）、自社の顧客のために予約する取引パートナーを通じても販売します（B2B）。刷新により、両チャネルはそれぞれ固有の部分を残しつつ同じフローに乗りました。
揃ったチャネルフロー、すっきりした管理、エスカレーションの減少です。マーケットプレイスは自らの言葉でこれらの成果を説明しており、数値は公表されていません。
プロジェクトは 2024 年に公開されました。
PHP、MySQL、JavaScript、REST API です。PHPTRAVELS はセルフホスト型で、商用ライセンスのもとソースコードが含まれます。
できます。デモを予約して現在の顧客チャネルとパートナーチャネルの運用を確認し、料金ページで買い切りプランを比較してください：Startup $2499、Agency $4999、Enterprise $9999。