שני דברים גדולים קודם, אחר כך השאר. אני מדבר בגלוי כי זה יותר מועיל לכם מאשר להיות מנומס. 1. תנו לנו לעצב את מנוע ההזמנות, או תנו לנו לבנות את שלנו מעל שלך. המנוע הוא נקודת התורפה היחידה שלנו בהמרה, ואני רואה את זה באנליטיקות שלנו: אנשים מגיעים לדף הנחיתה שלנו, קוראים על הבתים, חוקרים כמה עמודים, מזינים את התאריכים שלהם, מועברים למנוע Little Hotelier ועוזבים. שיעור היציאה שם הוא הגבוה ביותר בכל המסע, וזה נובע מכך כמה מעט אנחנו יכולים לשנות. בחירת צבעים אינה התאמה אישית. דוגמה שאנחנו נשאלים עליה כל שבוע: בית עם חדר שינה אחד מציג אייקון של אדם עם "4", כאשר האמת היא שני מבוגרים, ילד אחד ותינוק אחד. האייקון הזה מבלבל ומייצר מיילים, ואנחנו לא יכולים לערוך אותו או להסביר אותו. מה שאנחנו צריכים זה שליטה אמיתית בעיצוב, כלומר HTML מותאם אישית, CSS והזרקת קוד למנוע, או טוב יותר API הזמנות חסר ראש (חיפוש, הצעת מחיר, שמירה, הזמנה, תשלום) כדי שנוכל לבנות את הממשק שלנו שמזין ישירות ל-Little Hotelier. כרגע העיצוב בינוני מספיק כדי שמלונות כמו שלנו יחשבו לעבור למערכת אחרת כדי שהלידים שהשקענו בהם יומרו להזמנות. 2. ה-API לא מספיק. משיכת זמינות ומחירים חיים היא הגבול שלה. אין אפשרות לכתוב מחיר או הגבלה, אין webhooks כאשר הזמנה מגיעה, אין ייצוא iCal ואין מזין הזמנות, והתנאים שלכם אוסרים סריקה, כך שאין דרך מאושרת לכלים של מפעיל לפעול על החשבון. בנינו סקריפט שבודק את ה-API שלכם כל שלושים דקות כדי להציג זמינות חיה באתר שלנו, וכל שינוי מחיר עדיין חייב לעבור ידנית בממשק הווב. הצוות שלי עובד בעיקר עם AI, קלוד בפרט, וגם רוב המפעילים הקטנים עכשיו. התקדמנו במהירות על ידי בניית מערכות שמחברות את ה-PMS וה-POS שלנו, ו-Little Hotelier הוא החלק שלא ניתן לחיבור. API קריאה וכתיבה תקין, webhooks ואינטגרציה רשמית לעוזרי AI יאפשרו למפעילים כמוני לנהל את המלון ביעילות רבה יותר, וזה יהפוך אתכם לבחירה הברורה ללקוחות שאתם באמת מוכרים להם. 3. חדרים וירטואליים. מכירת כמה חדרים כיחידה אחת, או יחידה אחת ככמה, חיונית למלון כמו שלנו ו-Cloudbeds עשה זאת שנים. הופתעתי לגלות שזה חסר. 4. תכניות תעריפים סגורות מוצגות כ"Sold out". כאשר אני מפסיק למכור תכנית מוזלת בתאריכים מסוימים, האורחים רואים שהתכנית מוצגת כ"Sold out" לצד התעריף הסטנדרטי באותו בית, כך שזה נראה כאילו משהו לא זמין כאשר אין כלום. תכנית שהיא סגורה לתאריכים שנחפשו לא צריכה להופיע כלל. קשור: אין כלל ל"תכנית תעריף זו אינה חלה על שהות שנוגעת לתאריכים אלה", ולכן הכלי היחיד הוא עצירת מכירה, ערוץ אחר ערוץ. המנוע מתרגם אוטומטית את שמות הבתים שלנו. כאשר דפדפן של אורח מוגדר לתאילנדית, "White House" הופך לทำเนียบขาว, משכן הנשיא האמריקאי, "Turquoise" הופך לצבע, ואחת מהתיאורים המתורגמים שלנו מכילה קטע ביפנית בתוך משפט בתאילנדית. שמות פרטיים לעולם לא צריכים להיות מתורגמים אוטומטית, ואנחנו צריכים לבדוק או להכתיב תרגומים לפי שפה. 1. עדכוני תעריפים בהמוניהם מחליפים בשקט. התעריף האחרון שנשמר בתאריך מנצח, ולכן שמירת תעריף בסיסי בטווח מסוים מוחקת את התוספות לסוף השבוע ולחגים שכבר קיימות בתאריכים האלה. אין תצוגה מקדימה של מה שישתנה, אין ביטול ואין מעקב אחר שינויים בתעריפים. אנחנו עובדים עכשיו בסדר של שלושה סבבים קפדניים כדי להימנע מלהשמיד את התמחור שלנו, ואף מפעיל לא צריך ללמוד את זה בדרך הקשה. 2. תוויות שאין לנו שליטה עליהן. כל תעריף במנוע מציג "דרוש הפקדה של 30%" בגלל מתג בהגדרות, בין אם חיבור שער תשלום קיים או לא, ואין אפשרות לערוך או להסתיר את זה. אותו דבר כמו אייקון תפוסה: המנוע מספר לאורחים דברים שלא אמרנו. 3. אבטחה מוגזמת לאנשים שמשתמשים בה מדי יום. יציאות אוטומטיות, שינוי סיסמא כפוי כל כמה חודשים, אותו דבר באפליקציה. מכשירים אמינים, מפתחות כניסה או סשנים ארוכים יותר במכשירים מוכרים יישמרו על הביטחון בלי המתח היומי. מתסכל, אך לא יקר כמו הנקודות שלמעלה. שניים קטנים יותר. ההנחות על משך שהות ב-Airbnb אינן מנוהלות דרך מערכות ניהול הערוצים, ולכן שוויון התעריפים שם נשמר ביד. והדוחות הם ייצוא rather than תובנות: סיימנו לעשות את האנליטיקות שלנו כדי ללמוד היכן ההזמנות נופלות, וכך אנחנו יודעים שהנקודה הראשונה נכונה. תודה ששאלת. אנחנו אוהבים את המוצר, ולכן מנוע ההזמנות וה-API חשובים כל כך לנו.