פיתוח מערכת AI להתאמה אישית של חוויית האורח במלון

התאמה אישית של חוויית האורח: היכן זה נשבר כיום

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

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

פרופיל אורח אחיד לא נבנה, כי אין מי שישווה בין הדוא״ל מההזמנה לבין הטלפון מהחשבונית של הספא, והכפילויות נשארות כפילויות.

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

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

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

מה משתנה אחרי ההטמעה: אפקט בגדלים מדידים

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

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

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

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

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

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

אפשרויות מימוש: כללים, מודל מוכן, מודל משלכם

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

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

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

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

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

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

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

מה נשאר בידי המלון: סכמות, כללים, תיעוד, תקנונים

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

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

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

מקרה בוחן: איך רשת מלונות הסירה הצעות לא רלוונטיות

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

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

מה שינו

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

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

תוצאות ההטמעה

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

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

במה שונה התאמה אישית מבוססת כללים ממודל על נתונים?

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

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

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

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

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

ספקות טכניים שאנחנו מסירים לפני ההתחלה

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

הנתונים חסרים ולא מלאים בכל מקום — מה אז?

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

איך להרחיב את הפתרון ממלון אחד לרשת?

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

מי אחראי לאיכות אחרי ההפעלה?

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

נדון במשימה: מאיפה להתחיל במלון שלכם

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

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

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

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