شيئان كبيران أولاً، ثم البقية. أنا أكون صريحًا لأنه أكثر فائدة لك من أن أكون مهذبًا. 1. دعونا نصمم محرك الحجز، أو دعونا نبني خاصتنا فوق محرككم. المحرك هو أضعف نقطة تحويل لدينا، وأراه في تحليلاتنا: يصل الناس إلى صفحة الهبوط الخاصة بنا، يقرأون عن الفنادق، يستكشفون عدة صفحات، يدخلون تواريخهم، يُسلمون إلى نظام إدارة الحجوزات الخاص بـ Little Hotelier ويغادرون. معدل الخروج هناك هو الأعلى في الرحلة بأكملها، ويعود ذلك إلى قلة التغييرات التي يمكننا إجراؤها. اختيار الألوان ليس تخصيصًا. مثال واحد يُطلب منا كل أسبوع: فندق بغرفة نوم واحدة يظهر أيقونة شخص مع "4"، والحقيقة أن هناك شخصان بالغتان، وطفل واحد ورضيع واحد. تخلق تلك الأيقونة ارتباكًا ورسائل بريد إلكتروني، ولا يمكننا تعديلها أو شرحها. ما نحتاجه هو إما تحكم حقيقي في التصميم، بمعنى HTML مخصص، وCSS، وحقن الكود على المحرك، أو الأفضل من ذلك، واجهة برمجة تطبيقات حجز بدون رأس (بحث، عرض سعر، حجز، دفع) بحيث يمكننا بناء واجهتنا الأمامية التي تتصل مباشرة بـ Little Hotelier. حاليًا، التصميم متوسط الجودة لدرجة أنه يجعل الفنادق مثل ours تفكر في الانتقال إلى نظام آخر حتى تتحول العملاء المحتملون الذين عملنا جاهدين من أجلهم إلى حجوزات. 2. واجهة برمجة التطبيقات ليست كافية. سحب التوافر والأسعار الحية هو الحد الذي تتوقف عنده. لا توجد طريقة لكتابة سعر أو قيد، ولا webhook عند وصول حجز، ولا تصدير iCal، ولا تغذية الحجوزات، وشروطك تمنع التجريف، لذلك لا توجد طريقة مصرح بها لأدوات المشغل الخاصة للعمل على الحساب. أنشأنا سكربت يراقب واجهة برمجة التطبيقات الخاصة بك كل ثلاثين دقيقة لعرض التوافر الحي على موقعنا الإلكتروني، وكل تغيير في السعر لا يزال يتطلب النقر عبر واجهة الويب يدويًا. يعمل فريقي بشكل رئيسي عبر الذكاء الاصطناعي، خاصة Claude، وكذلك معظم المشغلين الصغار الآن. تحركنا بسرعة من خلال جعل الذكاء الاصطناعي يبني الأنظمة التي تربط PMS و POS لدينا، و Little Hotelier هو الجزء الذي لا يمكن ربطه. واجهة برمجة تطبيقات حقيقية للقراءة والكتابة، وwebhooks، وتكامل رسمي للمساعدين الذكيين، ستسمح للمشغلين مثلي بتشغيل الفندق بكفاءة أكبر، وستجعلك الاختيار الواضح للعملاء الذين تبيع لهم فعليًا. 3. الغرف الافتراضية. بيع عدة غرف كوحدة واحدة، أو وحدة واحدة كعدة، ضروري لفندق مثل ours وقد قامت Cloudbeds بذلك لسنوات. فوجئت بعدم وجوده. 4. خطط السعر المغلقة تظهر كـ "بيعت بالكامل". عندما أوقف البيع على خطة مخفضة في تواريخ معينة، يرى الضيوف أن تلك الخطة مدرجة كـ "بيعت بالكامل" بجانب السعر القياسي على نفس الفندق، لذلك يبدو أن شيئًا غير متاح عندما لا يكون كذلك. خطة مغلقة للتواريخ التي تم البحث عنها يجب ألا تظهر ببساطة. ذات صلة: لا توجد قاعدة لـ "هذه خطة السعر لا تنطبق على الإقامات التي تلامس هذه التواريخ"، لذلك الأداة الوحيدة هي إيقاف البيع، قناة بقناة. يحول محرك الحجز أسماء فنادقنا تلقائيًا. عندما يكون متصفح الضيف مضبوطًا على التايلاندية، يتحول "White House" إلى ทำเนียบขาว، مقر الرئيس الأمريكي، و"Turquoise" إلى اللون، وأحد أوصافنا المترجمة يحتوي على جزء من اليابانية في وسط جملة تايلاندية. يجب ألا تُترجم الأسماء بشكل تلقائي، ونحتاج إلى مراجعة أو تجاوز الترجمات حسب اللغة. 1. تحديثات السعر بالجملة تُكتب بصمت. آخر سعر محفوظ على تاريخ معين هو الذي يفوز، لذا فإن حفظ سعر أساسي عبر مدى يمسح التعديلات على عطلة نهاية الأسبوع والأعياد الموجودة على تلك التواريخ. لا يوجد معاينة لما سيتغير، ولا تراجع، ولا سجل تدقيق لتغييرات السعر. نعمل الآن وفق ترتيب صارم من ثلاث جولات لتجنب تدمير تسعيرنا الخاص، والذي لا ينبغي لأي مشغل أن يتعلمه بالطريقة الصعبة. 2. التسميات التي لا يمكننا التحكم فيها. كل سعر في المحرك يقول "مطلوب وديعة بنسبة 30%" بسبب تبديل إعدادات، سواء كان بوابة دفع متصلة أم لا، ولا توجد طريقة لتحريرها أو إخفائها. نفس العائلة مثل أيقونة الإشغال: يخبر المحرك الضيوف بأشياء لم نقولها. 3. الأمان مبالغ فيه للأشخاص الذين يستخدمونه يوميًا. تسجيل خروج مستمر، تغييرات كلمة المرور القسرية كل بضعة أشهر، ونفس الشيء على التطبيق. الأجهزة الموثوقة، مفاتيح المرور، أو جلسات أطول على الأجهزة المعروفة ستحتفظ بالأمان دون الاحتكاك اليومي. محبط، رغم أنه ليس مكلفًا مثل النقاط أعلاه. هناك اثنان أصغر. خصومات مدة الإقامة على Airbnb لا تُدار عبر نظام إدارة القنوات، لذا فإن تساوي الأسعار هناك يُحافظ عليه يدويًا. والتقارير تصدير بدلاً من رؤى: انتهى بنا الأمر إلى إجراء تحليلاتنا الخاصة لمعرفة أين تتوقف الحجوزات، وهكذا نعرف أن النقطة الأولى صحيحة. شكرًا لسؤالك. نحب المنتج، ولهذا السبب يهمنا جدًا محرك الحجز وواجهة برمجة التطبيقات.