Constructor University

أهم قرار: الاحتفاظ بـ Salesforce كأساس بيانات الطلاب

كانت كونستراكتور تمتلك بالفعل بيئة Salesforce الخاصة بها وسجلات الطلاب المعتمدة.

كانت هناك مخاوف مبكرة بشأن ما إذا كانت منصة السكن الجديدة ستخلق هيكل بيانات مخصص منفصل يحتاج بعد ذلك إلى تكامل آخر مع الجامعة.

عملت Booking Ninjas بدلاً من ذلك مع هيكل جهات الاتصال وحسابات الأشخاص الموجودة في Salesforce الخاصة بكونستراكتور.

يمكن أن تظل معلومات السكن متصلة بسجلات الطلاب المستخدمة بالفعل في أماكن أخرى في الجامعة، ويمكن للفرق المصرح لها الوصول إلى المعلومات ذات الصلة دون الحاجة إلى أن يعمل كل مستخدم داخل تطبيق Booking Ninjas نفسه.

هذا عالج واحدة من أوضح المخاوف التي أثيرت خلال المشروع: لم يكن السكن بحاجة إلى أن يصبح جزيرة بيانات أخرى.

تشرح Booking Ninjas هذه الهيكلية الأوسع في ما هو Salesforce Org؟

يمكن أن تصبح رحلة سكن الطلاب تدفقًا متصلًا واحدًا

تبدأ التجربة المفيدة بسجل الطالب وتستمر خلال دورة حياة السكن.

كيف تناسب إعداد كونستراكتور معًا

يمكن أن يتعامل الطلاب مع المزيد من رحلة السكن بأنفسهم

كانت كونستراكتور بحاجة إلى أكثر من شاشة سكن إدارية.

كان الطلاب أيضًا بحاجة إلى مكان واضح للتفاعل مع العملية.

قامت Booking Ninjas بتكوين بوابة طلاب تحمل علامة تجارية حيث يمكن ربط وصول الطلاب بسير عمل سكن الجامعة.

يمكن أن تصبح البوابة المكان الذي يرى فيه الطلاب معلومات السكن ذات الصلة بهم، ويحافظون على التفضيلات القابلة للتطبيق، ويستمرون في خطوات الحجز، ويكملون إجراءات مثل دفع السكن القابل للتطبيق.

هذا يقرب العمل الروتيني من الشخص الذي يعرف الإجابة بالفعل.

الحالي لـ Booking Ninjas بوابة الطلاب تحافظ على خدمة الطلاب الذاتية متصلة مباشرة بسجلات Salesforce بدلاً من الحفاظ على نسخة أخرى من الطالب خارج المنصة.

يمكن أن تصبح قواعد سكن الجامعة جزءًا من سير العمل

لم يكن لدى كونستراكتور عملية سكن متطابقة لكل طالب.

يمكن أن يكون لدى الطلاب الجدد والطلاب العائدين متطلبات مختلفة. يمكن أن تكون لبعض أنواع الغرف أهلية مختلفة. يمكن أن تؤثر تفضيلات الطلاب والمعلومات الحالية في الجامعة أيضًا على ما يجب أن يحدث بعد ذلك.

بدلاً من مطالبة الموظفين بتذكر وشرح كل اختلاف يدويًا، يمكن أن تساعد بيانات Salesforce وسير عمل Booking Ninjas في تحديد المسار المناسب للسكن.

استكشف المشروع أيضًا متطلبات تخصيص أعمق مثل تفضيلات الغرف، تفضيلات الطوابق، الجنسية، تفضيلات التدخين، اعتبارات زملاء السكن، وسلوك المخزون المتحكم فيه.

يجب أن تُفهم تلك الأفكار المتقدمة في المطابقة والتخصيص كمجالات كانت كونستراكتور وBooking Ninjas تعرفها وتقوم بتحسينها خلال التنفيذ، بدلاً من تقديمها جميعًا كوظائف إنتاج مؤكدة.

يمكن أن تصبح المدفوعات جزءًا من حالة الحجز

كان لدى كونستراكتور أيضًا مسارات مالية مختلفة اعتمادًا على الطالب.

على سبيل المثال، قد يحتاج الطلاب العائدون إلى إيداع سكن بينما يمكن أن يتبع الطلاب الجدد عملية أخرى.

عملت Booking Ninjas على ربط نشاط الدفع عبر Stripe مع الطالب والحجز بحيث يمكن أن تصبح المدفعة القابلة للتطبيق جزءًا من سير عمل السكن نفسه.

هذا يخلق تسلسلًا أوضح بكثير:

يساعد نفس الهيكل أيضًا الطلاب الذين يبدأون الحجز لكن لا يكملون الدفع على الفور. يمكن أن يحتفظ الحجز بحالته حتى يتمكن الطالب من العودة إلى الخطوة المعلقة بدلاً من البدء من جديد.

تربط أدوات الدفع الحالية الخاصة بـ Booking Ninjas المعاملات مباشرة مع الحجوزات والفواتير وسجلات عملاء Salesforce. :contentReference[oaicite:3]{index=3}

لم ترغب إدارة الحياة السكنية في الانتظار لمورد برمجي في كل مرة تحتاج فيها إلى تقرير جديد

تتغير أسئلة السكن الجامعي باستمرار.

قد يحتاج شخص واحد إلى طلاب في مبنى معين. وقد يحتاج آخر إلى الإشغال. وقد يحتاج آخر إلى معلومات عن القاصرين، أو الجنسية، أو تخصيص الغرف، أو سمات الطلاب الأخرى.

أوضح فريق Constructor أن قائمة ثابتة من التقارير لن تكون كافية.

نظرًا لأن سجلات السكن ظلت في Salesforce، يمكن للفرق المصرح لها استخدام تقارير Salesforce والصادرات المسموح بها للإجابة على أسئلة مختلفة من نفس البيانات الأساسية.

استمر المستخدمون الحقيقيون في تشكيل النظام

كشفت اختبارات قبول المستخدم عن التفاصيل التي تهم عندما يصل البرنامج إلى العمليات اليومية في الجامعة.

عملت Constructor و Booking Ninjas على الأسئلة المتعلقة بأنواع الطلاب، وأهلية الغرف، وحالات الحجز، وسلوك الدفع، والتقارير، والتفضيلات، والمخزون، والمصطلحات، وعملية السكن.

استكشفت الفريق أيضًا كيف يمكن أن يصبح الخروج وتفتيش الغرف أكثر تنظيمًا، بما في ذلك تحديد الاستثناءات وتقليل كمية المعالجة اليدوية المطلوبة للرحيل العادي في نهاية العام.

بعض تلك العمليات المتقدمة كانت لا تزال قيد التعريف، لكن عملية التنفيذ نفسها أظهرت كيف يمكن أن تستمر نسخة Constructor من المنصة في التكيف حول العمليات السكنية الحقيقية.

ما أصبح أكثر ارتباطًا لـ Constructor

ليس لدينا نتائج عددية موثوقة بعد الإطلاق لهذه القصة، لذا فإن القيمة تُظهر بشكل أفضل من خلال العمل الذي ربطته Booking Ninjas والتسليمات اليدوية التي صُمم النظام لتقليلها.

جامعتهم. طلابهم. قواعد سكنهم. منظمتهم.

تعد جامعة Constructor مثالًا واضحًا لنموذج Booking Ninjas القائم على Salesforce.

كانت الجامعة تمتلك بالفعل منظمة، وسجلات طلاب، وحقول، وأذونات، وتقارير، وعلاقات بيانات.

لم تكن Booking Ninjas بحاجة إلى طلب من الجامعة للتخلص من تلك القاعدة من أجل تحديث السكن.

بدلاً من ذلك، يمكن أن يصبح السكن طبقة تشغيلية أخرى داخل نفس البيئة الأوسع.

وهذا أيضًا كيف تصف Booking Ninjas منصة سكن الطلاب الحالية: يمكن أن تظل معلومات الطالب، والغرفة، والسرير، والتخصيص، والدفع، والصيانة، والعمليات مركزية في Salesforce.

يمكن أن يصبح حجز السكن بداية لعملية سكنية أوسع

يمكن أن توفر إدارة الحجوزات سجل السكن الأساسي.

حولها، يمكن للجامعة ربط بوابات الطلاب، والتوافر، وتخصيصات الغرف والأسرة، والمدفوعات، والتقارير، والصيانة، وتسجيل الوصول، وتسجيل الخروج، والتواصل، وغيرها من عمليات الحياة السكنية حسب الحاجة.

كانت Constructor بحاجة إلى إعداد أغنى لأن عمليات السكن لديها كانت تتعلق بالفعل بالعديد من أجزاء الجامعة.

يمكن أن يبدأ السكن الأصغر بعدد أقل من القطع.

النقطة المفيدة هي أن كلاهما يمكن أن يستخدم نفس قاعدة Salesforce دون إجبار كل مؤسسة على نفس عملية السكن.

للحالة الأوسع، انظر حل سكن الطلاب .

تعرف على المزيد حول إعداد سكن الطلاب هذا