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