تكلفة نظام طلبات المطعم أونلاين: بناء نظام خاص أم Foodics وToast وطلبات التوصيل (2026)

الإجابة المختصرة: يكلّف نظام الطلبات المخصّص لمطعم، بموقع طلبات ولوحة إدارة وشاشة مطبخ، نحو 3,000 إلى 7,000 دولار ويستغرق من 3 إلى 6 أسابيع. وتضيف تطبيقات الجوال للعميل والسائق نحو 1,500 إلى 7,000 دولار حسب النطاق. يسترد النظام تكلفته عندما تنتقل نسبة معتبرة من الطلبات بعيدًا عن تطبيقات التوصيل التي تأخذ عادةً عمولة من 15 إلى 30 بالمئة. أما إذا كان لديك فرع واحد وأسعار بسيطة ولا يهمّك امتلاك بيانات العملاء، فنظام نقاط البيع الذي يوفّر الطلب أونلاين أرخص وأسرع.

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

كم تبلغ تكلفة نظام طلبات المطعم أونلاين في 2026؟

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

هذه النطاقات لعلامة مطعم واحدة بعدة فروع، وتتبع جدول الأسعار المنشور خلف حاسبة تكلفة التطبيقات: أنظمة الأعمال المخصّصة من 1,500 إلى 7,000 دولار، وتطبيقات الجوال من 1,500 إلى 7,000 دولار. ونظام مطعم بإدارة طلبات حية يقع في النصف الأعلى من النطاق الأول. ولا تشمل الأرقام الاستضافة ولا رسوم بوابة الدفع ولا التصوير.

النطاق	ما تحصل عليه	التكلفة المعتادة	المدة
موقع قائمة طعام مع نموذج طلب	القائمة وطلب عبر واتساب أو البريد ولوحة محتوى بسيطة	500 إلى 1,500 دولار	أسبوع إلى أسبوعين
طلبات ويب مع إدارة وشاشة مطبخ	حسابات وتوصيل واستلام ودفع بالبطاقة وحالة الطلب ولوحة تحكم وشاشة مطبخ	3,000 إلى 7,000 دولار	3 إلى 6 أسابيع
إضافة تطبيقي العميل والسائق	تطبيقات iOS وAndroid على الخلفية نفسها وإشعارات وواجهة سائق	يضاف 1,500 إلى 7,000 دولار	3 إلى 6 أسابيع، جزء منها بالتوازي
التشغيل المستمر	تحديثات ومراقبة ونسخ احتياطي وتعديلات صغيرة	باقة الصيانة 99 دولارًا شهريًا، والاستضافة منفصلة	شهري

للمقارنة، تتضمن باقاتي ذات السعر الثابت باقة المتجر بسعر 1,499 دولارًا خلال 21 يومًا وباقة MVP بسعر 2,499 دولارًا خلال 21 يومًا. نظام المطعم أعلى منها لأن فيه أدوارًا أكثر وطرقًا أكثر لخسارة المال إذا تعطّل شيء. وأعطيك الرقم النهائي بعد جلسة اكتشاف قصيرة، لأن عدد أدوار المستخدمين يحرّك السعر أكثر من أي عامل آخر.

هل أبني منصة طلبات خاصة أم أستخدم Foodics أو Toast أو تطبيقات التوصيل؟

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

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

العامل	تطبيق توصيل	طلب عبر نظام نقاط البيع	منصة مخصّصة
التكلفة الأولية	شبه معدومة	منخفضة باشتراك شهري	آلاف الدولارات
التكلفة لكل طلب	عمولة تتراوح عادة بين 15 و30 بالمئة	اشتراك مع رسوم الدفع	رسوم بوابة الدفع فقط
بيانات العملاء	تملكها المنصة	جزء منها لك	كلها لك
الهوية وتجربة الطلب	ثابتة	قوالب محدودة	كما تصمّمها
أسعار وإيقاف الأصناف لكل فرع	يدوي	حسب الباقة	مبنية على قواعدك
جودة العربية واتجاه RTL	متفاوتة	متفاوتة	باختيارك ومختبرة
من يصلح الأعطال	المزوّد	المزوّد	أنت أو مطوّرك

ما نقطة التعادل؟

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

السيناريو	الطلبات شهريًا	متوسط الطلب	العمولة	الطلبات المنقولة لقناتك	الوفر الشهري
فرع واحد مزدحم	1,500	8 دولارات	20%	30%	720 دولارًا
ثلاثة فروع	5,000	10 دولارات	22%	30%	3,300 دولار
علامة توصيل خليجية	3,000	22 دولارًا	25%	25%	4,125 دولارًا

مقابل بناء بتكلفة 5,000 دولار، يسترد الفرع الواحد تكلفته في نحو سبعة أشهر، وتسترده الحالتان الأخريان في أقل من شهرين. وإذا لم تستطع نقل 20 بالمئة من الطلبات فالبناء نادرًا ما يعوّض تكلفته، وسأقول لك ذلك قبل أن تنفق شيئًا.

ما الميزات التي يحتاجها نظام طلبات المطعم؟

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

• القائمة والإضافات: أحجام وإضافات وإزالة مكوّنات وكوبونات.
• الفروع: أسعار خاصة بكل فرع وإيقاف الصنف لكل فرع.
• التوصيل والاستلام: دفتر عناوين وتسعير توصيل فوري ووقت وصول متوقع للمندوب.
• الدفع: الدفع عند الاستلام وبالبطاقة عبر بوابة محلية مثل Paymob في مصر.
• نظام شاشة المطبخ: شاشة تعرض الطلبات الواردة لطاقم المطبخ.
• لوحة الإدارة: الطلبات والكتالوج والفروع والكوبونات والمالية وصلاحيات الموظفين وسجل التدقيق.
• العربية والإنجليزية: اتجاه RTL حقيقي وليس صفحة إنجليزية معكوسة.
• اختياري: المفضلة والمراجعات ودردشة الدعم وصندوق الإشعارات.

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

كيف تمنع الطلبات المكررة وفشل الدفع عند إتمام الطلب؟

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

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

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

كيف تعمل الأسعار لكل فرع وحالة نفاد الصنف؟

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

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

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

كم يستغرق البناء، وكيف يبدو مشروع حقيقي؟

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

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

• واجهة API بـ NestJS من 24 وحدة وظيفية على PostgreSQL وRedis، مبنية كنظام موحّد مقسّم إلى وحدات بدل الخدمات المصغّرة، وهو الأنسب لحجم مطعم.
• تطبيق Expo React Native للعملاء والسائقين.
• موقع طلبات بـ Next.js بالعربية والإنجليزية. لا يتصل المتصفح بالـ API مباشرة، بل يعمل الموقع كطبقة وسيطة، فتبقى الرموز في كوكيز httpOnly ولا يصل مفتاح التطبيق إلى العميل. وتندمج سلة الضيف مع السلة الحقيقية عند تسجيل الدخول.
• لوحة إدارة React مع شاشة مطبخ تستعلم عن التحديثات كل بضع ثوانٍ. اخترت الاستعلام الدوري بدل طبقة لحظية لأنه أبسط وكافٍ للمطبخ.
• تجزئة كلمات المرور بـ Argon2id ورموز تحديث دوّارة وحرّاس للصلاحيات ونطاق الفرع وسجل تدقيق ونسخ احتياطية ليلية مشفّرة بـ AES-256-GCM.
• حزمة Docker Compose واحدة خلف Caddy الذي يتولى HTTPS تلقائيًا.

يذكر ملف README ما لا يفعله الكود، مثل عمّال الطوابير غير المستخدمين بعد، فيطابق التوثيق الواقع. ولا أنسب هنا أرقام مبيعات للمشروع لأنه لا يذكر أي رقم. وإذا احتجت الجانب الخلفي لنظام كهذا فراجع تطوير واجهات API والخلفية، وللتطبيقات راجع تطوير تطبيقات الجوال.

وماذا عن مطاعم الفنادق؟

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

متى يكون نظام جاهز أو نقاط بيع هو الخيار الأذكى؟

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

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

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

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

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