من تسجيل الدخول إلى الحجز في ثوانٍ: كيف بنينا منظومة حجز الوحدات على منصّة سكني (sakani.sa)

منصّة سكني هي البوابة الوطنية للسكن في المملكة العربية السعودية: مشاريع، أراضٍ، وحدات جاهزة، ودعم تمويلي — ومعها لحظات نادرة تُطرح فيها وحدات جديدة وتختفي خلال دقائق. الأسرة التي تنتظر أرضها منذ سنوات تريد شيئاً واحداً: ألّا تفوتها اللحظة. هذه قصّة SakaniBot، منظومة بنيناها في برمجيات الريادة الذكية لتراقب الوحدات وتُتمّ خطوات الحجز نيابةً عن مستخدم مصادَق عليه، من تسجيل الدخول حتى تأكيد الحجز.

المبدأ الأول: الإنسان يملك الهوية، والنظام يملك السرعة

لا يخزّن النظام كلمة مرور ولا يُقلّد هوية أحد. المستخدم يسجّل دخوله بنفسه إلى سكني من متصفّحه، ويستقبل رمز التحقق (OTP) على جواله ويُدخله بيده. ما يفعله النظام بعد ذلك هو الجزء الممل الذي لا يجيده البشر تحت الضغط: المراقبة المستمرّة، والتسلسل الدقيق للخطوات، والتنفيذ في الثانية المناسبة.

القاعدة التي التزمنا بها: كل جلسة تبدأ بإنسان يثبت هويته على المنصّة الرسمية. الأتمتة تبدأ بعد ذلك، لا قبله.

المعمارية: خمس خدمات بمهمّة واحدة

1. إضافة Chrome (الواجهة): تعمل داخل متصفّح المستخدم على sakani.sa. بعد تسجيل الدخول ورمز الجوال، تلتقط الجلسة المصادَق عليها ورمز reCAPTCHA وتُرسلهما بأمان إلى محرّك الحجز، وتعرض حالة الحجز لحظياً بواجهة يحدّدها حساب المستخدم في اللوحة.
2. محرّك الحجز (FastAPI — Python): يستقبل الجلسة، ويُدير مجمّع جلسات بمهلة صلاحية، ويُنفّذ تسلسل الحجز خطوةً خطوة مع قاطع دائرة (circuit breaker) ومُصنّف أخطاء يفرّق بين «الوحدة حُجزت لغيرك» و«انقطاع مؤقّت».
3. مراقب المشاريع (Python): يفحص المشاريع والوحدات التي اختارها المستخدم في اللوحة، ويكتشف لحظة توفّر وحدة جديدة أو عودة وحدة مُلغاة.
4. لوحة التحكّم (Laravel + Filament): المستخدمون، الاشتراكات، المشاريع المُراقَبة لكل مستخدم، قوالب الإشعارات، وتحليلات الحجوزات. تُزامن إعداداتها مع المراقب كل 60 ثانية عبر واجهة برمجية مُوقَّعة.
5. مُبلِّغ تيليجرام: يوجّه الإشعارات لكل مستخدم على قناته الخاصّة: «وحدة متاحة الآن في مشروع X»، «بدأ الحجز»، «تمّ الحجز — رقم المرجع كذا».

رحلة الحجز الكاملة، خطوةً خطوة

1) تسجيل الدخول ورمز التحقق

يفتح المستخدم سكني، يسجّل الدخول، ويُدخل رمز الجوال. الإضافة تنتظر حتى تصبح الجلسة صالحة ثم تلتقطها. لا نطلب منه شيئاً لم يكن سيفعله بنفسه.

2) التحقّق من الأهلية

قبل أي محاولة، يسأل المحرّك المنصّة: هل هذا المستخدم مؤهّل لهذا المشروع؟ المستفيد غير المؤهّل لا يُستهلك وقته ولا وقت المنصّة.

3) الشرط المسبق ورمز الحجز

حجز الوحدة في سكني ليس طلباً واحداً؛ هو تسلسل: طلب شرط مسبق، ثم انتظار رمز حجز يصدر عن المنصّة، ثم تقديم الحجز بهذا الرمز خلال نافذة زمنية قصيرة. المحرّك يُدير هذا التسلسل بمهلات دقيقة وإعادة محاولة محسوبة، ويُسجّل كل خطوة.

4) التقديم والتأكيد

عند نجاح التقديم، يُقرأ رقم المرجع ويُرسل فوراً للمستخدم على تيليجرام وإلى اللوحة. إن رُفض الطلب لأن الوحدة أُخذت، يعود المحرّك إلى وضع المراقبة تلقائياً بدل أن يفشل بصمت.

5) ما بعد الحجز

المستخدم يُكمل الإجراءات الرسمية على سكني بنفسه (المستندات، التمويل، العقد). دور النظام ينتهي عند تأكيد الحجز؛ لا نتدخّل في أي خطوة قانونية أو مالية.

ما الذي جعل الفرق فعلاً؟

• تصنيف الأخطاء: نصف «الفشل» في النسخ الأولى كان انقطاعات عابرة. حين فرّقنا بين الخطأ النهائي والمؤقّت، ارتفعت نسبة الحجوزات الناجحة بشكل ملحوظ دون أي زيادة في عدد الطلبات.
• مجمّع الجلسات: جلسة مُهيّأة مسبقاً بمهلة صلاحية تعني أن لحظة التوفّر لا تضيع في المصافحة.
• إشعار يشرح: «الوحدة 214 — مشروع كذا — 3 غرف — الحجز بدأ» أفضل من «تنبيه». المستخدم يفهم ويثق.
• بيئة اختبار وهمية: خادم يحاكي واجهة سكني لتجربة كل التسلسل دون لمس المنصّة الحقيقية — وهذا ما جعل التطوير آمناً ومسؤولاً.

الأثر

الأسر التي استخدمت المنظومة لم تعد تسهر أمام الشاشة تُحدّث الصفحة. وصلت الإشعارات في الثواني الأولى من التوفّر، وأُتمّت الحجوزات في لحظات كانت تضيع سابقاً بسبب بطء يدوي طبيعي. والأهم: كل حجز تمّ بهوية صاحبه ورمز جواله، بلا اختصارات.

لمن يفكّر في أتمتة مماثلة

1. احترم المنصّة التي تبني فوقها: مصادقة حقيقية، أهلية حقيقية، وحدود معقولة للطلبات.
2. اجعل التسلسل قابلاً للملاحظة: سجل لكل خطوة، ومؤشر لكل سبب فشل.
3. ابنِ المحاكي أولاً، ثم المحرّك.
4. الإشعار جزء من المنتج، لا إضافة.

نبني في سمارت ليد تك أنظمة حجز ومراقبة لحظية للعقار والسفر والخدمات الحكومية والخاصّة — بذات الفلسفة: الإنسان يصادق ويقرّر، والنظام يراقب ويُنفّذ في الوقت الصحيح.