شاشة الحجز أسهل جزء في نظام المواعيد. التقويم وزر «احجز» يُبنيان في أيام، ويبدوان سليمين في العرض التقديمي. ما ينكسر يظهر بعد شهرين من التشغيل: مريضان في الغرفة نفسها الساعة الخامسة، عميل من الكويت حضر بعد ساعة من موعده، موعد أسبوعي انزاح ساعة في نهاية أبريل، وفاتورة رسائل تضاعفت بلا سبب ظاهر.

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

حجزان على الموعد نفسه

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

ولا يُغلق هذا الباب بشرط في الكود. توثيق MySQL يقولها صراحة: «الجملة SELECT العادية لا توفر حماية كافية… يمكن لمعاملات أخرى أن تُحدِّث أو تحذف الصفوف نفسها التي قرأتها للتو». الحل عنده قراءة قافلة، أي جملة SELECT … FOR UPDATE التي تقفل الصفوف وفهارسها كأنك حدّثتها، فتنتظر المعاملة الثانية حتى تنتهي الأولى وترى النتيجة الصحيحة.

وإذا كان نظامك على PostgreSQL فأمامك أداة أدق: قيد الاستبعاد. توثيق PostgreSQL نفسه يضرب المثال بحجز غرفة اجتماعات: جدول فيه عمود للغرفة وعمود من نوع «فترة زمنية»، وعليه قيد يمنع أن تتساوى الغرفة وتتداخل الفترتان (بعد تفعيل امتداد btree_gist الذي يسمح بضم عمود عادي إلى القيد). أي سطر ثانٍ يحمل الغرفة نفسها وفترة متداخلة يُرفض من قاعدة البيانات برسالة خطأ واضحة تقول إن القيمة تتعارض مع قيد الاستبعاد. القاعدة محفورة في الجدول لا في الكود، فلا يخترقها استيراد من ملف ولا شاشة إدارية نسي أحد أن يضيف التحقق فيها، ولا تسجيل يدوي من موظف الاستقبال في اللحظة نفسها. وإضافة القيد تُنشئ الفهرس اللازم تلقائيًا، فلا تدفع ثمنًا إضافيًا في البحث.

لمن يعمل على MySQL وليس عنده أنواع الفترات: النمط العملي أن تُخزَّن المواعيد على شبكة ثابتة (كل موعد ربع ساعة مثلًا) مع فهرس فريد على «المورد + وقت البداية». الشبكة الثابتة تفقدك المرونة في الخدمات ذات المدد المختلفة، لكنها تحوّل منع التعارض إلى قاعدة تفرضها قاعدة البيانات لا التطبيق.

يبقى باب ثالث: العميل الذي يضغط «تأكيد» مرتين، أو يفقد الشبكة فيعيد إرسال الطلب. هنا يُستخدم مفتاح idempotency، وهو معرّف فريد يولّده العميل مع الطلب، فيحفظ الخادم نتيجة أول طلب بهذا المفتاح ويعيدها لأي محاولة تالية بدل تنفيذ العملية مرة ثانية. توثيق Stripe يقترح UUID من النسخة الرابعة وينبه إلى ألا يحمل المفتاح بيانات شخصية.

اختبار القبول لهذا البند بسيط: أرسل طلبين متزامنين على الموعد نفسه، واشترط أن ينجح واحد بالضبط وأن يتلقى الثاني رسالة مفهومة لا خطأ خام من قاعدة البيانات.

المورد الواحد نادرًا ما يكون واحدًا

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

المعالجة أن يرتبط الحجز بقائمة موارد لا بمورد واحد، وأن يُطبَّق قيد عدم التداخل على كل مورد على حدة. ويستتبع ذلك قاعدة ثانية يسهل نسيانها: إلغاء الحجز يجب أن يحرر الموارد كلها، وتأجيله يجب أن يتحقق من توافرها كلها في الموعد الجديد قبل أن يثبّته.

التوقيت: ما يُخزَّن غير ما يُعرض

القاعدة التي لا خلاف عليها: خزّن اللحظة بتوقيت UTC، واعرضها بتوقيت من ينظر إليها. عميل يحجز من لندن يرى موعده بتوقيت لندن، وموظف الاستقبال في جدة يرى الموعد نفسه بتوقيت جدة، والقيمة في قاعدة البيانات واحدة.

وهنا تفصيلة تُغفل: نوع timestamp with time zone في PostgreSQL يُخزَّن داخليًا بـUTC ولا يحتفظ بالمنطقة الزمنية الأصلية. إذا احتجت لاحقًا أن تعرف أن هذا الموعد حُجز بتوقيت الرياض، فاحتفظ بمعرّف المنطقة في عمود مستقل. واحرص أن يكون المعرّف اسمًا كاملًا مثل Asia/Riyadh لا اختصارًا، لأن التوثيق نفسه يفرّق بينهما: الاختصار يعني إزاحة ثابتة عن UTC، بينما الاسم الكامل يحمل معه قواعد التوقيت الصيفي.

مصر والخليج لا يتحركان معًا

قاعدة بيانات المناطق الزمنية التي تعتمدها كل الأنظمة تقريبًا (قاعدة IANA) تسجل لمصر قاعدتين سارتين منذ 2023 إلى أجل غير مسمى: يبدأ التوقيت الصيفي آخر جمعة من أبريل عند منتصف الليل، وينتهي في تمام الساعة 24:00 من آخر خميس في أكتوبر. في مقابل ذلك، تسجَّل الرياض والدوحة ودبي بإزاحة ثابتة بلا أي قاعدة توقيت صيفي.

النتيجة العملية لمن يدير فرعين في القاهرة والرياض: الفارق بينهما ليس ثابتًا. القاهرة UTC+2 والرياض UTC+3 معظم العام، فإذا دخل التوقيت الصيفي المصري صار الفرعان على الساعة نفسها. في 2026 تقع الحدود يومي 24 أبريل و29 أكتوبر. أي تقرير أو مزامنة أو حساب «قبل الموعد بيوم» يفترض فارقًا ثابتًا سيخطئ في كل هذه الفترة.

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

الموعد المتكرر لا يُخزَّن كلحظة

جلسة علاج طبيعي كل ثلاثاء الساعة الخامسة مساءً ليست «لحظة UTC + 7 أيام». إذا خزّنتها هكذا، فستصير الجلسة الرابعة عند الساعة الرابعة أو السادسة بحسب موعدها من تحول التوقيت. المعيار RFC 5545 ينص على أن بداية السلسلة «ينبغي أن تُحدَّد كتاريخ بتوقيت محلي مع مرجع لمنطقة زمنية، لضمان أن تبدأ كل مرات التكرار في التوقيت المحلي نفسه بصرف النظر عن تغيرات المنطقة الزمنية».

بعبارة أخرى: خزّن «الثلاثاء 17:00 بتوقيت Africa/Cairo» واحسب اللحظات منها، لا العكس.

التقويم الهجري: خمسة تقاويم لا واحد

«أضف التقويم الهجري» تبدو مهمة يوم. المشكلة أن الهجري في البرمجيات ليس تقويمًا واحدًا. سجل Unicode للتقاويم، وهو المرجع الذي تبني عليه أنظمة التشغيل ومكتبات التواريخ، يعرّف خمسة معرّفات: islamic، وislamic-umalqura وهو تقويم أم القرى، وislamic-tbla وislamic-civil وهما حسابيان بجدول ثابت يختلفان في مبدأ التاريخ، وislamic-rgsa الموصوف بأنه رؤية السعودية. اختيار معرّف عن آخر يزحزح التاريخ المعروض يومًا كاملًا، وهو فرق يكفي ليشتكي عميل من أن موعده «مكتوب غلط».

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

بداية رمضان وعيد الفطر قرار يُعلن، لا ناتج معادلة. في إعلان المحكمة العليا السعودية المنشور عبر وكالة الأنباء السعودية في مارس 2026، جاء أن قرار المحكمة رقم 204/هـ وتاريخ 29/8/1447هـ هو الذي حدّد غرة رمضان، وأن هلال شوال يُتحرى مساء اليوم التاسع والعشرين من رمضان. أي أن تاريخ العيد بالميلادي لا يُعرف على وجه اليقين قبل يوم واحد منه.

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

ورمضان يفرض تغييرًا آخر في السعودية: المادة 98 من نظام العمل تقضي بتخفيض ساعات العمل الفعلية للمسلمين في رمضان إلى ما لا يتجاوز ست ساعات يوميًا أو ست وثلاثين أسبوعيًا. يعني ذلك أن «جدول العمل الأسبوعي» في نظامك لا يصلح ثابتًا واحدًا؛ يحتاج إلى نسخ لها فترات سريان، ونسخة رمضان واحدة منها. والمنشأة نفسها في مصر تتبع جدولًا مختلفًا في الشهر نفسه.

الإلغاء والتأجيل وعدم الحضور

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

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

أما نافذة الإلغاء المسموح بها فتُطبَّق على الخادم لا في الواجهة وحدها. زر «إلغاء» مخفي في الشاشة لا يمنع طلبًا مباشرًا إلى الواجهة البرمجية.

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

التصدير إلى تقويم العميل

هل تخطط لبناء أو تطوير مشروع رقمي؟

فريق سنابل يوفر لك دراسة فنية مخصصة لتحديد التقنيات المناسبة وتكلفة التنفيذ الدقيقة.

تواصل عبر واتساباستكشف خدماتنا

«أضف إلى تقويمي» ميزة صغيرة تفشل بصمت. الملف المصدَّر يتبع معيار iCalendar، وثلاث خصائص فيه تحسم سلامة المزامنة:

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

والإلغاء له مساره الخاص. معيار الجدولة المرافق (RFC 5546) يشترط إرسال رسالة بطريقة CANCEL تحمل المعرّف UID نفسه، وأن تُزاد قيمة SEQUENCE، وأن تُحدَّد خاصية RECURRENCE-ID إذا كان الملغى موعدًا واحدًا من سلسلة. بغير ذلك يظل الموعد الملغى في تقويم العميل، ويحضر.

التذكيرات: العدّاد الذي يبدأ في 1 أكتوبر 2026

التذكير عبر واتساب بند يُطلب في كل نظام حجز تقريبًا، وبنود تكلفته أكثر ما يُساء فهمه في العروض.

الأساس أن الرسالة التي تخرج من نظامك إلى عميل لم يراسلك في الأربع والعشرين ساعة الأخيرة يجب أن تكون قالبًا معتمدًا، وهذه هي حالة أي تذكير بموعد الغد تقريبًا. القالب من فئة utility، وMeta تحاسب عليه لأنه مرسل خارج نافذة خدمة العملاء. هذا لم يتغير.

ما يتغير في 1 أكتوبر 2026 ثلاثة بنود، وقد راجعنا نص التوثيق الرسمي (المحدَّث في 10 سبتمبر 2026) بتاريخ 21 سبتمبر 2026:

  • رسائل الخدمة تصبح محاسَبة لكل رسالة، بسعر يساوي سعر قوالب utility وauthentication في السوق نفسه. رسالة الخدمة هي أي رد غير قالبي يرسله نظامك داخل نافذة الأربع والعشرين ساعة، والنافذة تفتح وتتجدد مع كل رسالة من العميل.
  • يقابل ذلك حد مجاني شهري قدره 1,000 رسالة خدمة مُسلَّمة لكل رقم أعمال، يتقاسمه الإرسال الفردي والجماعي، ولا يُرحَّل ما لا تستهلكه منه إلى الشهر التالي.
  • قوالب utility المرسلة داخل نافذة الأربع والعشرين ساعة تصبح محاسَبة بعد أن كانت معفاة منذ 1 يوليو 2025.

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

السعر يتحدد برمز دولة رقم المستلم لا بدولة منشأتك. من بطاقة الأسعار المنشورة من Meta، السارية من 1 أكتوبر 2026 بالدولار الأمريكي لكل رسالة مُسلَّمة:

السوققالب utility ورسالة الخدمةقالب تسويقي
مصر0.00360.0644
السعودية0.01070.0576
الإمارات0.01570.0576
قطر0.01200.0341

الخلاصة الحسابية لعيادة متوسطة أهدأ مما يُتوقع. مثال افتراضي: عيادة في مصر بستمائة موعد شهريًا، ترسل قالب تأكيد عند الحجز وقالب تذكير قبل الموعد بيوم. الناتج 1,200 قالب utility، وبسعر مصر في بطاقة أسعار Meta يساوي نحو 4.3 دولار شهريًا. وردود العملاء («تأكيد» أو «تأجيل») تفتح رسائل خدمة تبقى في الغالب تحت الحد المجاني.

الفاتورة تكبر من مكان آخر: الرسالة التسويقية. «اشتقنا لك، احجز الآن» إلى القائمة نفسها تُصنَّف قالبًا تسويقيًا، وسعره في مصر نحو ثمانية عشر ضعف سعر التذكير. والفرق ليس ماليًا فقط: القانون المصري 151 لسنة 2020.pdf) يشترط للتسويق الإلكتروني موافقة مسبقة وآلية إيقاف واضحة، ويلزم بالاحتفاظ بسجلات إلكترونية تثبت الموافقة لمدة ثلاث سنوات من تاريخ آخر إرسال (المادتان 17 و18). والنظام السعودي يشترط الموافقة وآلية الإيقاف في مادته الخامسة والعشرين.

عمليًا: افصل في قاعدة البيانات بين موافقة تلقّي التذكيرات وموافقة تلقّي العروض، وخزّن مع كل موافقة نص ما وافق عليه العميل وتاريخه. ولتفاصيل القوالب وفئاتها راجع شات بوت واتساب لمتجرك، ولبطاقة الأسعار الكاملة بكل الأسواق والعملات راجع تكلفة شات بوت الذكاء الاصطناعي.

حقل واحد يغيّر تصنيف نظامك

«سبب الزيارة» أو «التخصص المطلوب» حقل يضيفه المصمم في دقيقة. في مصر ينقل هذا الحقل نظامك من معالجة بيانات شخصية عادية إلى معالجة بيانات حساسة.

تعرّف المادة الأولى من القانون 151 لسنة 2020 البيانات الشخصية الحساسة بأنها «البيانات التي تفصح عن الصحة النفسية أو العقلية أو البدنية أو الجينية»، ومعها بيانات القياسات الحيوية والبيانات المالية، وتنص على أن بيانات الأطفال تُعد حساسة في جميع الأحوال. وتحظر المادة 12 على المتحكم أو المعالج جمع البيانات الحساسة أو نقلها أو تخزينها أو معالجتها أو إتاحتها «إلا بترخيص من المركز»، وتوجب فوق ذلك موافقة كتابية صريحة من صاحب البيانات، وموافقة ولي الأمر إذا تعلق الأمر ببيانات طفل. وعقوبة المخالفة في المادة 41 حبس لا يقل عن ثلاثة أشهر وغرامة من خمسمائة ألف إلى خمسة ملايين جنيه، أو إحدى العقوبتين.

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

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

العربون: نافذة زمنية لا تظهر في العرض

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

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

أي أن العربون المحجوز لا يصلح لموعد بعد ثلاثة أسابيع. إما أن تخصم، أو أن تضع سياسة حجز مختلفة للمواعيد البعيدة.

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

وبند أخير يسقط كثيرًا: إشعار الدفع (webhook) قد يصل مرتين، أو يصل بعد أن يكون العميل قد أغلق الصفحة. عالج الإشعار بمعرّف عملية فريد بحيث لا يُنشئ حجزًا مكررًا ولا يخصم مرتين، واجعل الحجز يُثبَّت من الإشعار لا من عودة المتصفح.

متى تكفي أداة جاهزة

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

ويصبح البناء مبررًا حين يتحقق أحد هذه الشروط: الموعد الواحد يحتاج عدة موارد حرة في اللحظة نفسها؛ أو الفروع في دول مختلفة بتوقيتات وعطلات مختلفة؛ أو الحجز يجب أن يحرّك مخزونًا أو يصدر فاتورة أو يفتح ملفًا في نظام آخر؛ أو البيانات المجموعة حساسة فتترتب عليها التزامات لا تستطيع الأداة الجاهزة أن تفي بها نيابة عنك؛ أو قواعد العمل تتغير كل بضعة أشهر.

للمفاضلة العامة بين الشراء والبناء راجع أنظمة جاهزة أم مخصّصة لإدارة الأعمال، ولربط الحجز بالبيع والفاتورة راجع نظام نقاط البيع POS.

خمسة أسئلة قبل أن توقّع على عرض

اطرحها على من سيبني النظام، واطلب إجابة محددة لا وعدًا:

  1. كيف يُمنع الحجز المزدوج؟ الإجابة المقبولة تذكر قيدًا أو قفلًا في قاعدة البيانات، لا «تحقق في النظام».
  2. أين تُخزَّن المواعيد، وكيف تُعرض لعميل خارج البلد؟
  3. من يعدّل جدول العطلات ومواعيد رمضان، وهل يحتاج مبرمجًا؟
  4. ما حالات الموعد المدعومة، وهل يظهر «لم يحضر» في تاريخ العميل؟
  5. من يملك حساب واتساب للأعمال، ومن يدفع فاتورة Meta، ومتى تُرسل الرسالة كقالب تسويقي؟

المصادر

اطُّلع على جميع المصادر في 21 سبتمبر 2026.

إذا ظهرت إحدى هذه الحالات في نظامك العامل، أو كنت تخطط لبناء نظام من الصفر، فاكتب إلى فريق سنابل من صفحة الأنظمة البرمجية المخصصة، واذكر ما يحجزه عملاؤك وعدد الفروع والموارد التي يشغلها الموعد الواحد. يصلك خلال يوم عمل واحد تصوّر مبدئي للنظام مع تقدير للمدة والتكلفة، بلا رسوم ولا التزام.

أسئلة متكررة

هل يمكن الاعتماد على الرسائل القصيرة بدل واتساب في التذكير؟

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

هل أعرض التقويم الهجري وحده في شاشة الحجز؟

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

نظام حجز صالون لا يسجل أي بيانات صحية، هل تنطبق عليه قيود البيانات الحساسة؟

شرط الترخيص في المادة 12 من القانون المصري 151 لسنة 2020 مرتبط بالبيانات الحساسة تحديدًا، ومنها البيانات الصحية. الاسم ورقم الهاتف وموعد الجلسة بيانات شخصية عادية لا حساسة. لكن الالتزامات العامة للقانون تظل قائمة: الموافقة، ومدة الاحتفاظ، والرد على طلبات أصحاب البيانات، والإشعار عند التسرب. وانتبه إلى أن بعض الخدمات التجميلية تستدعي تسجيل حالة جلدية أو حساسية، وعندها يتغير التصنيف.