surfup

مطعم تايلاندي

قائمة إلكترونية مع طلبات QR وروبوت Telegram للموظفين ولوحة إدارة

مطاعم وضيافة · قائمة إلكترونية · طلبات QR · روبوت Telegram · لوحة إدارة
سياق المشروع

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

01 · التحدي

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

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

02 · العمل المنجز

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

  • صممنا بنية بنمطين: قاعدة محتوى واحدة ومسارا وصول. يفتح الرابط العام قائمة عرض تتضمن الفئات والصور والمكونات ومستويات الحرارة والأسعار، من دون أزرار للطلب، لتكون واجهة تقديم للمطبخ على Google Maps ووسائل التواصل. أما روابط الطاولات فتتضمن معاملاً يفعّل نمط الطلب، فتظهر السلة والتعليقات على الأصناف وخيار الإرسال. ويظل المحتوى واحداً، لذلك لا حاجة إلى مزامنته.
  • أنشأنا قائمة عامة سريعة ومتجاوبة تفتح خلال ثانية حتى عبر إنترنت الهاتف المحمول خارج المطعم؛ فالضيف غالباً ما يفتحها مباشرة من بطاقة Google Maps وهو يقف قرب المطعم. وتضم صور الأطباق، وأوصافاً توضح الحرارة والمكونات، وفئات من الحساء إلى المشروبات والحلويات، وأسعاراً محدثة. واستُضيفت خارج الشبكات الداخلية للمطعم، ليظل الرابط مستقراً بصرف النظر عن شبكة Wi-Fi أو ازدحام الصالة.
  • أنشأنا رموز QR للطاولات: لكل طاولة رمز فريد ورابط يتضمن رقمها. فلا يختار الضيف من قائمة «أنا على الطاولة رقم N» ولا يملي مكانه على النادل؛ فالنظام يتعرف إليه من الرابط تلقائياً. أزال ذلك المصدر الأهم للأخطاء في الأنظمة المشابهة وجعل الطلب مرتبطاً بالطاولة منذ اللحظة الأولى. ووضعنا لوحات QR بحيث يسهل مسحها من أي مقعد حول الطاولة.
  • أنشأنا سلة وإرسالاً للطلب من دون تسجيل: يضيف الضيف الأصناف، ويكتب ملاحظة للطبق مثل «من دون فول سوداني» أو «أكثر حرارة» أو «الصلصة منفصلة»، ويراجع محتويات الطلب ثم يؤكده. يصل الطلب إلى بوت Telegram للموظفين مع رقم طلب فريد ورقم الطاولة. لا حاجة إلى تثبيت تطبيق أو إدخال رقم هاتف أو إنشاء حساب؛ فالانتقال من المسح إلى الإرسال يستغرق دقيقة أو دقيقتين، وصُمم هذا المسار ليكون أقصر من أي خيار بديل.
  • طورنا بوت Telegram للموظفين، لتصل إليه جميع الطلبات في الوقت الفعلي مع رقم فريد ورقم الطاولة والأصناف وملاحظات الضيوف والمبلغ. وإلى جانب استقبال الطلبات، يسجل البوت سجل الطلبات بحسب الوردية واليوم، والمبالغ بحسب القائمة والأصناف، ويتيح إعادة الإرسال ومتابعة حالات المعالجة. يعمل الموظفون داخل Telegram المفتوح أصلاً على أجهزتهم؛ فلا حاجة إلى تثبيت برنامج منفصل أو التدريب عليه، فالواجهة مألوفة مثل أي محادثة.
  • أنشأنا لوحة إدارة للقائمة لإضافة أصناف جديدة وتعديل الأسعار والأوصاف والصور والفئات، وحذف الأصناف وتحديد توفرها فوراً بخيار «متاح/غير متاح». يظهر كل تعديل مباشرة في القائمة العامة ونمط الطلب معاً لأنها القائمة نفسها. يستطيع المالك إدارة الأصناف من هاتفه من دون مبرمج أو طلب المساعدة منا عند كل تفصيل صغير.
  • أخذنا في الحسبان الحالات اليومية في الصالة: إذا طلب ضيف صنفاً نفد للتو من المطبخ، يخفيه المدير فوراً في لوحة الإدارة فيختفي من نمط الطلب؛ وإذا أُرسل الطلب مرتين بالخطأ، يرى الموظفون النسختين ويرفضون المكررة؛ وإذا تغير السعر، يُعدّل مرة واحدة في كل الأماكن. هذه المواقف اليومية هي التي تحدد ما إذا كان النظام سيصمد في مطعم يعمل فعلياً.
  • أطلقنا النظام ودربنا الموظفين: طباعة رموز QR وتوزيعها، وشرح طريقة استخدام البوت للنُدُل، ومتابعة الورديات الأولى، وجمع ملاحظات الضيوف والموظفين، وضبط تفاصيل الواجهة استناداً إلى الاستخدام الفعلي.

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

03 · النتيجة

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

04 · النتائج الرئيسية
المؤشرالنتيجة
تحديث القائمةإعادة الطباعة خلال عدة أيام → دقائق في لوحة الإدارة
من قرار الضيف إلى إرسال الطلب5–10 دقائق → 1–2 دقيقة
أخطاء الطلباتمتكررة → حالات فردية في كل ربع سنة
متوسط الفاتورة+17%
تسجيل الطلبات والإيرادات بحسب الوردياتيدوياً في دفتر → آلياً في البوت

نُقلت المؤشرات من المواد الأصلية للحالة. وتُذكر الفترة حيثما وردت في المصدر.

الأشهر الثلاثة الأولى
متوسط الفاتورة
+17%
من قرار الضيف إلى إرسال الطلب (كان 5–10 دقائق)
1–2 دقيقة
لتحديث القائمة في لوحة الإدارة بدلاً من إعادة طباعتها
دقائق
أربعة أجزاء للنظام
  1. 01القائمة العامةرابط واحد لـ Google Maps ووسائل التواصل الاجتماعي
  2. 02روابط الطاولاترمز QR يتضمن رقم الطاولة
  3. 03بوت Telegram للموظفينالطلبات والسجل والإجماليات
  4. 04لوحة الإدارةإدارة القائمة من دون مبرمج
رحلة الضيف
  1. 01امسح رمز QR
  2. 02القائمة
  3. 03السلة
  4. 04تأكيد
  5. 05الطلب في البوترقم الطلب ورقم الطاولة
الوقت اللازم لإرسال الطلب
من قرار الضيف إلى الطلب
قبل5–10 دقيقة
بعد1–2 دقيقة
القيمة الأقل أفضل

تُرسم الحدود العليا للنطاقات: 5–10 دقائق و1–2 دقيقة.

الخطوات التالية

الخطوة التالية التي نقترحها للمطعم:

  • الدفع مباشرة من القائمة: يسدد الضيف الحساب من الطاولة من دون انتظار النادل، فتدور الطاولات بسرعة أكبر وتختفي في الذروة طوابير انتظار الحساب.
  • إضافة لغات: ترجمة أوصاف الأطباق إلى الإنجليزية ولغات أخرى لتناسب تدفق السياح، مع الإبقاء على المحتوى نفسه وترجمة طبقاته.
  • تعزيز الظهور في محركات الإجابة التوليدية (GEO): تنظيم معلومات المطبخ والقائمة والأجواء، كي يذكر المساعدون الذكاء الاصطناعي المطعم بدقة عند الإجابة عن أسئلة مثل «أين أجرب المطبخ التايلاندي؟»؛ وهي قناة يختار عبرها عدد متزايد من الضيوف مطاعمهم اليوم.
  • تحليلات القائمة: معرفة الأطباق التي يشاهدها الضيوف ولا يطلبونها، والأصناف التي ترفع قيمة الفاتورة، لتكون أساساً لتحسين التشكيلة والعروض الموسمية.
اقتباس
في أمسيات الجمعة، لم يكن النُدُل يستطيعون الوصول إلى الطاولات في الوقت المناسب؛ أما الآن فتصل الطلبات تلقائياً مع رقم الطاولة وملاحظة الضيف. وعندما ينفد الطبق الأكثر شعبية، أخفيه في لوحة الإدارة خلال عشر ثوانٍ، فلا يغادر أحد خائباً.

— مالك المطعم التايلاندي

أحدث المواد

كل المواد

مقالات وأدلة عملية من SurfUp.

دليل · 10 دقائق

صفحات «ما هو…» وإجابات الذكاء الاصطناعي: نقرات ضائعة أم طلب متراجع

فقد قسم مرجعي لبنك 24% من الزيارات بينما تراجع الطلب 13%. كيف نميّز النقرات الضائعة بسبب كتلة ذكاء اصطناعي من تراجع الطلب، وكيف نقيس ذلك.

اقرأ
دليل · 8 دقائق

انخفضت الزيارات بعد تحديث Google

كيف تعرف إن كان انخفاض الزيارات بسبب تحديث Google أو الموسمية أو عطل في الموقع: تسلسل تحديثات 2026، وفحص من ستة أسئلة، وخطة أول 14 يومًا.

اقرأ
دليل · 9 دقائق

تراجع الطلب أم خسر الموقع: مطابقة الحركة مع Wordstat

تراجع الطلب على الودائع 75% والحركة 37%؛ وفي البطاقات الطلب −35% والحركة −63%. كيف تطابق الحركة مع الطلب دون أن تلوم الموقع على السوق.

اقرأ