كل مضيف يعرض وحدته على أكثر من منصة يخشى الأمر نفسه: ضيفان، شقة واحدة، الليلة ذاتها. والتفسير المعتاد هو «المزامنة تأخرت». وهذا تقريباً ليس ما حدث.
الحجز المزدوج في نظام متصل نادراً ما يكون سببه التأخير. سببه أن شيئاً ما أعاد فتح ليلة كانت قد بِيعت بالفعل.
ما يحدث فعلاً عند وصول حجز
عندما يحجز ضيف عبر Booking.com، لا ينتظر مدير القنوات أن ينتبه نظامك ثم يُبلغ باقي المنصات بإغلاق الليلة. المنصة تُغلقها فوراً، من المصدر، كجزء من قبول الحجز نفسه.
وحين يصل الحجز إلى لوحتك تكون الليلة قد أصبحت غير متاحة في كل مكان. نظامك يُبلَّغ، لا يُستشار.
وهذا مهم، لأنه يعني أن النافذة الخطرة التي يقلق منها الجميع — الثواني بين وصول الحجز وعلم نظامك به — ليست الخطر الحقيقي. المنصة عالجتها بالفعل.
الخطر الحقيقي هو كتاباتك أنت للإتاحة
إذا كانت المنصة تُغلق الليلة عند الحجز، فكيف يحصل ضيفان على الليلة نفسها؟
لأن شيئاً ما أعاد فتحها.
الإجراء الخطر ليس استقبال حجز، بل إرسال الإتاحة. أي عملية تُرسل «هذه الغرفة لديها N وحدة متاحة في هذا التاريخ» قادرة على الكتابة فوق ليلة أغلقتها المنصة — وستفعل ذلك بثقة، لأنها تعتقد أنها تعرف الرقم الصحيح.
الأسباب المعتادة:
- تحديث إتاحة جماعي على نطاق تواريخ يتضمن ليالي مبيعة بالفعل.
- استيراد تقويم من طرف ثالث تكون صورته عن مخزونك قديمة.
- تعديلات يدوية في اللوحة، حين يضبط أحدهم الشهر على «وحدتان متاحتان» دون أن ينتبه أن إحداهما محجوزة.
- إعادة تشغيل لمهمة مزامنة سابقة تحمل أرقاماً كانت صحيحة وقت جدولتها وخاطئة وقت تنفيذها.
في كل حالة أغلقت المنصة الليلة بشكل سليم، ثم أعاد نظامك أنت فتحها. والحجز الذي يتبع ذلك ليس فشلاً في المزامنة، بل تعليمات نفّذتها المنصة.
لماذا «الوحدات المعروضة للبيع» ليست «الوحدات التي تملكها»
هذا أكثر أخطاء النمذجة شيوعاً، وهو سبب الإفراط في الحجز تحديداً في العقارات متعددة الوحدات.
إن كان لديك 3 استوديوهات متطابقة وواحد محجوز يوم الخميس، فالرقم الذي تُرسله للخميس هو 2 وليس 3. الحقل يعني الوحدات الحرة، لا الإجمالية.
أرسل 3 وتكون قد أخبرت المنصة أن هناك متسعاً لثلاثة حجوزات إضافية في ليلة لا تتسع إلا لاثنين. لا شيء معطّل؛ المنصة تبيع ما عرضتَه. ولهذا يقع الإفراط في الحجز في العقارات ذات الوحدات المتطابقة أكثر بكثير من الشقة المفردة — فالوحدة المفردة إما 1 أو 0 ويصعب الخطأ فيها، بينما المخزون متعدد الوحدات يتطلب طرح المبيع في كل إرسال.
كيف تعرف أيها أصابك
عند وقوع حجز مزدوج، السؤال ليس «هل تأخرت المزامنة» بل «ما آخر ما كتب على تلك الليلة».
- راجع ترتيب الأحداث. إن وصل الحجز الثاني بعد إرسال إتاحة يمس ذلك التاريخ، فالإرسال هو السبب.
- راجع النطاق لا التاريخ. التحديثات الجماعية تُكتب كنطاقات، والتعديل الضار غالباً استهدف ليلة أخرى وجرف هذه معه.
- ابحث عن التكرار. مهمة نُفِّذت مرتين بأرقام قديمة تبدو مطابقة لمهمة نُفِّذت مرة — إلا أن الليلة أعيد فتحها بعد إغلاقها.
- ابدأ بحساب الوحدات المتعددة. في عقار بوحدات متطابقة، افترض خطأ «الحر مقابل الإجمالي» قبل أي تفسير آخر.
ما يمنعه فعلاً
ليست مزامنة أسرع، بل حساب صحيح وكتابات أقل.
- لا تُرسل رقماً ثابتاً على نطاق. احسب كل ليلة على حدة مقابل المحجوز فيها.
- قيِّد كل إرسال بالسعة الحرة الحقيقية. يجب ألا يتجاوز الرقم المُرسل إجمالي الوحدات ناقص المحجوز في ذلك التاريخ — بقيد في النظام لا باعتماد على ذاكرة شخص.
- لا تُعِد كتابة الإتاحة بعد إشعار الحجز. المنصة أغلقت الليلة أصلاً، وأي رقم تكتبه بعدها لا يمكن إلا أن يُفسدها.
- اعتبر التعديل اليدوي للتقويم أخطر إجراء لديك. فهو يتجاوز كل الحسابات التي كان النظام سيجريها.
الجزء المخالف للحدس
معظم المضيفين بعد حادثة إفراط في الحجز يطلبون مزامنة أسرع أو أكثر تكراراً. وهذا يزيد الأمر سوءاً عادةً: كتابات أكثر تعني فرصاً أكثر للكتابة فوق ليلة أُغلقت بشكل صحيح.
الإعداد الآمن يكتب أقل، وكل كتابة مقيَّدة بما هو حر فعلاً. يفرض GateIn هذا القيد لكل ليلة بدل الوثوق بالرقم المُمرَّر إليه، ولهذا لا يستطيع تحديث جماعي على شهر كامل أن يُعيد فتح الليالي الثلاث المبيعة بداخله.