מובארה פיטנס ריזורט לא מכר לילה פשוט בחדר. האורחים שלו הגיעו לשהות בריאותית מסודרת שבה לינה, ארוחות, פעילות גופנית, תכנות, שירותים ותשלומים כולם צריכים לעבוד יחד.
מובארה פיטנס ריזורט בעיר איוינס, יוטה משלב לינה עם חוויית כושר ובריאות מסודרת שיכולה להימשך מביקור קצר לתוכניות של מספר שבועות.
Booking Ninjas עבדו עם מובארה כדי לקבוע סביבה של אתר נופש מבוססת Salesforce סביב הדרך שבה השהיות הללו נמכרו ופעלו בפועל.
האתגר: חדר אחד יכול לייצג מספר סוגי מלאי
מודל הלינה של מובארה הראה במהירות מדוע הגדרה רגילה של חדר אחד, הזמנה אחת לא הספיקה.
אותו חדר פיזי יכול היה להימכר באופן פרטי לאורח אחד או להיות משותף בין מספר משתתפי תוכנית.
בתוך המערכת, חדר כמו 101 יכול היה להיות קשור למלאי כמו 101A ו-101B.
אם החדר הראשי הוזמן באופן פרטי, שני המקומות המשותפים צריכים להיות לא זמינים. אם אחד מהמקומות המשותפים הוזמן, המערכת הייתה צריכה למנוע מכירת אותו חדר שוב כמלאי פרטי.
- מלך פרטי
- מלך זוגי
- מלכה פרטית
- מלכה זוגית
- ווילה פרטית
- ווילה זוגית
- ווילה שלישית
- מלאי הורה-ילד מחובר
Booking Ninjas קונפגו את המלאי סביב הכללים האמיתיים של מובארה
Booking Ninjas עבדו עם מובארה על התנהגות זמינות הורה-ילד כך שמלאי פרטי ומשותף יכול היה להשפיע זה על זה באופן אוטומטי.
זהו דוגמה טובה לגישה הרחבה יותר ליישום: להתחיל מהאופן שבו העסק באמת מוכר את המשאב, ואז לקבוע את המערכת סביב ההיגיון הזה.
הנוכחי של Booking Ninjas ניהול הזמנות ופלטפורמת ההזמנות משתמשים באותו מודל רחב על ידי חיבור הזמנות ישירות עם מלאי, זמינות, קיבולת, תמחור וכללי פעולה.
המוצר היה חבילת בריאות, לא פשוט חדר
לינה הייתה רק חלק ממה שהאורח קונה.
שהות יכולה לאחד לינה, ארוחות, גישה לפעילות גופנית, תכנות כושר ורכיבי בריאות אחרים.
אותם רכיבים יכולים להיות בעלי טיפול מס שונה, בעוד שהמחיר הסופי יכול גם להיות תלוי בתפוסה, אורך השהות, עונה, מצב נאמנות וכללי מבצעים.
הזמנות ארוכות יותר יכולות אפילו לחצות תקופות תמחור שונות במהלך אותה שהות.
לינה פרטית או משותפת קובעת חלק מהחבילה ודרישות המלאי.
ארוחות, פעילות גופנית ותכנות בריאות מהווים חלק ממה שהאורח רוכש.
אורך, תפוסה, תאריכים, נאמנות ומבצעים יכולים לשנות כיצד מתומחרת השהות.
פיקדונות, יתרות, חשבוניות והיסטוריית תשלומים נשארים מחוברים להזמנה.
ההזמנה הסופית נושאת את הפרטים התפעוליים מאחורי חוויית האורח המלאה.
Booking Ninjas ניגשו לזה כמנהל חבילות ותמחור במקום להפחית הכל למחיר לילה אחד.
הנוכחי של ניהול תמחור תומך גם בתמחור עונתי, מבוסס לוח שנה ומבוסס כללים בתוך Salesforce.
איך מודל הפעולה של מובארה השתלב
| מובארה הייתה צריכה | הגישה של Booking Ninjas | מה ההגדרה יכולה להקל |
|---|---|---|
| מלאי חדרים פרטיים + משותפים | חוקי הזמנה וזמינות מחוברים | גרסאות פרטיות ומשותפות של אותו חדר פיזי יכולות לחסום זו את זו בצורה נכונה. |
| חבילות בריאות שונות | ניהול חבילות + תמחור | לינה, רכיבי תוכנית, תאריכים, תפוסה וכללי תמחור יכולים להישאר חלק מאותה מבנה שהות. |
| שהות ארוכה וקצרה | תמחור מבוסס כללים | תקופות תמחור שונות ואורכי שהות יכולים להתנהל מבלי להפחית כל הזמנה למחיר לילה קבוע אחד. |
| פיקדונות ויתרות | עבודות הזמנה + תשלומים | תשלומים מראש, יתרות שנותרו, חשבוניות, כרטיסים והיסטוריית תשלומים יכולים להישאר מחוברים להזמנת האורח. |
| לדעת על מוכנות החדר | מצב ניקיון | צ'ק-אאוט יכול להעביר חדר למצב ריק-מלוכלך לפני שניקיון יחזיר אותו למצב ריק-נקי וזמין. |
| למכור שירותים במהלך השהות | נקודת מכירה | שירותי ספא, אימון אישי, סחורה, טיולים ושירותים נוספים יכולים להישאר מחוברים לאורח ולהזמנה. |
| לשמור על הוצאות מראש והוצאות נוספות ברורות | מבנה תמחור + POS | חבילת הבריאות ששולמה מראש יכולה להישאר נפרדת מרכישות נוספות שנעשו לאחר ההגעה. |
ההזמנה הפכה להתחלת הפעולה של האורח
צוות מובארה היה צריך הרבה יותר מאשר אישור הזמנה.
הם היו צריכים להבין מי מגיע, מי נמצא כרגע בבית, באיזה חדר האורח נמצא, האם נותרו יתרות, מה שולם ומתי הלינה מוכנה למכירה שוב.
Booking Ninjas עבדו כדי לשמור על התהליכים הללו סביב רשומות הזמנה מבוססות Salesforce כך שההזמנה תישאר שימושית במהלך השהות.
זה הופך את ההזמנה מרשומת מכירה למשהו שהפעולה יכולה להמשיך להשתמש בו לאחר שהאורח מגיע.
זמינות תלויה גם במצב החדר התפעולי
אורח שעוזב לא אומר אוטומטית שהחדר מוכן להגעה הבאה.
מובארה הייתה צריכה שהחדר יעבור דרך רצף פשוט אך חשוב:
זה מחבר את הניקיון ישירות עם בקרת המלאי.
חדר עשוי להיות פיזית ריק אך עדיין לא צריך להתייחס אליו כמלאי שניתן למכור עד שהמצב התפעולי אומר שהוא מוכן.
זו הסיבה לכך שזמינות היא יותר שימושית כאשר היא משקפת גם הזמנות וגם את המצב האמיתי של המשאב.
חוויית הנופש נמשכה לאחר רכישת חבילת הבריאות
העסקאות של מובארה באתר גם נראו שונות מ-POS רגיל שמתמקד במסעדות.
אורחים יכלו לרכוש מסאז'ים, אימון אישי, סחורה בחנות, טיולים פרטיים, טיולים, ארוחות לקחת ושירותי בריאות או הוצאות נוספות אחרות.
Booking Ninjas עבדו לקראת חוויית POS שעוצבה סביב רכישות אלו ולא סביב זרימת עבודה כללית של מסעדה.
המטרה הרחבה הייתה לשמור על הוצאות נוספות מחוברות לאורח ולהזמנה תוך הבחנה מהחבילה ששולמה מראש.
ה-POS הנוכחי של Booking Ninjas מחבר גם עסקאות עם הזמנות, שירותים, חברויות ורשומות לקוחות בתוך Salesforce.
המערכת נבנתה באמצעות משוב תפעולי אמיתי
חלק מהותי בפרויקט מובארה היה תהליך היישום עצמו.
Booking Ninjas בדקו את הפעולה הקיימת, יצרו את הסביבה של Salesforce ועבדו דרך סשנים חוזרים של ביקורת ובדיקות עם צוות מובארה.
המשוב הזה חשף פרטים שיכולים להיות קלים לפספס ביישום אתר נופש כללי: איך תוויות חדרים משותפים צריכות להופיע, איך מלאי צריך לחסום, איך רכיבי חבילה צריכים להיות מתומחרים, איך מצב החדר צריך להשתנות ואיך חיובים בתוכנית ששולמו מראש צריכים להיות שונים מהוצאות נוספות.
היישום היה בשלב מכוון.
זרימות העבודה המרכזיות של הזמנה ו-PMS הגיעו קודם, עם תהליכים תומכים עמוקים יותר של POS, חשבונאות, דיווחים, זיכויים ותהליכים נוספים שנועדו לבוא לאחר מכן.
מה הפרויקט הדגים
מובארה בסופו של דבר עצרה את היישום הרחב יותר והמשיכה להשתמש ב-PMS הקיים שלה תוך התמקדות בעדיפויות עסקיות אחרות.
לכן, החלפת ה-PMS, החשבונאות וה-POS המלאה המתוכננת לא הושלמה.
עבודת היישום המשמעותית עדיין הראתה כיצד Booking Ninjas יכולה לדגם פעולה של אתר נופש בריאותי מורכב בצורה יוצאת דופן.
גרסאות פרטיות ומשותפות של אותה לינה יכולות להיות מדודמות מבלי לאפשר הזמנות סותרות.
מבנה ההזמנה יכול היה לקחת בחשבון את אורך השהות, תפוסה, תקופות עונתיות, חבילות, מבצעים ורכיבי תמחור שונים.
הזמנות, מצב חדרים, תשלומים, מידע על אורחים ופעילות תפעולית אחרת יכולות לשתף את אותה יסוד Salesforce.
המלאי יכול היה לשקף האם הלינה הייתה מוכנה באמת לאורח נוסף, ולא פשוט אם האורח הקודם עזב.
שירותים ורכישות נוספות יכולות להיות מעוצבות סביב האורח וההזמנה במקום להפוך לעסקאות מבודדות.
הפרויקט הראה כיצד אתר נופש בריאותי עם כללים יוצאי דופן יכול להיות מדוד מבלי להפחית אותו לתבנית מלון קונבנציונלית.
מובארה לא הייתה צריכה עוד PMS מלון גנרי
המוצר של האתר היה שונה בעיצוב.
מלאי פרטי ומשותף עבד בצורה שונה. תוכניות בריאות עיצבו את המחיר. השהות יכולה להימשך שבועות. אורחים עשו רכישות נוספות סביב התוכנית. מצב הניקיון השפיע על האם המלאי היה באמת מוכן.
PMS נוקשה יכול היה לכפות את ההבדלים הללו לעבודה סביב.
Booking Ninjas לקחו את הגישה האחרת: השתמשו ב-Salesforce כבסיס פעולה, ואז קבעו את הכללים של הזמנה, תמחור, תשלום, שירות ופעולה סביב הארגון.
עיקרון זה נשאר מרכזי עבור Booking Ninjas כיום: פעולות שונות יכולות להשתמש באותו בסיס פלטפורמה מבלי להיות חייבות לעקוב אחרי אותם כללי עסקים.
למד עוד על סוג זה של הגדרת אתר נופש
ראה כיצד הזמנות, מלאי, קיבולת, מגבלות וכללי פעולה קובעים אם משאב יכול להיות מוזמן בפועל.
איך זמינות מנוהלת →ראה כיצד הזמנות, תשלומים, שירותים ופעילויות מאושרות אחרות יכולות להישאר מחוברות סביב אותו אורח.
מה זו רשומת לקוח? →ראה כיצד Booking Ninjas מחבר הזמנות מורכבות עם תמחור, זמינות, כללי פעולה וזרימות עבודה של Salesforce.
חקור ניהול תמחור →על הסיפור הזה: Booking Ninjas השלימו עבודה משמעותית של קונפיגורציה ויישום עם מובארה פיטנס ריזורט סביב מלאי לינה פרטית ומשותפת, חבילות בריאות, תמחור מורכב, תשלומים, מצב חדרים, פעולות אורחים, דרישות POS והרחבה מדורגת. מובארה לאחר מכן עצרה את היישום הרחב יותר והמשיכה עם ה-PMS הקיים שלה, כך שדף זה אינו מציג את Booking Ninjas כ-PMS המיוצר המושלם של מובארה או טוען לתוצאות פיננסיות או תפעוליות לא מאומתות.
אתר הנופש שלך לא צריך לפשט את המוצר שלו כדי להתאים ל-PMS שלו.
ראה כיצד Booking Ninjas יכולה לחבר מלאי מורכב, חבילות, תמחורים, אורחים, תשלומים, שירותים, מצב חדרים ופעולות סביב הדרך שבה השהות שלך פועלת בפועל.
.jpeg)
.jpg)
.png)
