AI לניהול הכנסות: תחזית ביקוש ואופטימיזציית מחירים למלונות

התפוסה וההכנסות של מלון תלויות במידת הדיוק של המחיר לכל תאריך. אנו מפתחים AI לניהול הכנסות מקצה לקצה: חוזים ביקוש, מגדירים תעריפים דינמיים וכללים שנשארים אצל הצוות שלכם. ניהול המחירים מפסיק להיות תלוי באינטואיציה — ההחלטות מתקבלות לפי נתונים.

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1359
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

AI revenue management: איפה המלון מפסיד הכנסות

ברוב המלונות רשת התעריפים חיה בטבלה ומתעדכנת פעם בשבוע, לעיתים רחוקות יותר. ההחלטה מתקבלת לפי מספרי השנה שעברה והתפוסה של היום, בלי התחשבות בקצב ההזמנות, באירועים מקומיים ובהתנהגות המתחרים. עד שהמנהל רואה את הבעיה, הקטגוריות הזולות כבר נמכרו, והיקרות עומדות ריקות.

מכאן גם אובדן ההכנסה לחדר: המלון או מוכר הרבה, אבל במחיר נמוך מדי, או מחזיק תעריף גבוה במקום שאין בו ביקוש. ניהול תעריפים ידני אינו מצליח פיזית לעמוד בקצב השוק — הביקוש משתנה מדי יום, ואילו הרשת נבחנת מחדש לפי נהלים.

התפוסה בעונה הנמוכה צונחת מאותה סיבה: הורדת המחיר מופעלת באיחור, כשחלון ההזמנות כבר נסגר. את תחזית הביקוש בונה המלון לפי מספר אחד מהשנה שעברה, בעוד שעל התוצאה משפיעים עשרות גורמים — יום בשבוע, חופשות בית ספר, טיסות שבוטלו, כנסים בעיר.

AI revenue management משנה את ההיגיון עצמו: המודל מחשב ביקוש לכל יום, סגמנט וערוץ, מתחשב בקצב ההזמנות, ברגישות האורח למחיר, במגבלות על אורך השהות ובחוקי סגירת המכירות. התעריף מחושב מחדש לא לפי לוח זמנים, אלא על כל שינוי בנתונים — בבוקר, לקראת הערב ולפני השקת מבצע.

התוצאה — פחות חדרים ריקים בתאריכים חלשים ומחיר ממוצע גבוה יותר בחזקים, עם אותו כוח אדם. נפרק כיצד זה נסגר: מהתחזית והחוקים ועד לשליטה בתוצאה.

תחזית ביקוש ותעריפים דינמיים: אפקט מדיד

לפני ההטמעה תחזית התפוסה של המלון חיה בטבלה ומתעדכנת פעם ביממה: אופק התכנון — 2–3 ימים, התעריף משתנה ידנית, וזינוק בביקוש נראה רק בדיעבד. לאחר ההפעלה האופק מתרחב לכמה שבועות, והאוטומציה של התעריפים מכסה 60–80% משינויי המחיר — המנהל מתערב רק בקבוצות ובחריגות.

תחזית תפוסה לכמה שבועות קדימה

המודל מחשב תפוסה לכל תאריך הגעה לפי קטגוריית חדר, ערוץ ואורך שהות. בקלט — היסטוריית הזמנות וביטולים, קצב ההזמנות הנוכחי, לוח אירועים ומגבלות מלאי.

השגיאה הממוצעת באופק של שבועיים נשמרת בטווח של 8–12%, ובתאריכים חמים התחזית מחושבת מחדש כל כמה שעות — הזינוק נראה עוד לפני שהוא הופך למחסור בחדרים.

חישוב מחדש של תעריפים לפי סגמנטים של הזמנות

לכל סגמנט הזמנות — ישיר, סוכנויות, תאגידי, קבוצתי — מוגדרות מסגרות משלו: תעריף מינימלי, צעד ותדירות השינוי, ואיסור על חישוב מחדש לאחר סף תפוסה. תמחור דינמי פועל יחד עם מגבילים, ולכן המחיר לא צונח בתאריכים עם ביקוש גבוה ולא מרחיק הזמנות מוקדמות.

כל שינוי תעריף נכנס ליומן: מי יזם אותו — המודל או המנהל — ועל איזו תחזית הוא מבוסס. אנחנו מחברים את המודל למערכת ניהול ההכנסות (IDeaS) או ישירות למערכת ההזמנות שלכם, כך שהחישוב מחדש מתבצע על נתונים שהמלון כבר משתמש בהם.

דרכים לאופטימיזציית מחירים: השוואת מצבי עבודה

אין מצב עבודה אחד נכון לאופטימיזציית מחירים: הבחירה תלויה בבשלות הנתונים, במספר הסגמנטים ובנכונות למסור את פרסום התעריפים לאלגוריתם. להלן ארבע אפשרויות, שביניהן בוחרים בדרך כלל.

אפשרות מתי מתאימה מגבלות
חוקי תעריפים ידניים מלאי של עד 30–40 חדרים, סגמנט אחד או שניים, אין היסטוריית הזמנות המחיר מגיב באיחור של 2–3 יממות, בתאריכי שיא הולך לאיבוד חלק מההכנסה
חצי-אוטומטי: תחזית ואישור קיימת היסטוריה של עונות קודמות, אך החלטות מאושרות בידי האחראי על התעריפים מומחה אחד מחזיק 20–30 נכסים, ומעבר לכך האישורים מתעכבים
תחזית ביקוש מלאה כמה ערוצי מכירה, זרימת הזמנות סדירה, יש בעל מדדים רגיש לנתונים: פערים בהיסטוריה וחריגות חד-פעמיות מרחיבים את הפיזור
היברידי עם מגבלות לפי סגמנטים רשת נכסים עם רווחיות שונה וחוזים תאגידיים נדרשים חוקי תעריפים מתועדים והפרדת סמכויות בין המרכז לנכס

חוקים ומגבלות של המודלים

חוקי התעריפים פועלים כגבולות: מחיר מינימלי ומקסימלי, צעד שינוי ליממה, איסור הורדה כשהתפוסה מעל הסף, ותאריכים סגורים. המודל חופשי בתוך המסדרון ואינו יוצא ממנו — המחיר לא יורד מתחת לעלות ולא מזנק בתאריך עם ביקוש חריג.

מצב היברידי לרשתות מלונות

ברשת התחזית מחושבת לכל הנכסים בבת אחת, והחוקים עוברים בירושה לכל מלון עם זכות לדריסה מקומית — למשל, עבור חוזים תאגידיים ושהות ממושכת. המרכז רואה תמונה כוללת ומשווה בין הנכסים, הנכס מנהל את הסגמנטים שלו בגבולות שהוגדרו, ולכן הגודל לא שובר את השליטה.

הטמעה בשלבים: מביקורת נתונים ועד מסירת המודל

סדר השלבים קבוע, משום שהמודל לומד מההיסטוריה: אם בנתונים נשארים כפילויות של הזמנות, ביטולים ותיקוני תעריפים ידניים, הוא ישחזר את העיוותים הללו ויפיק גרפים יפים בלי משמעות ניהולית.

ביקורת היסטוריית ההזמנות

  1. ביקורת נתוני המלון: מעריכים את עומק ההיסטוריה, את שלמות התפוסה לפי סגמנטים וערוצים, מאתרים שפל עונתי; מנקים כפילויות, ביטולים, בלוקים קבוצתיים ותיקוני מחיר ידניים.
  2. תרשים אינטגרציות: מתארים את הקשרים עם מערכת ניהול מלאי החדרים, מנהל הערוצים ומודול התעריפים — אילו נתונים ובאיזו תדירות נכנסים למודל ומה חוזר בחזרה.
  3. הרכבת התחזית: בונים מודל ביקוש לפי סגמנטים, ערוצים, עומק ההזמנה ואירועים בעיר, מגדירים את האופק ואת רזולוציית החישוב.

בדיקת התחזית על תקופות סגורות

  • בדיקת התחזית: מריצים את המודל על תקופות סגורות ומשווים לנתוני אמת של תפוסה ומחיר ממוצע — בנפרד בשיאים ובנפרד בעונה הנמוכה.
  • חוקי תמחור: מחברים את התחזית למגבלות המלון — גבול מחיר תחתון, אורך שהות מינימלי, עצירת מכירות בתאריכים סגורים.
  • הכשרת הצוות: מסבירים כיצד לקרוא את התחזית, אילו חריגות נחשבות לאות, וכיצד תיקון ידני משפיע על החישובים הבאים.
  • מסירת המודל: מוסרים את הסביבה, את נוהל האימון מחדש, את ניטור המדדים ואת התיעוד — מחלקת ההכנסות מנהלת את המערכת בעצמה.

מה נשאר בידי המלון: תצורות, חוקים, נהלים

תחזית ואופטימיזציית מחירים אינן חיות בדוחות, אלא בחוקים שלפיהם המערכת מקבלת החלטות בכל יממה. את החוקים הללו אנחנו מוסרים בצורה קריאה — כדי שאנליסט המלון ישנה את הגבולות בעצמו, בלי להמתין למפתח.

הגדרות של חוקים ומדיניות גישה

  • תצורת חוקים: גבולות מחיר לכל סוג חדר וסגמנט, צעד השינוי, מגבלת סטייה יומית.
  • התנהגות בביקוש נמוך ובעומס יתר: מה המערכת עושה אוטומטית ומה מוציאה לאישור.
  • מדיניות גישה: תפקידי אנליסט, מנהל מחלקת מכירות וצופה, ומטריצת אישור לתיקונים ידניים.
  • ניהול גרסאות של התצורה: כל שינוי נשמר כתמונת מצב, וחזרה לסט הקודם — בפעולה אחת.
  • יומן פעולות: מי, מתי ואיזה גבול של חוק הזיז, עם קישור לתאריך שהות מסוים.

נוהל עבודה יומי עם תעריפים

  • תיעוד התחזית: מהיכן מגיעים הנתונים, מה משמעות כל מדד, כיצד לקרוא את רווח התחזית ולא רק את הנקודה.
  • נוהל עדכון תעריפים: חלון בדיקת החריגות בבוקר וסדר אישור התיקונים הידניים.
  • ניטור פערים: הספים שבהם מגיע אות על הפער בין המצב בפועל לתחזית.
  • תוכנית מסירה לתפעול: הכשרת המשמרת, הרצות ביקורת וקריטריונים שלפיהם אתם מאשרים את המערכת.

כמה שבועות לאחר ההפעלה, את הכיול מוביל הצוות שלכם, ואנחנו מתחברים לשינויי הלוגיקה.

מקרה בוחן: תחזית ביקוש מבוססת AI ברשת מלונות כפריים

מה היה לפני ההטמעה

התעריפים ברשת מלונות כפריים הועברו סקירה ידנית: המנהל הוציא פעם בשבוע נתונים מערוצי המכירה, כולל Booking.com, הצליב אותם עם התפוסה של השנה שעברה והפיץ מחירים חדשים.

המחזור ארך שניים-שלושה ימים, ולכן העונה הנמוכה נפתחה עם הנחות «על כל מלאי החדרים» — התפוסה בכל זאת לא השלימה, והעלות הממוצעת של השהות ירדה ולא התאוששה עד סוף העונה.

מדד לפני ההטמעה אחרי
תפוסה בעונה הנמוכה 41% 63%
שיעור תיקוני תעריפים ידניים כ-80% 12%
שיעור ההזמנות שבוטלו 18% 9%
סטיית התחזית מהמצב בפועל 12–14% 4–5%
תדירות בחינת המחירים מחדש פעם בשבוע מדי יום

התוצאה לפי עונות

התחזית נבנית לכמה שבועות קדימה בנפרד לכל סוג אירוח, ולכן העונה הגבוהה הפסיקה להיפתח עם הנחות: המחירים עלו לפני תאריכי השיא ולא אחריהם. בעונה הנמוכה המערכת מחפשת ביקוש באופן ממוקד — שהיות קצרות, אירועים מקומיים, אורחים חוזרים — במקום הורדה גורפת של התעריף בכל החדרים.

הביטולים פחתו בחצי, משום שתנאי ההזמנה הפכו לחלק מהחישוב: במקום שבו הביקוש יציב, חלון הביטול קצר, ובמקום שבו התחזית מעורערת — גמיש. תיקונים ידניים נותרו רק לקבוצות ולבקשות תאגידיות, שבהן את ההחלטה על המחיר מקבל בכל מקרה המנהל.

במה תמחור דינמי שונה מתעריפים עונתיים

רשת תעריפים עונתית היא לוח שנה שנבנה מראש: עונה גבוהה ונמוכה, חגים, מחירים קבועים לפי סוגי חדרים ומשך השהות. היא צפויה למחלקת ההזמנות ומובנת לאורחים קבועים, אבל אינה מגיבה למה שקורה בשוק היום.

הפער העיקרי מתגלה בזינוק בביקוש. כשקונצרט או תערוכה ענפית מעלים בחדות את העניין בעיר, הרשת העונתית ממשיכה למכור קטגוריות זולות במחיר של העונה הנמוכה — עד שהמנהל יעלה ידנית את הרמות ויסגור את הזולות. עד לרגע הזה מלאי החדרים כבר נמכר, וההכנסה שהוחמצה אינה חוזרת.

תעריפים דינמיים מחשבים את המחיר מהמצב הנוכחי: עומק ההזמנות, יתרת מלאי החדרים, תנועת המחירים בשוק ואירועים בעיר. החישוב מחדש מתבצע כמה פעמים ביום, ולצד המחיר משתנות גם המגבלות — משך שהות מינימלי, סגירת הגעה. לכן זינוק בביקוש משתקף במחיר באותו יום, ולא כעבור שבוע.

אם במלון כבר הוטמעה רשת תעריפים משלו, אין צורך לשבור אותה.

הרשת נשארת שכבת בסיס ומקור מחירים עבור Opera וערוצי המכירה, ואילו התחזית והחוקים מונחים מעל: המערכת מציעה מחיר חדש או מפרסמת אותו בעצמה, אתם מגדירים גבולות שהיא לא יורדת מתחתם ולא עולה מעליהם, ובכל רגע מחזירים את הניהול הידני.

המסקנה מההשוואה פשוטה: הגישה העונתית מגיבה לביקוש באיחור של ימים, הדינמית — בשעות. ההכנסה גדלה לא בזכות תפוסה נוספת, אלא בזכות העובדה שאותו מלאי חדרים נמכר במחיר שהשוק מוכן לשלם עכשיו.

ספקות טכניים: נתונים, דיוק, אינטגרציות

לפני תחילת הפרויקט כמעט תמיד עולות אותן שאלות: האם היסטוריית ההזמנות תספיק, מה המודל עושה בתקופה חריגה, כיצד נמדד הדיוק והאם האינטגרציה לא תשבור את התהליכים הקיימים. להלן התשובות שנכנסות לתיעוד הטכני של הפרויקט.

יש לנו היסטוריית הזמנות קצרה והטרוגנית — האם זה יספיק?

שני מחזורים עונתיים מלאים מספיקים למודל בסיסי, ומכאן והלאה הדיוק גדל עם העומק. פערים, כפילויות, ביטולים והזמנות קבוצתיות אינם נזרקים, אלא מתויגים בתכונות בקלט — המודל לומד מתרחישי מכירה אמיתיים, כולל ביטולים מאוחרים והזזות תאריכים.

כיצד המודל מתנהג בביקוש חריג?

חריגה — אירוע גדול, סגירת מכירות, תקלה בערוץ — מזוהה בנפרד ואינה נמרחת על התחזית לתאריכים סמוכים. תיקון ידני של מנהל ההכנסות תמיד בעל עדיפות על פני ההמלצה: האוטומציה מציעה, ההחלטה נשארת בידי האדם.

כיצד אתם מודדים את דיוק התחזית?

התחזית מוצלבת עם המצב בפועל בתקופה נדחית בנפרד לפי סוגי תאריכים: ימי חול, סופי שבוע, עונה גבוהה, הזמנות ארוכות. שיעור הפגיעות במסדרון המותר נראה לפי ימים, ולכן ירידה בביצועי המודל מורגשת לפני שהיא מתחילה להשפיע על התפוסה.

האם האינטגרציה לא תשבור את המערכות שלנו?

ההחלפה מתבצעת דרך הממשקים הסטנדרטיים של מערכת הניהול ושל ערוצי המכירה, וכתיבת ההמלצות אינה חוסמת את מחלקת ההזמנות ואינה משנה את חוקי התעריפים. בתקופה הראשונה המודל פועל במצב תצפית: מחשב מחירים, אך אינו מפרסם דבר — ואת הפערים מנתחים לפני הפעלת האוטומציה.

מי אחראי לאמינות הנתונים?

אנחנו אחראים לעיבוד, לבקרת שלמות ולהגיון המודל: פערי תעריפים ופערים בייצוא מתגלים בקלט ונכנסים לדוח. שלמות הייצוא וחוקי המכירה נשארים באחריות המלון — את זה מעגנים בנוהל ההחלפה.

נדון במשימה: כיצד להכין את המלון לתחזית ביקוש

כדי שהמודל ילמד מהמצב שלכם ולא מעקומות ענפיות ממוצעות, לקראת השיחה הראשונה מספיק לאסוף את מה שכבר קיים במערכות המלון. להלן רשימה קצרה: איתה נעבור מהר יותר מדיון במשימה להערכת לוחות זמנים.

  • ייצוא הזמנות מ-2–3 עונות: תאריך ההזמנה וההגעה, תעריף, ערוץ, סטטוס ביטול. ככל שההיסטוריה ארוכה יותר, כך התחזית יציבה יותר בתאריכי שיא.
  • הלוגיקה הנוכחית של המחירים: מי ועל איזה בסיס משנה תעריפים, אילו מגבלות כבר בתוקף — שהות מינימלית, סגירת מכירות, חוקים לפי ערוצים.
  • פילוח לפי סגמנטים עם חלקים: תאגידי, קבוצתי, מכירות ישירות. לכל אחד התחזית מחושבת בנפרד, אחרת מתערבבים מודלי ביקוש שונים.
  • נתונים על המלאי הזמין תוך התחשבות בתיקונים, בחסימות ובחדרי שירות — אחרת הקיבולת במודל תהיה מופרזת.
  • מגבלות עסקיות: מחיר מינימלי מותר, תעריפים חוזיים, מדיניות לקבוצות ולשהות ממושכת.
  • הרשאות גישה למערכת הניהול ולערוצי המכירה — בשלב הכיול, כדי להריץ את התחזית על זרימה אמיתית.

הכנת הנתונים היא החלק העמוס ביותר, וכאן אנחנו לוקחים את העבודה על עצמנו: נעזור לייצא, לאחד ולבדוק את ההיסטוריה. כשהתמונה ברורה, נחזור עם תוכנית הטמעה: סדר הכנסת התחזית לעבודה, נקודות בקרת איכות והערכת לוחות זמנים לפי שלבים. תארו את המשימה — נגיע עם חישוב קונקרטי.