ميز مقابل Foodics

الكاشير يواجه الزبون. والطلب يواجه المورّد. وظيفتان مختلفتان في يومين مختلفين.

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

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

خصم المخزون يخبرك بما خرج من المبنى. لا يخبرك بما تفعله حياله.

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

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

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

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

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

أكثر من 100 تطبيق. وأكثر من 15 فئة. المخزون موجود، وتخطيط الموارد موجود، ولا واحد منها يصدر أمر شراء.

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

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