العودة إلى المدونة
العمليات

طلبات السفري عبر QR: أفضل الممارسات من الطلب حتى الاستلام

سير عمل مُختبر للسفري: أسعار منفصلة، رفع إيصال الدفع، وإدارة الاستلام دون مكتب استقبال.

11 min read
طلبات السفري عبر QR: أفضل الممارسات من الطلب حتى الاستلام

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

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

تستعرض هذه المقالة القرارات العملية التي تجعل سير العمل هذا ناجحاً في مطعم حقيقي.

أسعار منفصلة للسفري

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

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

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

تأكيد الطلب ذو المرحلتين

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

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

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

رفع إيصالات الدفع دون توقف

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

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

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

رموز المرجع للاستلام

حين يصل العميل للاستلام، تحتاج وسيلة سريعة لمطابقة هاتفه مع الطلب على شاشتك. مناداة رقم الطابور يُجدي في مطعم هادئ لكن يفشل في محل شاي فقاعي صاخب مع خمسة رقم 12 في الطابور.

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

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

المطابقة في نهاية اليوم

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

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

ماذا تفعل حين يسوء الأمر

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

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

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

لا تُحسِّن المسار المثالي بإفراط

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

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

هل أنت مستعد لإنشاء قائمتك الرقمية المجانية؟

Create and update a menu in 19 languages. The core QR menu stays free, with optional Pro upgrades for higher limits and extra tools.