ゴールディングスのモニュメントバレーには、1つのゲスト目的地がありましたが、その背後には多くの異なる運営とシステムが働いていました。
ゴールディングスリゾート ロッジの部屋、ヴィラ、RVサイト、キャンプ場の宿泊、ダイニング、ツアー、小売、その他のゲストサービスをモニュメントバレー体験の周りに組み合わせています。
ブッキングニンジャは、ゴールディングスとコンサルティングパートナーと共に、各部門を別々のソフトウェア問題として扱うのではなく、全体の運営を見据えた技術的方向性をサポートしました。
課題：1つのゲスト体験、多くのシステムがその背後にある
プロジェクトの時点で、ゴールディングスの運営の異なる部分は、予約、販売時点、部屋のアクセス、小売、コミュニケーション、関連機能にわたる別々のオンプレミスシステムに依存していました。
同じ宿泊中に1人のゲストが物件のいくつかの部分と相互作用する場合、これは困難になります。
- ホテルの部屋とヴィラ
- RVとキャンプ場の在庫
- グループと会議スペース
- ゲストの履歴
- ハウスキーピング
- メンテナンス
- レストランとPOS活動
- 支払いと報告
各部門は異なる仕事を持つかもしれませんが、情報はしばしば同じゲスト、予約、ユニット、または取引に属します。
異なるリソースには異なるワークフローが必要でした。
ホテルの部屋、ヴィラ、RVサイト、キャンプ場のユニット、会議スペースはすべて予約可能です。
しかし、それはすべてが同じワークフローに従うべきだということではありません。
宿泊は夜間の空き状況と料金に依存する場合があります。RVサイトには異なる在庫の詳細があります。会議スペースはイベントの日付やグループの要件に依存する場合があります。レストランの取引は再び別のプロセスに従います。
したがって、有用な技術的方向性は、ゴールディングスを標準的なホテルモデルに平坦化することではありませんでした。
異なるリソースが必要なルールを維持しながら、基盤となる運営の全体像を接続することでした。
ブッキングニンジャの方向性：全体のデスティネーションを接続する
歴史的なプロジェクトの範囲は、1つの孤立した予約機能ではなく、ゴールディングスの環境のいくつかの部分を見渡しました。
部屋、ヴィラ、RV在庫、キャンプ場のリソース、グループ、その他の予約可能なスペースを構造化された空き状況に接続します。
予約とゲスト情報を有用に保ち、他のリゾートの部分と相互作用する際に役立てます。
ハウスキーピング、メンテナンス、サービスリクエスト、その他の作業を関与する宿泊またはゲストに接続します。
支払いとPOS活動を予約、ゲスト、サービス、運営記録に近づけます。
管理者に占有率、収益、税金、ゲスト、運営報告のためのより強力な基盤を提供します。
運営要件がどのように組み合わさるか
| ゴールディングスのニーズ | ブッキングニンジャの方向性 | 接続されたモデルが改善できること |
|---|---|---|
| 異なる宿泊タイプを管理する | 予約管理 | 部屋、ヴィラ、RVサイト、キャンプ場の在庫、その他のリソースは、共有の予約構造内に存在しながら、それぞれのルールを保持できます。 |
| 空き状況を信頼できるものに保つ | 空き状況 + 予約管理 | 予約、制限、キャパシティ、在庫の変更は、繰り返し手動で確認する必要がなく、同じ空き状況の画像にフィードできます。 |
| ハウスキーピングとメンテナンスを調整する | 作業指示管理 | 運営作業は、実際に作業が行われる部屋、ヴィラ、サイト、またはその他の場所に接続できます。 |
| レストラン活動を接続する | 販売時点 | 取引は、予約、サービス、顧客、在庫、運営報告と接続でき、孤立した活動として残るのではなくなります。 |
| グループをサポートする | グループ予約 + 請求ワークフロー | 関連する予約と請求は、1つのグループが複数の宿泊施設やサービスに触れるときに、より近くに留まることができます。 |
| 固定デスクから離れて作業する | モバイル / タブレットアクセス | スタッフは、すべてのアクションを1つのワークステーションを通じてルーティングするのではなく、ゲストや運営のリモートエリアに近くで作業できます。 |
| ゲストの履歴を活用する | Salesforce顧客記録 | 宿泊履歴、取引、リクエスト、その他の承認された活動は、より有用な顧客像に貢献できます。 |
| 統合の余地を残す | Salesforce + APIベースの統合 | 運営環境は、すべてのツールを一度に置き換える必要がなく、外部チャネルや専門システムと接続できます。 |
1人のゲストがリゾートのいくつかの部分に触れることができます。
シンプルな例が問題を見やすくします。
ゲストがゴールディングスでヴィラを予約します。宿泊中、彼らはレストランで食事をし、その食事を宿泊にチャージします。後で、彼らはヴィラの問題を報告し、スタッフの助けが必要です。
ゲストにとって、それらはすべて1つの宿泊の一部です。
しかし、断片化された技術環境では、ヴィラの予約、レストランの取引、ゲストプロファイル、メンテナンスの問題、スタッフの応答はすべて異なる場所に存在する可能性があります。
それは、すべての部門がすべてを見えるわけではないということを意味しません。Salesforceの権限は、どのユーザーがどのレコードを見たり変更したりできるかを決定することができます。
フロントデスク、ハウスキーピング、メンテナンスは同じ運営の全体像を必要としました。
フロントデスクは、ゲストが到着することを知っているかもしれません。
ハウスキーピングは、宿泊が準備できているかどうかを知る必要があります。
メンテナンスは、ユニットに問題があるときに知る必要があります。
管理者は、問題がまだオープンであるか、ユニットが通常通り使用できるかを知る必要があります。
これらのチームは異なる仕事を持っていますが、作業は同じ部屋、ヴィラ、サイト、予約、またはゲストに接続できます。
ブッキングニンジャの現在の作業指示管理機能は、Salesforce内で運営作業の場所、割り当て、ステータス、優先度、履歴を接続することによってそのモデルに従っています。
ゲストの関係は、彼らが部屋を離れたときに止まりませんでした。
ゴールディングスは、食事、小売、その他のゲストサービスも運営しています。
それは、1つのシステムで取引が行われる一方で、ゲストの宿泊が別の場所にあるときに、断片化の別の機会を生み出します。
歴史的な要件には、特にレストランとPOS活動、部屋の請求、モバイル注文と支払い、関連する取引ワークフローが含まれていました。
ブッキングニンジャの現在の 販売時点 は、取引を顧客、予約、サービス、在庫、運営記録にリンクさせることによって、より広いアイデアをサポートしています。
運営はフロントデスクを超えて進む必要がありました。
ゴールディングスは、リモート機能も重要であると認識しました。
それは、ゲストとリソースがロッジの建物、ヴィラ、RVエリア、キャンプ場の在庫、リゾートの他の部分に広がっているデスティネーション運営において重要です。
スタッフは、情報を確認したり運営アクションを完了するために、常に1つの固定フロントデスクのワークステーションに戻る必要はありません。
モバイルとタブレットアクセスは異なるモデルを作成します：スタッフは、ゲストや運営の問題が実際にある場所に近くで作業できます。
ビジネスの価値は、オペレーション間のギャップを減らすことから生まれます
このプロジェクトのための検証済みの前後の指標はないため、価値は特定のパーセンテージの改善として提示されるべきではありません。
オペレーションモデルは、接続されたシステムが回避可能な作業を減らし、収益機会を保護できる場所を示しています。
接続された記録は、同じゲスト、予約、支払い、またはオペレーション情報を複数の場所に入力または調整する必要を減らすことができます。
ハウスキーピング、メンテナンス、予約、サービス作業は、関与するリソースまたはゲストに接続されたままにできます。
明確な空き状況とユニットの状態は、スタッフが実際に販売可能な宿泊施設やリソースを理解するのに役立ちます。
レストラン、ゲスト、ルームチャージ、支払いの活動は、運用コンテキストを共有することで追跡しやすくなります。
構造化された予約、パッケージ、料金、グループのワークフローは、予約の複雑さが増すにつれて手動調整への依存を減らすことができます。
オペレーションおよび財務データは、接続された記録から得られる場合、管理者により明確な視点を提供できます。
アーキテクチャは成長する場所も必要でした
Gouldingの要件は、即時のワークフローを超えていました。
このプロジェクトは、将来のチャネル接続、自動料金更新、マーケティング、統合、ゲストコミュニケーション、より広範なレポートニーズも考慮しました。
それは重要です。なぜなら、確立された目的地は新しいシステムが導入された後も変わり続けるからです。
Salesforceの基盤は、新しい要件が現れるたびに別のソフトウェアの置き換えを始めるのではなく、同じ運用記録の周りに接続とワークフローを追加する方法を提供します。
Gouldingは、ソフトウェアに合わせてよりシンプルなビジネスになる必要はありませんでした。
これがGouldingをBooking Ninjasアプローチの強力な例にしているのです。
目的地は、伝統的なソフトウェアがしばしば分けるいくつかのカテゴリを横断しています：ホテル宿泊、ヴィラ、RVおよびキャンプ場の滞在、グループビジネス、イベント、ダイニング、小売、施設、ゲストサービス。
厳格なプラットフォームは、組織にそれが本当にどのビジネスであるかを決定するよう求めるかもしれません。
Booking Ninjasは逆のアプローチを取ることができます：共通のSalesforce基盤を使用し、その後、必要なオペレーションの部分に周りの異なるワークフローを構成します。
異なる部分は、接続されるべきデータと関係を共有しながら、異なるルールを維持できます。
予約から始めて、目的地が必要とするものを接続します
予約エンジンと予約管理は、コアの予約構造を提供できます。
より複雑なリゾートは、その基盤をグループ予約、料金管理、POS、支払い、ハウスキーピング、作業指示、在庫、レポート、モバイルアクセス、ポータル、チャネル接続、およびそれらの機能が実際のオペレーションの問題を解決する場所で拡張できます。
重要な点は、すべてのモジュールをインストールすることではありません。
目的地の相互依存する部分を接続することです。
より広いユースケースについては、 リゾート管理ソリューション .
接続されたリゾートオペレーションについて詳しく学ぶ
予約、キャパシティ、制限、その他のルールが、部屋、サイト、スペース、またはリソースがまだ予約可能かどうかを決定する方法を確認してください。
空き状況の管理方法 →メンテナンス作業が、実際に問題がある部屋、ユニット、場所、または資産に接続されたままにできる方法を確認してください。
メンテナンスが部屋や資産に接続する方法 →予約、支払い、サービス活動、その他の承認された情報が、同じ顧客の周りに接続されたままにできる方法を確認してください。
顧客記録とは？ →このストーリーについて： Booking Ninjasは、Gouldingのモニュメントバレーと広範なオペレーショナルテクノロジーの範囲をカバーするコンサルティングパートナーと協力しました。宿泊、ヴィラ、RVおよびキャンプ場の在庫、グループ、ゲスト活動、POS、オペレーション、レポート、モバイル機能、将来の統合を含みます。元の要件は、オペレーションの問題と技術の方向性を説明するために使用されます。このページは、要求されたすべてのRFP機能が最終的に展開されたと主張したり、未確認の財務結果を報告したりするものではありません。
すべてのオペレーションを別々のシステムにすることなく、1つの目的地を運営します。
Booking Ninjasが、予約、リソース、ゲスト、支払い、POS、メンテナンス、スタッフのワークフロー、レポート、統合を、目的地が実際にどのように運営されているかに基づいて接続できる方法を確認してください。
.jpeg)
.jpg)
.png)
