نظام إدارة المطعم: ما الذي يغطيه وكيف تكتب متطلباتك

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

الصالة والمطبخ والمكتب: ثلاثة أجزاء بأسماء مختلفة

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

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

تغيير سعر واحد يكشف من يملك القائمة

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

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

قاعدة 30/30/30/10 اختباراً لنطاق النظام

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

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

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

كيف تبدو برمجيات مطعم عادي من الداخل

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

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

تكلفة نقطة البيع تُحسب بالشهر لا بسعر الاشتراك

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

الاشتراك نفسه، بعدد الفروع والأجهزة التي تشغّلها فعلاً.

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

الأجهزة: الطرفيات وقارئات البطاقات وطابعات المطبخ والأجهزة اللوحية. بعض البائعين يبيعها، وبعضهم يؤجرها، وبعضهم يقبل أجهزتك.

الربط ببقية أدواتك. التكامل مع التوصيل أو الحجز أو المحاسبة أو القائمة الرقمية مجاني أحياناً، وأحياناً برسم شهري على كل وصلة.

المستخدمون الإضافيون والفروع الإضافية وحدود الطلبات الأعلى. هذه تُباع كثيراً إضافاتٍ منفصلة ولا تأتي مشمولة.

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

سجل الضيف: ما تحتاج إليه أداة إدارة علاقات العملاء في المطعم

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

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

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

صنف القائمة يحتاج إلى أكمل تعريف

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

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

القواعد التي يتبعها فريقك دون أن تُكتب

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

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

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

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

اكتب المتطلبات من خدمة واحدة حقيقية

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

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

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

تصميم نظام إدارة المطعم مشروعاً برمجياً

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

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

تضييق قائمة البائعين وترتيب الإعداد

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

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

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

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

أين يقف FineDine وما الذي يتركه لأنظمة أخرى

يغطي FineDine سجلات الصالة ومعها التقارير. في Menu Manager يحمل الصنف وصفاً وصورة وفيديو، وسعراً لكل حجم، وإضافات، ومعلومات القيم الغذائية والحساسية، والأيام والساعات التي يتوفر فيها. قائمة QR التي يراها الضيف تعرض الصنف نفسه بأيقونات الحساسية وأسعار الأحجام، ومنه يقرأ AI Website Builder أيضاً. وإن كانت قائمتك صورة أو ملف PDF أو Excel أو CSV، يبني Menu Manager القائمة من الملف المرفوع. عندها تصير أطول خطوة في الإعداد مراجعةً لما خرج وتصحيحاً له.

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

التقارير طبقتان. التقارير القياسية تغطي الملخص والأصناف والأعمال والحجوزات. وAI Reports (FineDine IQ) تتحدث كل ساعة، وتقارن الإيراد والطلبات ومتوسط الفاتورة بفترة سابقة، وتنبّه إلى الأرقام الشاذة، وتقترح خطوات مثل إكمال صور الأصناف التي تنقصها صورة. بالطبقتين معاً يُغطّى بند الإيراد في قاعدة 30/30/30/10. ووصلات نقطة البيع والدفع والطابعة موجودة في Marketplace، بعضها مجاني وبعضها برسم شهري، فتأكد أولاً أن نظامك بينها.

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