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