Movara Fitness Resortは単なる宿泊料金を販売しているわけではありませんでした。ゲストは、宿泊、食事、運動、プログラム、サービス、支払いがすべて連携した構造化されたウェルネス滞在を求めて訪れました。
Movara Fitness Resort は、ユタ州アイビンズに位置し、宿泊と構造化されたフィットネスおよびウェルネス体験を組み合わせており、短期の訪問から数週間にわたるプログラムまで対応しています。
Booking Ninjasは、Movaraと協力して、実際に販売され運営されている方法に基づいたSalesforceネイティブのリゾート環境を構成しました。
課題：1つの部屋が複数の在庫を表す可能性
Movaraの宿泊モデルは、通常の1部屋1予約の設定では不十分である理由をすぐに示しました。
同じ物理的な部屋は、1人のゲストにプライベートで販売されることもあれば、複数のプログラム参加者で共有されることもあります。
内部的には、101号室のような部屋は、101Aや101Bなどの関連在庫を持つことができます。
メインの部屋がプライベートで予約されている場合、両方の共有ポジションは利用不可にする必要があります。1つの共有ポジションが予約された場合、システムは同じ部屋をプライベート在庫として再度販売できないようにする必要があります。
- キングプライベート
- キングダブル
- クイーンプライベート
- クイーンドブル
- ヴィラプライベート
- ヴィラダブル
- ヴィラトリプル
- 親子接続在庫
Booking NinjasはMovaraの実際のルールに基づいて在庫を構成しました
Booking Ninjasは、プライベートおよび共有在庫が自動的に相互に影響を与えるように、親子の可用性動作についてMovaraと協力しました。
これは、ビジネスが実際にリソースを販売する方法から始め、その論理に基づいてシステムを構成するという広範な実装アプローチの良い例です。
Booking Ninjasの現在の 予約管理 および予約プラットフォームは、予約を在庫、可用性、キャパシティ、価格設定、運用ルールと直接接続する同じ広範なモデルを使用しています。
製品は単なる部屋ではなくウェルネスパッケージでした
宿泊は、ゲストが購入しているものの一部に過ぎませんでした。
滞在は、宿泊、食事、運動アクセス、フィットネスプログラミング、その他のウェルネスコンポーネントを組み合わせることができます。
これらのコンポーネントは異なる税処理を受ける可能性があり、最終的な価格は占有率、滞在期間、季節、ロイヤルティステータス、プロモーションルールによっても異なる場合があります。
長期の予約は、同じ滞在中に異なる料金期間を跨ぐことさえあります。
プライベートまたは共有の宿泊がパッケージと在庫要件の一部を確立します。
食事、運動、ウェルネスプログラミングがゲストが購入しているものの一部を形成します。
長さ、占有率、日付、ロイヤルティ、プロモーションが滞在の価格に影響を与える可能性があります。
デポジット、残高、請求書、支払い履歴は予約に関連付けられたままです。
最終的な予約は、ゲストの全体的な体験の背後にある運用の詳細を持っています。
Booking Ninjasは、すべてを1泊の部屋料金に還元するのではなく、パッケージと料金管理としてアプローチしました。
現在の 料金管理 機能も、Salesforce内で季節、カレンダーに基づく、ルール駆動の価格設定をサポートしています。
Movaraの運営モデルがどのように組み合わさったか
| Movaraが必要としたもの | Booking Ninjasのアプローチ | 設定が簡単にできること |
|---|---|---|
| プライベート + 共有部屋の在庫 | 予約と可用性ルールの接続 | 同じ物理的な部屋のプライベート版と共有版が正しく互いにブロックできる。 |
| 異なるウェルネスパッケージ | パッケージ + 料金管理 | 宿泊、プログラムコンポーネント、日付、占有率、価格ルールが同じ滞在構造の一部として残ることができる。 |
| 長期および短期の滞在 | ルールベースの価格設定 | 異なる価格期間と滞在期間を、すべての予約を1つの固定の宿泊料金に還元することなく処理できる。 |
| デポジットと残高 | 予約 + 支払いワークフロー | 前払い、残高、請求書、カード、支払い履歴がゲストの予約に関連付けられたままです。 |
| 部屋の準備状況を把握する | ハウスキーピングの状態 | チェックアウトにより、部屋が空き状態の汚れた状態に移行し、ハウスキーピングがそれを空き状態の清掃済みで利用可能な在庫に戻すことができる。 |
| 滞在中にサービスを販売する | ポイントオブセール | スパサービス、パーソナルトレーニング、商品、エクスカーション、テイクアウトの食事、その他の購入がゲストと予約に関連付けられたままです。 |
| 前払いと付随的支出を明確に保つ | 請求 + POS構造 | 前払いのウェルネスパッケージが、到着後の追加購入と区別されることができる。 |
予約がゲストの運営の始まりとなった
Movaraのスタッフは、予約確認以上のものが必要でした。
彼らは、誰が到着するのか、現在誰が滞在しているのか、ゲストがどの部屋にいるのか、残高が残っているか、何が支払われたのか、宿泊施設が再び販売可能になるのはいつかを理解する必要がありました。
Booking Ninjasは、Salesforceネイティブの予約記録に基づいてこれらのプロセスを維持することに取り組み、予約が滞在中も有用であり続けるようにしました。
これにより、予約は販売記録から、ゲストが到着した後も運営が引き続き使用できるものに変わります。
可用性は運用部屋の状態にも依存していた
ゲストがチェックアウトすることは、自動的に次の到着のために部屋が準備できていることを意味しません。
Movaraは、部屋がシンプルだが重要なシーケンスを通過する必要がありました：
これにより、ハウスキーピングが在庫管理と直接結びつきます。
部屋は物理的には空であっても、運用状況が準備が整ったと示すまで、販売可能な在庫として扱われるべきではありません。
このため、可用性は予約とリソースの実際の状態の両方を反映する方が有用です。
ウェルネスパッケージ購入後もリゾート体験は続いた
Movaraの施設内取引は、通常のレストラン中心のリゾートPOSとは異なって見えました。
ゲストは、マッサージ、パーソナルトレーニング、プロショップ商品、プライベートハイキング、エクスカーション、テイクアウトの食事、その他のウェルネスサービスや付随的なものを購入することができました。
Booking Ninjasは、これらの実際の購入に基づいたPOS体験を形作ることに取り組みました。一般的なレストランテーブルのワークフローではありません。
広範な目標は、追加の支出をゲストと予約に関連付けたままにし、前払いのウェルネスパッケージとは区別することでした。
Booking Ninjasの現在のPOSも、Salesforce内で取引を予約、サービス、メンバーシップ、顧客記録とリンクしています。
システムは実際の運用フィードバックを通じて構築された
Movaraプロジェクトの定義的な部分は、実装プロセス自体でした。
Booking Ninjasは、既存の運営をレビューし、Salesforce環境を作成し、Movaraのチームと共に定期的なレビューとテストセッションを通じて作業しました。
そのフィードバックは、一般的なリゾート実装では見逃しがちな詳細を明らかにしました：共有部屋のラベルがどのように表示されるべきか、在庫がどのようにブロックされるべきか、パッケージコンポーネントがどのように価格設定されるべきか、部屋の状態がどのように変わるべきか、前払いのプログラム料金が付随的なものとどのように異なるべきか。
実装は意図的に段階的に行われました。
コアの予約とPMSワークフローが最初に来て、より深いPOS、会計、報告、クレジット、サポートプロセスが続く予定でした。
プロジェクトが示したこと
Movaraは最終的に、より広範な実装を一時停止し、既存のPMSを使用し続けながら他のビジネスの優先事項に焦点を当てました。
計画された完全なPMS、会計、POSの置き換えは、したがって完了には至りませんでした。
それでも、実質的な実装作業は、Booking Ninjasが異常に複雑なウェルネスリゾートの運営をモデル化できることを示しました。
プライベート版と共有版の同じ宿泊施設は、矛盾する予約を許可することなくモデル化できました。
予約構造は、滞在の長さ、占有率、季節的な期間、パッケージ、プロモーション、異なる価格コンポーネントを考慮することができました。
予約、部屋の状態、支払い、ゲスト情報、その他の運用活動は、同じSalesforce基盤を共有できました。
在庫は、宿泊施設が実際に別のゲストのために準備が整っているかどうかを反映できました。単に前のゲストが出発したかどうかではありません。
追加のサービスや購入は、ゲストと予約に基づいて設計され、孤立した取引にはなりませんでした。
プロジェクトは、異常なルールを持つウェルネスリゾートを、従来のホテルのテンプレートに還元することなくモデル化できることを示しました。
Movaraは一般的なホテルPMSを必要としなかった
リゾートの製品は、設計上異なっていました。
プライベートおよび共有在庫は異なる方法で機能しました。ウェルネスプログラムが価格を形成しました。滞在は数週間にわたることができました。ゲストはプログラムの周りで追加の購入を行いました。ハウスキーピングの状態が在庫が本当に準備が整っているかに影響を与えました。
厳格なPMSは、これらの違いを回避策に押し込む可能性があります。
Booking Ninjasは、他のアプローチを取りました：Salesforceを運営の基盤として使用し、その後、予約、価格設定、支払い、サービス、運用ルールを組織に合わせて構成しました。
この原則は、今日のBooking Ninjasにとっても中心的なものです：異なる運営が同じプラットフォーム基盤を使用でき、同じビジネスルールに従う必要はありません。
この種のリゾート設定についてもっと学ぶ
予約、在庫、キャパシティ、制限、運用ルールが、リソースが実際に予約可能かどうかを決定する方法をご覧ください。
可用性の管理方法 →予約、支払い、サービス、その他の承認された活動が同じゲストの周りでどのように関連付けられるかをご覧ください。
顧客記録とは？ →Booking Ninjasが複雑な予約を価格設定、可用性、運用ルール、Salesforceワークフローとどのように接続しているかをご覧ください。
料金管理を探る →このストーリーについて： Booking Ninjasは、プライベートおよび共有宿泊在庫、ウェルネスパッケージ、複雑な価格設定、支払い、部屋の状態、ゲストの運営、POS要件、段階的な拡張に関してMovara Fitness Resortと大規模な構成および実装作業を完了しました。Movaraは後に、より広範な実装を一時停止し、既存のPMSを使用し続けたため、このページはBooking NinjasをMovaraの完成した生産PMSとして提示したり、未確認の財務または運用結果を主張したりするものではありません。
あなたのリゾートは、PMSに合わせて製品を単純化する必要はありません。
Booking Ninjasが、複雑な在庫、パッケージ、料金、ゲスト、支払い、サービス、部屋の状態、運営を、あなたの滞在が実際に機能する方法に基づいてどのように接続できるかをご覧ください。
.jpeg)
.jpg)
.png)
