شاشة المطبخ الحيّة ونظام المقهى

شاشة المطبخ (وتُسمّى أيضاً KDS — شاشة عرض المطبخ) هي اللوحة الحيّة الموجَّهة للطاقم، حيث يصل كل طلب يُرسَل من الطاولة في الوقت الفعلي. في اللحظة التي ينقر فيها الزبون تأكيد الطلب على هاتفه، تظهر بطاقة طلب كبيرة على هذه الشاشة، ويمرّر فريقك الطلب عبر مراحل المطبخ بنقرة واحدة لكل مرحلة — من استُلِم وصولاً إلى اكتمل. إنها تستبدل التذكرة المطبوعة والصياح عبر المنفذ بشاشة واحدة مشتركة يقرؤها كل من خلف المنضدة بلمحة.

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

لماذا يهمّ هذا: الطلب هو العمود الفقري لنظام المطعم بأكمله. كل نقرة يقوم بها طاقمك مختومة بالوقت ومكتوبة في سجلّ تاريخي، وهو بالضبط ما يغذّي الخط الزمني الحيّ للزبون («في المطبخ… جاهز!»)، وإيرادات كل طاولة، وسجلّ العميل في نظام الـCRM لديك. فشاشة المطبخ ليست مجرّد وسيلة راحة للطاقم — بل هي كيف يتحوّل زائر عابر بهدوء إلى عميل باسم وله سجلّ يمكنك تسويقه لاحقاً. أتقِن سير عمل المطبخ، فتُضيء تلقائياً كل ميزات التحليلات والولاء وذكاء العملاء التابعة له.

أمر واحد اضبطه بشكل صحيح من البداية: شاشة المطبخ وكامل واجهة الطلب جزء من إضافة خطّة OS. يجب أن يكون نوع متجرك مضبوطاً على مطعم أو مقهى (لا متجر عادي)، ويجب أن تحمل خطّتك الصلاحية المطابقة (restaurant_os أو cafe_os). إن غاب أيٌّ منهما، تعرض صفحات المطبخ وطلب الطاولة صفحة «غير موجود» — لكن لاحظ أن التقاط العميل لا يُحجَب أبداً: حتى دون واجهة الـOS، يظل مسح الطاولة يسجّل الزيارة في نظام الـCRM لديك. البوّابة تخفي آلية الطلب فقط، ولا تخفي جمع البيانات أبداً.

ما هذا / لماذا: قبل أن يصل أي طلب إلى شاشة مطبخك، على الزبون أن يضع طلباً. كل طاولة تنشئها تحصل على رابطها الخاص القصير بصيغة /t/{token} — رمز عشوائي من ٨ أحرف يستحيل تخمينه. تطبع ذلك الرابط كملصق QR للطاولة (أو ترمّزه على بطاقة NFC)؛ يمسحه الزبون بكاميرا هاتفه دون أي تطبيق، فتُفتح قائمتك الحيّة فوراً. هذه هي الباب الأمامي للنظام كلّه، لذا يستحقّ أن تفهم بالضبط ما يراه الزبون.

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

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

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

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

ثم يتابع الزبون خطّاً زمنياً حيّاً. يبقي هاتفه صفحة مفتوحة على /t/o/{order_id} تستعلم عن التحديثات وتعرض مؤشّر حالة ودود: استُلِم الطلب ← أُكِّد ← في المطبخ ← جاهز ← قُدِّم ← اكتمل، مع عدّاد تنازلي للوقت المتوقّع ولمسات صغيرة مثل «الشيف يعمل عليه». في كل مرة يُقدّم فيها طاقمك الطلب على شاشة المطبخ، تعكسه هذه الصفحة خلال ثوانٍ — دون أي تحديث يدوي. تلك هي الحلقة السحرية: نقرة واحدة عند المنفذ تحدّث هاتف الزبون تلقائياً، فلا يضطر أحد لأن يسأل «هل جهز بعد؟»

ما تعرضه / لماذا: افتح شاشة المطبخ من مركز مطعمك (أو اذهب مباشرة إلى user/restaurant/{cardId}/kitchen). صُمِّم التخطيط كلّه ليُقرأ من الطرف الآخر لمطبخ ساخن: ثلاثة مسارات ملوّنة تمتدّ من اليسار لليمين، وكل طلب نشط هو بطاقة واحدة كبيرة في المسار المطابق لحالته. تعرض الشاشة فقط الطلبات التي لا تزال في المطبخ — وأي شيء قُدِّم أو اكتمل أو أُلغِي يسقط تلقائياً، فلا تزدحم اللوحة أبداً بعمل منتهٍ.

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

كل بطاقة طلب تحمل كل ما يحتاجه الخط. عنوان البطاقة هو اسم الطاولة (مثل «طاولة ٧») مع شارة نمط صغيرة (تناول في المكان / استلام / توصيل). وتحته يسرد كل صنف وكمّيّته، إضافة لأي إضافات. وعلى اليمين يعرض مؤقّتَين: ساعة انقضاء كبيرة تعدّ تصاعدياً منذ وضع الطلب، وسطر وقت تقديري أصغر. تستمرّ ساعة الانقضاء في الدقّ بنفسها بين تحديثات البيانات، فتبقى صادقة دائماً حول مدّة انتظار هذه التذكرة — وهي إشارة فريقك للإسراع ببطاقة جلست أطول من اللازم.

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

شريط حِمل المطبخ في الأعلى هو مقياس الضغط لديك. يعرض إجمالي عدد الطلبات النشطة ونطاق انشغال بكلمة واحدة: هادئ، أو مشغول، أو مزدحم جداً. النطاقات حساب صادق من العدد الحيّ — هادئ تحت ٥ طلبات نشطة، ومشغول عند ٥ فأكثر، ومزدحم جداً عند ١٢ فأكثر — لا تخمين ولا تقدير بالذكاء الاصطناعي. وبجانبه ثلاثة عدّادات صغيرة تُفصّل جديد / قيد التحضير / جاهز، ونقطة خضراء نابضة مع «حيّ · يُحدَّث تلقائياً» تؤكّد أن الشاشة متّصلة وتُحدَّث.

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

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

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

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

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

إلغاء الطلب. بجانب زر التقديم على كل بطاقة عنصر X صغير (إلغاء). نقره يضبط الطلب على أُلغِي — حالة صريحة خارج السلسلة الرئيسية — ومثل التقديم/الإكمال، يُغلق جلسة الطاولة. استخدمه لطلب خاطئ، أو مغادرة دون دفع، أو نسخة مكرّرة. يُسجَّل الإلغاء بالطريقة الصادقة نفسها لأي انتقال آخر، فيظهر بوضوح في تاريخ الطلب بدل أن تختفي التذكرة بصمت. لا تراجُع عن الإلغاء، فهو الزر الوحيد الذي يجب التعامل معه بحذر.

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

ما هذا / لماذا: يأتي سكان مي بمحرّك الطلب نفسه بنكهتَين، يحدّدهما نوع متجرك. نظام المطعم هو تجربة التناول في المكان الكاملة؛ ونظام المقهى مضبوط للمنضدة والاستلام والطلب المسبق. يتشاركان شاشة المطبخ نفسها، ودورة الحياة السداسية نفسها، والتقديم بنقرة واحدة نفسه، وطاولات QR/NFC نفسها، والخطّ الزمني الحيّ للعميل نفسه — فأي شيء تعلّمته أعلاه يعمل بالطريقة نفسها في كليهما. الفروق متعمّدة وصغيرة، وكلّها تتعلّق بمطابقة *شكل* كيف يقدّم كل نوع مكان الطعام فعلاً.

نظام المطعم يضع التناول في المكان أولاً. يُفعّل وضع التناول في المكان (جلسات الطاولة، فتُبقي المجموعة فاتورة واحدة مستمرّة عبر عدّة طلبات)، والتقسيم لأطباق متتابعة (إرسال المقبّلات والأطباق الرئيسية والحلويات للمطبخ بالتسلسل)، وإضافات الأصناف الكاملة (عمق «بدون بصل، نصف استواء، أضف جبنة، مع بطاطس» الغنيّ الذي يحتاجه مطبخ الجلوس). ومركزه وروابطه معنونة بلغة المطاعم — قسم QR يُسمّى «الطاولات وQR»، لأن وحدة الخدمة طاولة فعلية يجلس عندها الضيف. اختر المطعم إن كان ضيوفك يجلسون وتُحضِر أنت الطعام إليهم.

نظام المقهى يضع المنضدة والاستلام أولاً. يُطفئ وضع التناول في المكان ويُفعّل بدلاً منه المنضدة / الاستلام والطلب المسبق (يطلب العميل قبل وصوله ويستلم عند الجاهزية). والتقسيم لأطباق متتابعة مُطفأ — فالمقهى يرسل كل شيء دفعة واحدة لا بالتسلسل — والإضافات تبقى بسيطة بدل عمق المطعم الكامل (تخيّل «حليب شوفان، جرعة إضافية» لا بناءً من خمس خطوات). وقسم QR فيه يُعاد تسميته «QR الاستلام» بدل «الطاولات وQR»، لأن وحدة الخدمة طلب عند منضدة لا طاولة جلوس. اختر المقهى إن كان العملاء يطلبون وينتظرون ويستلمون.

شاشة المطبخ نفسها تبدو وتعمل بالطريقة نفسها في كليهما. المسارات والبطاقات وشريط الحِمل والتقديم بنقرة واحدة والتحديث كل ٧ ثوانٍ — كلّها متطابقة. الفرق العملي الوحيد الذي يلاحظه طاقم مطبخك هو شارة نمط الطلب على كل بطاقة (تناول في المكان مقابل استلام)، وأن بطاقات المقهى نادراً ما تحمل اسم طاولة. فلا تعيد تدريب الطاقم حين تدير مقهى: اللوحة هي اللوحة. نوع الـOS يغيّر فقط ما يضبطه *المالك* وما يراه *الزبون* على صفحة الطلب، لا المنفذ.

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

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

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

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

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

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

دع النظام يقوم بذكاء العملاء — مهمّتك فقط إدارة المطبخ. كل طلب تقدّمه يربط ذلك الزبون بهدوء بنظام الـCRM لديك: طلبه، وإنفاقه، وهاتفه إن أعطاه، والقناة التي وصل منها. لا تكتب أبداً سجلّ عميل يدوياً. ومع الوقت يبني هذا ملف «الزبون الدائم الذي يطلب اللاتيه دائماً الساعة الثامنة مساءً» الذي يشغّل الولاء وإعادة التسويق — كل ذلك ناتج مجّاني لإدارة شاشة المطبخ بشكل طبيعي.

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

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

ماذا يحدث للطلب بعد أن أعلّمه قُدِّم أو اكتمل؟ يسقط فوراً عن شاشة المطبخ — فاللوحة لا تعرض إلا الطلبات التي لا تزال في المطبخ، فلا يزدحمها العمل المنتهي أبداً. الطلب نفسه لا يُحذَف؛ بل يبقى في تاريخ طلباتك وسجلّ العميل في الـCRM، وتُغلق جلسة طاولته فتُقرأ الطاولة كحرّة من جديد. إن علّمته قُدِّم، يعرض هاتف الزبون «بالهناء والشفاء!»؛ واكتمل يعرض أن الطلب أُنجِز.

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

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

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

صفحات المطبخ والطلب تعرض «غير موجود» — ما الخطأ؟ تظهر تلك البوّابة حين لا يكون نوع متجرك مضبوطاً على مطعم أو مقهى، أو لا تحمل خطّتك صلاحية الـOS المطابقة (restaurant_os / cafe_os). اضبط نوع المتجر من قائمة متاجرك وتأكّد أن خطّتك تتضمّن إضافة الـOS. مهمّ: حتى وبوّابة الحجب قائمة، يظل التقاط العميل يعمل — فمسح الطاولة يُسجَّل في الـCRM لديك بغضّ النظر. تُخفى واجهات الطلب والمطبخ فقط، لا بياناتك أبداً.

الإضافات (Modifiers) تتيح للطبق أن يحمل خيارات وإضافات — «الحجم: عادي / كبير»، «الحليب: كامل / شوفان»، «إضافات: +جبن، +لحم مقدّد»، «الحرارة: خفيف / حار». وهي جزء من مجموعة قدرات نظام الأعمال: نظام المطعم يفعّل مجموعات إضافات كاملة (عدة مجموعات لكل صنف، إلزامية أو اختيارية، باختيار مفرد أو متعدّد)، بينما يُبقي نظام المقهى الفكرة نفسها لكن أبسط — مناسبة لبضعة خيارات سريعة على مشروب. والمتجر العادي ليس له إضافات إطلاقاً. والعمق الذي تحصل عليه يتبع نوع نظام متجرك، لا مفتاحاً منفصلاً.

وفي قائمة العميل، يعرض الطبق الذي يحمل خيارات إشارة «قابل للتخصيص» صغيرة كي يعرف الضيوف أن عليهم النقر للاختيار قبل الإضافة إلى السلّة، وتُرفَق اختياراتهم بسطر الطلب إلى المطبخ. نصيحة عملية: أبقِ مجموعات الإضافات قصيرة وواضحة التسمية — فيطلب الضيوف أسرع، ويقرأ المطبخ التذاكر بنظرة. واحفظ المجموعات الإلزامية («اختر حجماً») للقرارات الضرورية فعلاً كي لا تبطّئ الطلب.

تقسيم الأطباق (Coursing) هو القدرة على تجميع طلب التناول في المكان إلى أطباق متتابعة — المقبّلات أولاً، ثم الأطباق الرئيسية، ثم الحلوى — كي يجهّزها المطبخ ويقدّمها بالترتيب الصحيح بدلاً من إخراج طعام الطاولة كلّه دفعةً واحدة. وهي قدرة في نظام المطعم ومفعّلة للمطاعم فقط؛ أما نمط المقهى المبني على المنضدة والاستلام فلا يستخدم تقسيم الأطباق. إنه الفرق بين خدمة جلوس حقيقية ومنضدة خذ-وامضِ.

ولأن تقسيم الأطباق يركب على سير التناول في المكان، فإنه يقترن طبيعياً بجلسات الطاولة وشاشة المطبخ: يتقدّم كل طبق عبر دورة الحياة نفسها (تم الاستلام ← قيد التحضير ← جاهز ← تم التقديم)، لكن مجمّعاً. وإن كان مكانك يخدم الضيوف على طاولات، فاختر مطعم نوعاً لمتجرك لفتح تقسيم الأطباق؛ وإن اخترت مقهى ووجدت أنك تحتاجه، فبدّل نوع المتجر (يجب أن تخوّلك خطّتك للمطعم) — ولا يُعاد بناء أي شيء آخر.

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

وهنا أيضاً يُغلَق الجانب المالي: لأن طلبات الطاولة تُدفَع شخصياً، تعلّم حالة دفع الطلب (مثل «مدفوع») هنا بمجرد التحصيل. فسطح الطلبات نفسه هو تاريخك للرجوع وأداة تسويتك في نهاية الخدمة معاً — مكان واحد يربط كل تذكرة مطبخ بإيصال وبعميل دافع.

الطلب المسبق (Order-ahead) قدرة في نمط المقهى: مضبوطة للعملاء الذين يطلبون قبل وصولهم أو أثناء انتظارهم، ثم يستلمون عند المنضدة — الإيقاع الطبيعي للمقهى لا لمطعم الجلوس. وهو يركب على التنفيذ نفسه بالمنضدة/الاستلام الذي يفعّله نظام المقهى (والتناول في المكان مُطفأ في نمط المقهى)، فيستطيع العميل وضع طلب استلام من قائمتك وتجهّزه أنت للاستلام.

والطلب المسبق أحد القدرات التي تميّز المقهى عن المطعم: فالمطعم يتمحور حول جلسات الطاولة والتناول في المكان وتقسيم الأطباق، بينما يتمحور المقهى حول المنضدة والاستلام والطلب المسبق بإضافات أبسط. اختر نوع النظام الذي يطابق كيف يستلم ضيوفك طعامهم فعلاً — وتذكّر أن أوقات التحضير المتوقعة (وحِمل المطبخ الاختياري) التي تضبطها في نظام المطعم — الإعداد هي ما يحرّك وعد «جاهز عند» الذي يراه العملاء حين يطلبون مسبقاً.