تطوير منصة NIDA لإدارة الطلبات وإشعار العملاء

طلب تطوير منصة NIDA لإدارة الطلبات وإشعار العملاء

1. نبذة عن المشروع

أرغب في تطوير منصة تقنية تجارية بنظام الاشتراكات (SaaS)، مشابهة من حيث الفكرة لمنصة Bajri، مخصصة للمطاعم والمقاهي.

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

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

2. آلية عمل النظام

الخطوة الأولى: إنشاء الطلب

عندما يقوم العميل بالطلب من الكاشير، يتم إنشاء الطلب في النظام بإحدى طريقتين:

* تلقائياً عن طريق الربط مع نظام نقاط البيع (POS)، مثل Foodics.

* يدوياً عن طريق لوحة تحكم المطعم.

الخطوة الثانية: توليد QR Code

بمجرد إنشاء الطلب، يقوم النظام بتوليد QR Code فريد ومخصص لهذا الطلب فقط.

يظهر QR على شاشة مخصصة أمام العميل عند الكاشير، أو يمكن طباعته على الفاتورة إذا كان نظام نقاط البيع يدعم ذلك.

الخطوة الثالثة: ربط العميل بالطلب

يقوم العميل بمسح QR باستخدام كاميرا هاتفه.

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

الخطوة الرابعة: متابعة حالة الطلب

تظهر حالات الطلب كالتالي:

1. تم استلام الطلب.

2. قيد التجهيز.

3. جاهز للاستلام.

4. تم الاستلام.

الخطوة الخامسة: إشعار الجاهزية

عندما يقوم الموظف بتغيير حالة الطلب إلى «جاهز للاستلام»، يجب أن يتلقى العميل تحديثاً على هاتفه.

الميزة الأساسية المطلوبة هي ظهور حالة الطلب على شاشة قفل الآيفون باستخدام Live Activities، دون تثبيت التطبيق الكامل.

يجب دراسة وتنفيذ هذه التجربة باستخدام App Clips وActivityKit وApple Push Notification service، مع الالتزام بمتطلبات Apple وقيود الأجهزة والأذونات.

أما أجهزة Android، فيتم توفير صفحة متابعة مباشرة وإشعارات Web Push على الأجهزة والمتصفحات التي تدعمها وبعد الحصول على الأذونات اللازمة.

3. لوحات التحكم المطلوبة

أ. لوحة إدارة المنصة (Super Admin)

خاصة بمالك المشروع، وتشمل:

* إضافة وإدارة المطاعم والمقاهي.

* إدارة الفروع والمستخدمين.

* إنشاء وإدارة الاشتراكات الشهرية والسنوية.

* متابعة حالة الاشتراكات والمدفوعات.

* عرض إحصائيات استخدام المنصة.

* إدارة الباقات والأسعار.

* مراقبة أداء النظام والإشعارات.

* إدارة صلاحيات المستخدمين.

ب. لوحة تحكم المطعم (Restaurant Dashboard)

خاصة بكل مطعم مشترك، وتشمل:

* عرض الطلبات الحالية.

* إنشاء طلب جديد يدوياً.

* توليد QR لكل طلب.

* تغيير حالة الطلب.

* عرض الطلبات المكتملة.

* إدارة الفروع والموظفين.

* إضافة شعار المطعم وتخصيص واجهة العميل.

* عرض التقارير والإحصائيات.

يجب فصل بيانات المطاعم بشكل آمن، بحيث لا يستطيع أي مطعم الوصول إلى بيانات مطعم آخر.

ج. واجهة العميل (Customer Interface)

واجهة بسيطة ومتوافقة مع الهواتف، تعرض:

* شعار واسم المطعم.

* رقم الطلب.

* حالة الطلب الحالية.

* إشعار جاهزية الطلب.

* رسالة انتهاء الطلب بعد الاستلام.

يجب أن تكون التجربة سريعة ولا تتطلب تسجيل حساب.

4. التكامل مع أنظمة الكاشير

يجب تصميم النظام ليكون قابلاً للربط مع أنظمة نقاط البيع، خصوصاً Foodics.

المطلوب من التكامل:

* استقبال الطلبات الجديدة.

* ربط رقم الطلب بنظام NIDA.

* إنشاء QR تلقائياً.

* استقبال تحديثات حالة الطلب عندما يدعمها نظام POS.

* منع تكرار الطلبات عند تكرار أحداث الربط.

يجب التأكد من توفر واجهات API والصلاحيات اللازمة لدى مزود نقاط البيع قبل الالتزام بالتكامل الكامل.

كما يجب أن يعمل النظام بشكل مستقل دون POS.

5. المتطلبات التقنية

أقترح استخدام التقنيات التالية، مع السماح للمطور باقتراح بدائل مناسبة:

المكون التقنية المقترحة

واجهات الويب Next.js

Backend Node.js / NestJS

قاعدة البيانات PostgreSQL

التحديثات المباشرة WebSockets

إدارة المهام Redis

iOS App Clip Swift

شاشة القفل ActivityKit / APNs

الاستضافة Cloud Hosting

الاشتراكات بوابة دفع تدعم الكويت وKNET

يجب أن يكون النظام قابلاً للتوسع، وآمناً، ويدعم تعدد المطاعم والفروع.

6. متطلبات الأمان

* توليد QR عشوائي وفريد لكل طلب.

* عدم تضمين بيانات شخصية داخل QR.

* تحديد صلاحية رمز QR وجلسة العميل.

* منع الوصول غير المصرح به للطلبات.

* تأمين واجهات API.

* تسجيل العمليات المهمة.

* توفير نسخ احتياطية.

* حماية بيانات المطاعم والمستخدمين.

7. مراحل التنفيذ المطلوبة

المرحلة الأولى: إثبات التقنية (Proof of Concept)

تطوير نموذج عملي يتضمن:

* إنشاء طلب.

* توليد QR خاص به.

* مسح QR بواسطة الآيفون.

* عرض حالة الطلب.

* بدء Live Activity على الأجهزة المدعومة.

* تحديث شاشة القفل عند جاهزية الطلب.

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

المرحلة الثانية: تطوير MVP

تطوير لوحة إدارة المنصة، لوحة المطعم، واجهة العميل، قاعدة البيانات، وإدارة الطلبات والفروع.

المرحلة الثالثة: التكامل والاشتراكات

إضافة بوابة الدفع، نظام الاشتراكات، وربط أنظمة نقاط البيع المدعومة.

المرحلة الرابعة: الاختبار والإطلاق

اختبار النظام في مطاعم ومقاهٍ فعلية، ومعالجة الأخطاء، وتجهيزه للإطلاق التجاري.

8. المطلوب تسليمه

* منصة ويب قابلة للتشغيل.

* لوحة Super Admin.

* لوحة تحكم للمطاعم.

* واجهة متابعة العملاء.

* نظام QR فريد لكل طلب.

* إثبات عملي لميزة Live Activities.

* قاعدة بيانات ونظام صلاحيات.

* توثيق API.

* الكود المصدري كاملاً.

* ملفات وتعليمات النشر.

* اختبارات أساسية للأمان والأداء.

* فترة دعم لإصلاح الأخطاء بعد التسليم.

يجب أن تكون ملكية الكود المصدري وحسابات الاستضافة وحسابات النشر لصاحب المشروع، وفقاً للعقد.

9. المطلوب من المستقل

يرجى تقديم عرض فني ومالي يتضمن:

1. تقييم إمكانية تنفيذ تجربة شاشة القفل دون تثبيت تطبيق كامل.

2. التقنيات المقترحة.

3. المدة الزمنية لكل مرحلة.

4. التكلفة التفصيلية لكل مرحلة.

5. متطلبات تكامل Foodics.

6. تكاليف الاستضافة والتشغيل والصيانة.

7. آلية الاختبار وضمان الجودة.

8. مدة الضمان والدعم الفني.

الهدف النهائي: بناء منصة SaaS تجارية قابلة للتوسع، تقدم للمطاعم والمقاهي نظاماً رقمياً متكاملاً لإدارة نداء العملاء ومتابعة جاهزية الطلبات عبر QR Code، مع تجربة استخدام سريعة وبسيطة.