Bristol Adventureは、孤立した部屋の宿泊ではなく、完全な冒険旅行を販売しています。1回の予約で、固定された宿泊期間、複数の旅行者、キャビン、フライト、アクティビティ、オプション、共有または個別の支払いを組み合わせることができます。
標準的な予約設定では不十分でした。予約システムは、Bristol Adventureが実際に旅行を構築し販売する方法に従う必要がありました。
課題: 冒険パッケージは部屋の予約以上のもの
Bristol Adventureはキャビンや部屋を通じて宿泊を管理していますが、宿泊は製品の一部に過ぎません。
多くの旅行は固定された宿泊期間に従います。ゲストは、独自の時間とキャパシティを持つフライトやアクティビティも必要とするかもしれません。家族や大きなグループは、1つの全体の冒険パッケージに属しながら、複数の部屋を必要とする場合があります。
- 固定の3、4、7泊の宿泊
- キャビンと部屋の在庫
- 複数部屋のグループ予約
- 出発時間のあるフライト
- フライトの座席キャパシティ
- アクティビティとオプション
- 共有旅行請求書
- Salesforce顧客記録
Bristol Adventureに基づいた3つのワークフロー
最も重要な作業は、基本的な部屋予約モデルに合わない運営の3つの部分に焦点を当てました。
| Bristol Adventureのニーズ | Booking Ninjasの設定 | なぜ重要か |
|---|---|---|
| 固定期間の予約 | 予約ルールは、Bristol Adventureの固定の3、4、7泊パッケージの長さに基づいて設定されました。 | 予約フローは、Bristol Adventureが実際に販売する製品に従うことができ、制限のない夜間ホテルカレンダーのように振る舞うことはありません。 |
| POSを通じたフライト | フライトは、出発時間、座席在庫、ゲストの予約へのリンクを持つ時間ベースのPOS製品として構成されました。 | フライトは、旅行の中で管理された在庫となり、切り離された手動のオプションではなくなります。 |
| グループラグジュアリー冒険パッケージ | グループ予約を使用して、複数の部屋、旅行者、フライト、オプションを1つの全体の旅行構造の下に保ちました。 | 家族やグループは、無関係な予約の集まりではなく、1つの冒険として管理できます。 |
定義された宿泊期間の旅行のための固定期間の予約
Bristol Adventureのほとんどの宿泊は、無期限のホテル予約ではありません。製品自体には定義された長さがあります。
典型的なパッケージオプションには、3泊、4泊、7泊の宿泊が含まれます。Booking Ninjasは、これらの宿泊ルールが予約プロセスに反映されるように設定されました。
これは、可用性と予約ルールが、会社が実際に提供できるものと一致する必要があるため重要です。ゲストは、カレンダーに部屋が空いているからといって、意図された冒険パッケージの範囲外の組み合わせを作成できるべきではありません。
フライトはPOSを通じて時間ベースの在庫となった
フライトは、通常の予約オプションよりも複雑でした。
各フライトには出発時間と限られた座席数があります。Bristol Adventureは、運用キャパシティが変化したときに反応する能力も必要です。たとえば、2機の航空機が18席を提供し、1機が利用できなくなった場合、その日の販売可能なキャパシティが減少する必要があります。
Booking Ninjasは、POS構造を使用して、フライトを独自の在庫を持つ時間ベースの製品として扱いました。
フライトは時間ベースのサービスとして作成されます。
利用可能な出発時間が割り当てられます。
在庫は販売可能なキャパシティを表します。
フライトは旅行者の宿泊に関連付けることができます。
注文は旅行の請求記録に接続されたままです。
同じPOS構造は、旅行者が宿泊を必要としない場合の単独のフライト販売もサポートできます。
キャパシティベースの予約については、可用性の管理方法をご覧ください。
グループラグジュアリー冒険パッケージは一緒に滞在
家族やグループ旅行は、各部屋が無関係な予約として扱われると、迅速に管理が難しくなる可能性があります。
Bristol Adventureには、複数の人の旅行を整理するホストがいる場合があります。グループは、1つの冒険でありながら、複数の部屋やキャビン、フライト、その他のオプションを必要とするかもしれません。
Booking Ninjasは、複数の宿泊施設がグループの下に配置できるように、グループ予約構造を有効にしました。これにより、チームは部屋ごとに旅行を再構築する必要がなくなります。
旅行が接続ポイントになる
これらの要素が接続されると、Bristol Adventureは宿泊、フライト、グループを別々のシステムとして考える必要がなくなります。
運営フローは理解しやすくなります:
顧客はSalesforceの記録に接続されたままです。
正しい固定期間の宿泊が選択されます。
キャビンや部屋が旅行に割り当てられます。
キャパシティベースのサービスが宿泊の周りに追加できます。
接続された活動はSalesforce内で利用可能なままです。
結果は単なるより良いカレンダーではありません。それは、Bristol Adventureが販売する完全な製品を表すことができる予約構造です。
Bristol AdventureのSalesforce環境に基づいて構築
Bristol AdventureはすでにSalesforce Sales Cloudを導入していました。Booking Ninjasは、その同じSalesforce基盤で機能するように設計されました。
これにより、予約はSalesforceのアカウントや連絡先に接続されたままとなり、スタッフが同期を維持する必要のある別の顧客データベースを作成する必要がなくなります。
また、Bristol Adventureは、独自の用語、記録、ワークフロー、報告、および将来の要件に基づいて組織を形成し続ける余地を持ちます。
詳細は、Salesforce Orgとは何かをご覧ください。
旅行の支払い側をサポート
Bristol Adventureは、請求書の発行から7日以内に50%が支払われ、旅行の90日前に残りの50%が支払われる支払いスケジュールについても議論しました。90日以内に行われた予約は全額支払いが必要です。
チームは、どの顧客が期限を過ぎているかを手動で確認していました。
Booking Ninjasのウォークスルー中に、請求書、支払い記録、ファイルに保存されたカード、Stripeの支払い処理、および予約ワークフローに関連する支払いの自動化がデモされました。
これにより、同じ旅行構造が請求と支払いのフォローアップをサポートする道を持ち、予約自体から財務面を切り離すことなく行えます。
予約が請求書にどのように接続されるかについては、ご覧ください。
Bristol Adventureの設定で何が変わったか
固定期間の宿泊は、Bristol Adventureが実際に販売するパッケージの長さに従うことができます。
出発時間と座席キャパシティは、予約操作の一部として処理できます。
複数の部屋、旅行者、フライト、オプションは、1つの大きな冒険の一部として残ることができます。
宿泊とサービスは、スタッフが手動で再接続する必要のある別々の予約トレイルを作成する必要がありません。
顧客と予約活動は、Bristol Adventureがすでに使用しているSalesforce環境に接続されたままです。
設定は、Bristol Adventureの運営モデルに従うことができ、ビジネスを標準的なホテルのワークフローに強制する必要がありません。
関連する読み物
複数の予約と旅行者が、より大きな予約の一部としてどのように処理されるかをご覧ください。
グループ予約を探る →日付、キャパシティ、在庫、予約制限がどのように連携しているかをご覧ください。
可用性の管理方法 →運営環境が、1つの組織の独自の記録とワークフローに基づいて形成される理由をご覧ください。
Salesforce Orgとは何か →予約活動が請求書や支払いにどのように接続されるかをご覧ください。
予約が請求書に接続される方法 →あなたの予約は標準モデルに合わせる必要はありません
Booking Ninjasが、予約、パッケージ、キャパシティベースのサービス、支払い、グループワークフローを、あなたの運営が実際に機能する方法に基づいて形成できる方法をご覧ください。
.jpeg)
.jpg)
.png)
