الزبون يعرف طلبه جاهز قبل ما يوقف على الكاشير.

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

لا. يمسح رمز QR على الفاتورة، يكتب رقم الطلب، ويشوف حالته في المتصفح. ما فيه تحميل تطبيق ولا إنشاء حساب.

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

لا، ونقولها بوضوح. إشعارات المتصفح تحتاج HTTPS، ومتصفح يدعم Web Push، وموافقة الزبون. على iPhone لازم الصفحة تتضاف للشاشة الرئيسية (iOS 16.4+). لذلك المتابعة المباشرة ونداء رقم الطلب يبقون الأساس، والإشعار مجرد تحسين.

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

لصفحة الزبون: رقم الطلب، حالته، أوقات التحديث، وجلسة متصفح مؤقتة. ما نخزّنوش أسماء أو أرقام هواتف أو بيانات دفع. لطلب التجربة: بيانات تواصل المطعم فقط. الوصول للبيانات محصور في الخادم عبر مفاتيح خاصة، مع RLS.

صفحة الزبون تحاول تتحدث لحالها، والموظف عنده زر «إشعار يدوي» وبديل واضح: ينادي رقم الطلب. ما نبنوش الخدمة على افتراض أن الإشعار يصل دائمًا.

هو سعر مقترح لمرحلة التجربة، وليس عقدًا. نتفق على مدة التجربة والمؤشرات والالتزامات قبل البدء، وأي تغيير يكون مكتوبًا.