Constructor Universityは、レガシーな学生住宅システムを置き換える必要がありましたが、古いソフトウェアを別の孤立したデータベースに置き換えることは、新たな問題を生むだけでした。
Constructor University はすでに学生情報にSalesforceを利用していました。Booking Ninjasは、その既存の環境で作業し、住宅が学生の大学記録の別の接続部分になるようにしました。
このプロジェクトは、住宅予約、学生セルフサービス、割り当てルール、支払い、運用データ、そしてSalesforceの基盤に関する報告を一つにまとめました。Constructorがすでに信頼しているものです。
課題：住宅は部屋の空き状況以上のものに関わっていました。
Constructorは、以前の住宅システムであるMercuryから移行していました。
それは、既存の物件、学生の連絡先、予約、住宅履歴、運用プロセスを移行の一部として考慮する必要があることを意味していました。
しかし、住宅自体も空いている部屋を割り当てる以上に複雑でした。
- 学生記録
- 住宅の好み
- 部屋の適格性
- 予約
- デポジットと支払い
- 部屋の割り当て
- 居住生活の報告
- チェックインとチェックアウト
新入生と復学生は異なる道をたどることができました。一部の部屋タイプには異なる適格ルールがありました。住宅チームは変更された報告が必要でした。学生はプロセスの一部を完了するための使いやすい方法が必要でした。
最も重要な決定：学生データの基盤としてSalesforceを維持すること
Constructorはすでに独自のSalesforce環境と確立された学生記録を持っていました。
初期の懸念は、新しい住宅プラットフォームが別のカスタムデータ構造を作成し、それが大学に戻るための別の統合を必要とするかどうかでした。
Booking Ninjasは、Constructorの既存のSalesforceの連絡先および個人アカウント構造を使用して作業しました。
住宅情報は、大学内の他の場所ですでに使用されている学生記録に接続されたままとなり、認可されたチームは、すべてのユーザーがBooking Ninjasアプリケーション内で作業する必要なく、関連情報にアクセスできるようになりました。
これは、プロジェクト中に提起された最も明確な懸念の一つに対処しました：住宅は別のデータアイランドになる必要はありませんでした。
Booking Ninjasはこの広範な構造を以下で説明しています。 Salesforce Orgとは何ですか？
学生住宅の旅は一つの接続されたフローになる可能性があります。
有用な体験は、学生記録から始まり、住宅ライフサイクルを通じて続きます。
ConstructorがSalesforceで既に維持している学生情報から始めます。
学生に関連する情報とアクションを持つブランド化された住宅のエントリーポイントを提供します。
学生のステータス、好み、部屋のタイプ、および適用される要件が次のステップを形成します。
予約は、その学生に適用される支払いまたは承認ルールに従うことができます。
住宅記録は、割り当て、居住生活、報告、そして後のライフサイクル作業のために利用可能なままです。
Constructorのセットアップがどのように組み合わさったか
| Constructorのニーズ | Booking Ninjasのアプローチ | それが可能にしたこと |
|---|---|---|
| レガシー住宅データを置き換える | Salesforceネイティブの移行構造 | 物件、連絡先、予約、および関連する履歴データは、空の住宅システムから始めるのではなく、新しい環境に移行することができました。 |
| 既存の学生記録を維持する | 既存のSalesforce連絡先 / 個人アカウント構造 | 住宅は、別の独立した学生データベースを作成するのではなく、大学の確立された学生情報の周りで機能することができました。 |
| 学生にセルフサービスを提供する | 学生ポータル | 学生は、Constructorブランドの環境にアクセスし、住宅の旅の関連部分を自分で完了することができました。 |
| 異なる住宅ルールを適用する | 予約ルール + Salesforceワークフロー | 新入生、復学生、部屋のタイプ、好み、その他の学生属性が、学生に示されるプロセスに影響を与えることができます。 |
| 住宅デポジットを処理する | 支払い処理 | 適用される支払い活動は、学生と予約に接続されたままとなり、別々に調整されるのではなくなります。 |
| 未完了の予約を使いやすく保つ | 予約状況 + 支払いワークフロー | 学生は、最初から住宅リクエストを再構築するのではなく、未解決のステップに戻ることができます。 |
| 変更された報告をサポートする | Salesforceレポート + ダッシュボード | 居住生活は、同じデータから建物、部屋、占有状況、学生属性、または割り当てに関する異なるビューを構築することができました。 |
学生は、住宅の旅の多くを自分で扱うことができました。
Constructorは、単なる管理用の住宅画面以上のものが必要でした。
学生もプロセスと対話するための明確な場所が必要でした。
Booking Ninjasは、学生アクセスを大学の住宅ワークフローに接続できるブランド化された学生ポータルを構成しました。
このポータルは、学生が自分に関連する住宅情報を確認し、適用可能な好みを維持し、予約ステップを続け、適用可能な住宅支払いなどのアクションを完了する場所になることができます。
それは、ルーチン作業をすでに答えを知っている人に近づけます。
Booking Ninjasの現在の 学生ポータル は、学生のセルフサービスをSalesforceの記録に直接接続し、プラットフォームの外に学生の別のコピーを維持することはありません。
大学の住宅ルールは、ワークフローの一部になる可能性があります。
Constructorは、すべての学生に対して同一の住宅プロセスを持っていませんでした。
新入生と復学生は異なる要件を持つ可能性があります。特定の部屋タイプには異なる適格性がある場合があります。学生の好みや既存の大学情報も、次に何が起こる必要があるかに影響を与える可能性があります。
スタッフに手動であらゆるバリエーションを記憶し説明させるのではなく、SalesforceデータとBooking Ninjasのワークフローが適切な住宅パスを決定するのを助けることができます。
このプロジェクトは、部屋の好み、階の好み、国籍、喫煙の好み、ルームメイトの考慮、制御された在庫の行動など、より深い割り当て要件も探求しました。
これらの高度なマッチングおよび割り当てのアイデアは、すべてが確認された生産機能として提示されるのではなく、ConstructorとBooking Ninjasが実装中に定義し洗練していた領域として理解されるべきです。
支払いは予約状態の一部になる可能性があります。
Constructorは、学生によって異なる財務パスを持っていました。
たとえば、復学生は住宅デポジットが必要な場合があり、新入生は別のプロセスをたどることができます。
Booking Ninjasは、Stripeの支払い活動を学生と予約に接続する作業を行い、適用可能な支払いが住宅ワークフローの一部になるようにしました。
それは、はっきりとした順序を作り出します：
同じ構造は、予約を開始したがすぐに支払いを完了しない学生にも役立ちます。予約はその状態を保持できるため、学生は再び始めるのではなく、未解決のステップに戻ることができます。
Booking Ninjasの現在の支払いツールは、トランザクションを予約、請求書、Salesforceの顧客記録に直接接続します。 :contentReference[oaicite:3]{index=3}
レジデンシャルライフは、新しいレポートが必要になるたびにソフトウェアベンダーを待ちたくありませんでした。
大学の住宅に関する質問は常に変化しています。
ある人は特定の建物にいる学生が必要かもしれません。別の人は占有率が必要かもしれません。別の人は未成年者、国籍情報、部屋の割り当て、または他の学生属性が必要かもしれません。
Constructorのチームは、固定されたレポートのリストでは不十分であることを明確にしました。
住宅記録がSalesforceに残っているため、権限のあるチームはSalesforceのレポートと許可されたエクスポートを使用して、同じ基礎データから異なる質問に答えることができました。
- 建物と部屋
- 学生の割り当て
- 占有率
- 学生属性
- 予約状況
- 支払い状況
- 住宅の例外
- 運用エクスポート
実際のユーザーがシステムを形作り続けました。
ユーザー受け入れテストは、ソフトウェアが日常の大学運営に到達する際に重要な詳細を明らかにしました。
ConstructorとBooking Ninjasは、学生の種類、部屋の適格性、予約状態、支払い行動、レポート、好み、在庫、用語、住宅ライフサイクル作業に関する質問を検討しました。
チームはまた、チェックアウトと部屋の検査をより構造化する方法を探求し、例外を特定し、通常の年度末の出発に必要な手動処理の量を減らすことを含めました。
そのいくつかの高度なワークフローはまだ定義中でしたが、その実装プロセス自体は、Constructorのプラットフォームのバージョンが実際の住宅運営に基づいて形を変え続けることができることを示しました。
Constructorにとってより接続されたもの
このストーリーのための確認された数値のポストローンチ結果はないため、価値はBooking Ninjasが接続した作業と、システムが削減するように設計された手動の引き継ぎを通じて最もよく示されます。
大学は住宅を完全に別の学生情報環境として扱う必要はありませんでした。
住宅の旅は、スタッフの指示や手動のフォローアップに依存するのではなく、ブランド化されたポータルを通じて進むことができました。
学生のステータスや他のSalesforce情報は、どの住宅プロセスが適用されるかを判断するのに役立ちます。
適用可能な住宅のデポジットは、別の切り離されたチェックではなく、同じ予約履歴の一部になることができます。
Salesforceのレポートは、レジデンシャルライフに固定されたベンダーレポートライブラリに依存するよりも多くの柔軟性を提供しました。
実際のUATシナリオは、Constructorが1つの固定された住宅プロセスを受け入れることを強制するのではなく、構成にフィードバックを提供することができます。
彼らの大学。彼らの学生。彼らの住宅ルール。彼らの組織。
Constructor Universityは、Booking NinjasのSalesforceネイティブモデルの特に明確な例です。
大学はすでに組織、学生記録、フィールド、権限、レポート、データ関係を持っていました。
Booking Ninjasは、住宅を近代化するために大学にその基盤を捨てるように求める必要はありませんでした。
代わりに、住宅は同じ広範な環境内の別の運用層になることができます。
それがまた、Booking Ninjasが現在の学生住宅プラットフォームを説明する方法です：学生、部屋、ベッド、割り当て、支払い、メンテナンス、運用情報はSalesforceに集中して留まることができます。
住宅予約は、より広いレジデンシャルワークフローの始まりになることができます。
予約管理は、コアの住宅記録を提供できます。
その周りで、大学は学生ポータル、空き状況、部屋とベッドの割り当て、支払い、レポート、メンテナンス、チェックイン、チェックアウト、コミュニケーション、その他のレジデンシャルライフのワークフローを必要に応じて接続できます。
Constructorは、すでに大学の多くの部分に触れているため、より豊かなセットアップが必要でした。
小規模な住宅は、より少ない部品から始めることができます。
有用なポイントは、両者が同じSalesforce基盤を使用できることであり、すべての機関を同じ住宅プロセスに強制することはありません。
より広いユースケースについては、次を参照してください。 学生住宅ソリューション .
この学生住宅セットアップについて詳しく学ぶ
学生のセルフサービスがSalesforceデータ、権限、請求、大学のワークフローに直接接続される方法を確認してください。
学生ポータルを探る →記録、ワークフロー、ユーザー、レポート、自動化、その他の運用ツールが1つの組織特有の環境に存在できる方法を確認してください。
Salesforce組織とは？ →予約、ポリシールール、空き状況、変更、運用レポートがSalesforce内で接続されたままでいる方法を確認してください。
予約管理を探る →このストーリーについて： このページは、Constructor UniversityのBooking Ninjasの実装とユーザー受け入れテストの資料を反映しており、レガシー移行、Salesforceの学生記録、住宅予約、ポータルセルフサービス、支払いワークフロー、レポート、住宅ルールの構成を含みます。高度なルームメイトマッチング、制御されたオーバーブッキング、検査ワークフローは、実装中に探求または洗練された領域としてのみ説明され、後の生産証拠が最終的な展開を確認しない限り、そうです。
別の学生データベースを作成することなく、学生住宅を近代化します。
Booking Ninjasが、予約、部屋、学生、支払い、ポータル、レポート、レジデンシャルライフのワークフローを、あなたの機関がすでに使用しているSalesforce環境の周りでどのように接続できるかを確認してください。
.jpeg)
.jpg)
.png)
