Bristol Adventure מוכרת טיולי הרפתקאות שלמים, ולא לילות חדרים מבודדים. הזמנה אחת יכולה לשלב שהות קבועה, מספר מטיילים, בקתות, טיסות, פעילויות, תוספות ותשלומים משותפים או נפרדים.
הגדרת הזמנה סטנדרטית לא הייתה מספיקה. מערכת ההזמנות הייתה צריכה לעקוב אחרי הדרך שבה Bristol Adventure בונה ומוכרת את הטיולים שלה.
האתגר: חבילת הרפתקה היא יותר מהזמנת חדר
Bristol Adventure מנהלת לינה בבקתות ובחדרים, אך הלינה היא רק חלק אחד מהמוצר.
הרבה טיולים עוקבים אחרי אורכי שהות קבועים. אורחים עשויים גם להזדקק לטיסות ופעילויות עם זמני קיום וקיבולת משלהם. משפחות וקבוצות גדולות עשויות להזדקק למספר חדרים תוך כדי שייכות לאותה חבילת הרפתקה.
- שהות קבועות של 3, 4 ו-7 לילות
- מלאי בקתות וחדרים
- הזמנות קבוצתיות מרובות חדרים
- טיסות עם זמני יציאה
- קיבולת מושבים בטיסות
- פעילויות ותוספות
- חשבוניות טיול משותפות
- רשומות לקוחות ב-Salesforce
שלושה זרימות עבודה מעוצבות סביב Bristol Adventure
העבודה החשובה ביותר התמקדה בשלושה חלקים מהפעולה שלא התאימו למודל הזמנת חדר בסיסי.
| צורך של Bristol Adventure | הגדרת Booking Ninjas | למה זה חשוב |
|---|---|---|
| הזמנות קבועות | כללי ההזמנה הוגדרו סביב חבילות קבועות של 3, 4 ו-7 לילות של Bristol Adventure. | זרימת ההזמנה יכולה לעקוב אחרי המוצר ש-Bristol Adventure באמת מוכרת במקום להתנהג כמו לוח שנה של מלון ללא הגבלות. |
| טיסות דרך POS | טיסות הוגדרו כמוצרים מבוססי זמן עם זמני יציאה, מלאי מושבים וקישורים חזרה להזמנה של האורח. | טיסה הופכת למלאי מנוהל בתוך הטיול במקום תוספת ידנית מנותקת. |
| חבילות הרפתקה יוקרתיות קבוצתיות | הזמנת קבוצות שימשה לשמור על מספר חדרים, מטיילים, טיסות ותוספות תחת מבנה טיול אחד. | משפחה או קבוצה יכולה להתנהל כחוויה אחת במקום אוסף של הזמנות לא קשורות. |
הזמנות קבועות לטיולים עם אורכי שהות מוגדרים
רוב השהיות של Bristol Adventure אינן הזמנות מלון פתוחות. המוצר עצמו יש לו אורך מוגדר.
אפשרויות החבילה הטיפוסיות כוללות שהות של 3 לילות, 4 לילות ו-7 לילות. Booking Ninjas הוגדר כך שחוקים אלה יוכלו להתבטא בתהליך ההזמנה.
זה חשוב כי זמינות וחוקי הזמנה צריכים להתאים למה שהחברה יכולה באמת לספק. אורחים לא צריכים להיות מסוגלים ליצור קומבינציות שנופלות מחוץ לחבילת ההרפתקה המיועדת פשוט כי חדר מופיע פתוח בלוח שנה.
טיסות הפכו למלאי מבוסס זמן דרך POS
טיסות היו מורכבות יותר מתוספת הזמנה רגילה.
לכל טיסה יכול להיות זמן יציאה ומספר מוגבל של מושבים. Bristol Adventure גם צריכה את היכולת להגיב כאשר קיבולת התפעול משתנה. לדוגמה, אם שני מטוסים מספקים 18 מושבים ואחד מהם אינו זמין, הקיבולת הניתנת למכירה עשויה להזדקק לירידה באותו יום.
Booking Ninjas השתמשה במבנה ה-POS כדי להתייחס לטיסות כמוצרים מבוססי זמן עם המלאי שלהן.
הטיסה נוצרת כשירות מבוסס זמן.
זמני יציאה זמינים יכולים להיות מוקצים.
המלאי מייצג את הקיבולת הזמינה למכירה.
הטיסה יכולה להיות מחוברת לשהיית המטייל.
ההזמנה יכולה להישאר מחוברת לרשומות החיוב של הטיול.
אותו מבנה POS יכול גם לתמוך במכירת טיסה עצמאית כאשר מטייל אינו זקוק ללינה.
למידע נוסף על הזמנות מבוססות קיבולת, ראה כיצד מנוהלת הזמינות.
חבילות הרפתקה יוקרתיות קבוצתיות נשארות יחד
טיול משפחתי או קבוצתי יכול במהרה להפוך לקשה לניהול אם כל חדר מתייחס כהזמנה לא קשורה.
Bristol Adventure עשויה להיות מארחת אחת שמארגנת טיול עבור מספר אנשים. הקבוצה עשויה לדרוש מספר חדרים או בקתות, טיסות ותוספות אחרות תוך כדי שייכות להרפתקה אחת.
Booking Ninjas הפעלו את מבנה ה-הזמנות קבוצתיות כך שמספר מקומות לינה יכולים לשבת תחת הקבוצה במקום לכפות על הצוות לבנות את הטיול חדר חדר.
הטיול הופך לנקודת החיבור
ברגע שהחלקים הללו מחוברים, Bristol Adventure לא צריכה לחשוב על לינה, טיסות וקבוצות כמערכות נפרדות.
זרימת העבודה הופכת לקלה יותר להבנה:
הלקוח נשאר מחובר לרשומת Salesforce.
שהות קבועה נכונה נבחרת.
בקתות וחדרים מוקצים לטיול.
שירותים מבוססי קיבולת יכולים להתווסף סביב השהות.
הפעילות המחוברת נשארת זמינה בתוך Salesforce.
התוצאה היא לא פשוט לוח שנה טוב יותר. זו מבנה הזמנה שיכול לייצג את המוצר המלא ש-Bristol Adventure מוכרת.
בנויה סביב סביבת Salesforce של Bristol Adventure
Bristol Adventure כבר הייתה עם Salesforce Sales Cloud במקום. Booking Ninjas עוצבה לעבוד על אותה בסיס Salesforce.
זה אומר שההזמנות יכולות להישאר מחוברות לחשבונות ולקשרים של Salesforce במקום ליצור מסד נתונים נפרד של לקוחות שהצוות צריך לשמור מסונכרן.
זה גם נותן ל-Bristol Adventure מקום להמשיך לעצב את הארגון סביב המינוח, הרשומות, זרימות העבודה, הדיווחים והדרישות העתידיות שלה.
למד עוד ב-מה זה ארגון Salesforce?
תמיכה בצד התשלומים של הטיול
Bristol Adventure גם דנה בלוח תשלומים שבו 50% נדרש בתוך שבעה ימים מהחשבונית וה-50% הנותרים נדרשים 90 יום לפני הטיול. הזמנות שנעשו בתוך חלון של 90 יום דורשות תשלום מלא.
הצוות היה בודק ידנית אילו לקוחות פיגרו.
במהלך הסקירה של Booking Ninjas, הוצגו חשבוניות, רשומות תשלום, כרטיסים על הקובץ, עיבוד תשלומים של Stripe ואוטומציה של תשלומים סביב זרימת העבודה של ההזמנה.
זה נותן לאותה מבנה טיול נתיב לתמוך בחיוב ובמעקב תשלומים מבלי להפריד את הצד הפיננסי מההזמנה עצמה.
ראה כיצד ההזמנות מחוברות לחשבוניות.
מה השתנה בהגדרת Bristol Adventure
שהות קבועות יכולות לעקוב אחרי אורכי החבילות ש-Bristol Adventure באמת מוכרת.
זמני יציאה וקיבולת מושבים יכולים להתנהל כחלק מהפעולה של ההזמנה.
מספר חדרים, מטיילים, טיסות ותוספות יכולים להישאר חלק מהרפתקה גדולה אחת.
הלינה והשירותים לא צריכים ליצור מסלולי הזמנה נפרדים שהצוות מחבר ידנית.
פעילות לקוחות והזמנות יכולות להישאר מחוברות לסביבת Salesforce ש-Bristol Adventure כבר משתמשת בה.
ההגדרה יכולה לעקוב אחרי מודל הפעולה של Bristol Adventure במקום לכפות על העסק לעקוב אחרי זרימת עבודה סטנדרטית של מלון.
קריאה קשורה
ראה כיצד ניתן לנהל מספר הזמנות ומטיילים כחלק מהזמנה גדולה יותר.
גלה את ההזמנות הקבוצתיות →ראה כיצד תאריכים, קיבולת, מלאי והגבלות הזמנה עובדים יחד.
כיצד מנוהלת הזמינות →ראה מדוע הסביבה התפעולית יכולה להיות מעוצבת סביב הרשומות והזרימות של הארגון שלך.
מה זה ארגון Salesforce? →ראה כיצד פעילות ההזמנה יכולה להישאר מחוברת לחשבוניות ולתשלומים.
כיצד ההזמנות מחוברות לחשבוניות →ההזמנות שלך לא חייבות להתאים למודל סטנדרטי
ראה כיצד Booking Ninjas יכולה לעצב הזמנות, חבילות, שירותים מבוססי קיבולת, תשלומים וזרימות קבוצתיות סביב הדרך שבה הפעולה שלך פועלת בפועל.
.jpeg)
.jpg)
.png)
