Quinns Hot Springs Resort

لماذا يمكن أن يصبح النظام القديم أكثر صعوبة في التعامل معه

يمكن أن تستمر أنظمة الحجز القديمة في أداء الوظيفة التي تم بناؤها من أجلها في الأصل.

تظهر الصعوبة عندما تنمو العملية حولها.

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

كانت كوينز تبحث عن تلك الخطوة التالية.

لم يكن الهدف ببساطة استبدال شاشة قديمة بأخرى جديدة. كانت الاتجاه الأكثر فائدة هو التفكير في أساس حجز يمكن أن يتكيف مع تغير المنتجع الأوسع.

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

الاتجاه: اعتبار المنتجع موارد متصلة، وليس مجرد غرف

قدمت Booking Ninjas لكوينز طريقة للنظر إلى مشكلة الحجز بشكل أوسع.

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

كيف يمكن أن تناسب Booking Ninjas منتجعًا مثل كوينز

تظهر حمامات السباحة لماذا قاعدة حجز واحدة ليست كافية

يقدم كوينز وصول الضيوف المقيمين إلى حمام السباحة وحجوزات السباحة النهارية مسبقًا.

تلك تجارب مرتبطة، لكنها لا تعمل بنفس الطريقة.

يمكن أن يحصل الضيف المقيم على الوصول لأنه يحمل بالفعل إقامة مؤهلة.

بينما يختار زائر السباحة النهارية من جلسات السباحة المحددة مع توافر وقواعد حجز منفصلة.

هذه هي بالضبط النوع من الاختلاف الذي يحتاجه نموذج التشغيل المرن لفهمه.

تم تصميم أدوات التوافر الحالية من Booking Ninjas لتطبيق حدود جدولة مختلفة، وقيود، وحدود سعة، وقواعد حجز حول موارد مختلفة.

تتبع المدفوعات أيضًا نوع الحجز

تحتوي حجوزات الإقامة في كوينز على قواعد الودائع، والأرصدة، والإلغاءات الخاصة بها.

تتبع حجوزات السباحة النهارية جدول دفع آخر.

هذا مهم في مشروع التحديث لأن منطق الدفع يجب أن يبقى مرتبطًا بما حجزه العميل بالفعل بدلاً من أن يتم التعامل معه كمعاملة غير مرتبطة.

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

يمكن للضيف التفاعل مع أكثر من جزء واحد من المنتجع

قد يقيم نفس الشخص في كوخ، ويستخدم حمامات السباحة، ويتناول الطعام في المنتجع، ويعود لاحقًا.

عندما تعيش كل حجز كمعاملة غير مرتبطة، تفقد العملية جزءًا من قصة ذلك العميل.

يوفر بيئة قائمة على Salesforce اتجاهًا آخر: الحفاظ على سجل الضيف مرتبطًا بالحجوزات والأنشطة التي تنتمي إلى ذلك الشخص.

تشرح مركز المعرفة تلك البنية في ما هو سجل العميل؟.

لا يعني ذلك أن كل تجربة في المنتجع يجب أن تُجمع في حجز واحد ضخم.

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

ما أظهرته المشاركة

ليس لدينا أدلة كافية لنقول إن Booking Ninjas استبدلت نظام كوينز القديم في الإنتاج أو قدمت نتائج قابلة للقياس بعد الإطلاق.

لذا فإن النتيجة المفيدة هي اتجاه التحديث الذي تم توضيحه خلال المشاركة.

لا ينبغي أن يصبح المنتجع أبسط ليتناسب مع النظام

يعد كوينز مثالًا مفيدًا على لماذا تكون Booking Ninjas أقوى عندما تحتاج عدة أجزاء من العملية إلى قواعد مختلفة ولكن لا تزال تنتمي إلى نفس العمل.

تختلف إقامة الكوخ عن حجز السباحة المحددة. يمكن أن يكون للضيف المقيم وصول مختلف إلى حمام السباحة مقارنة بالزائر اليومي. يمكن أن تتبع المدفوعات جداول مختلفة. ويحتوي تناول الطعام على تدفق حجز آخر مرة أخرى.

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

يمكن أن توفر Booking Ninjas الأساس القائم على Salesforce بينما يقرر المنتجع أي سير عمل يجب أن يتصل وأيها يجب أن يبقى متميزًا.

ابدأ بالحجز، ثم اربط أجزاء المنتجع التي تحتاج إلى ذلك

يمكن أن تكون نقطة البداية بسيطة: محرك الحجز وإدارة الحجز لسير العمل الأساسي للإقامة.

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

يمكن بعد ذلك إضافة سير العمل الإضافي للمنتجع فقط عندما يحل مشكلة تشغيلية حقيقية.

هذا يسمح بالتحديث حول المنتجع بدلاً من إجبار المنتجع على تغيير النظام بالكامل قبل أن يكون جاهزًا.

للحالة الأوسع، انظر إلى حل إدارة المنتجع.

تعرف على المزيد حول تحديث تدفق الحجز