ٹیک اوے ڈائن ان سے ایک مختلف کاروبار ہے۔ گاہک بیٹھتے نہیں۔ انھیں کسی میز پر رکھنے کو کچھ نہیں ہے۔ وہ دو چیزیں جاننا چاہتے ہیں: کھانا کب تیار ہوگا، اور ادائیگی کیسے کروں۔ جو چیز بھی ان دو سوالوں کے راستے میں آئے وہ رکاوٹ ہے، اور رکاوٹ آرڈرز کو اس مقابلے کار کے پاس بھیجتی ہے جس کا عمل بہتر ہے۔
گزشتہ چند سالوں میں ٹیک اوے کی حکمت عملی فون کالز اور واک ان کاؤنٹرز سے دور QR اور قطار کے ورک فلو کی طرف منتقل ہو گئی ہے جو پیمانے پر کام کرتی ہے۔ گاہک قطار کا نمبر لیتے ہیں، اپنے فون پر اپنا آرڈر بناتے ہیں، بینک ٹرانسفر پرچی اپ لوڈ کرکے ادائیگی کرتے ہیں، اور جب ان کا نمبر آئے تو پک اپ کرتے ہیں۔ پوری بات ایک براؤزر میں چلتی ہے، کوئی ایپ نہیں، کوئی ہوسٹ اسٹیشن نہیں، کوئی ہیڈسیٹ نہیں۔
یہ مضمون عملی فیصلوں سے گزرتا ہے جو اس ورک فلو کو ایک حقیقی ریسٹورنٹ میں کام کرنے لائق بناتے ہیں۔
علیحدہ ٹیک اوے قیمتیں
پہلا فیصلہ یہ ہے کہ آیا ٹیک اوے قیمتیں ڈائن ان جیسی ہونی چاہئیں۔ بہت سے ممالک میں جواب نہیں ہے۔ ڈائن ان میں برتن، شیشے کے سامان، میز کی سروس، اور ایک تجربہ شامل ہے۔ ٹیک اوے میں پیکجنگ اور یہ فرض شامل ہے کہ گاہک کہیں اور کھائے گا۔ لاگت کی ساختیں مختلف ہیں، اور ادائیگی کی خواہش مختلف ہے۔
ایک عام نمونہ ٹیک اوے پر معمولی اضافہ ہے — شاید دس سے پندرہ فیصد — پیکجنگ اور تھیلے بنانے اور حوالے کرنے کی معمولی محنت کو پورا کرنے کے لیے۔ کچھ ریسٹورنٹ اسے الٹا کرتے ہیں اور معمولی ٹیک اوے رعایت پیش کرتے ہیں کیونکہ وہ برتن دھونے اور میز کی تبدیلی پر بچت کرتے ہیں۔ کسی بھی صورت میں، مینو سسٹم کو فی آئٹم ایک علیحدہ قیمت فیلڈ کو سپورٹ کرنا ہوگا، ڈائن ان قیمت سے الگ، جو صرف اس وقت ظاہر ہو جب گاہک پک اپ کے لیے آرڈر کر رہا ہو۔
آئٹمز کے لیے ٹیک اوے کے لیے ایک علیحدہ دستیابی کا جھنڈا بھی درکار ہے۔ کچھ پکوان سفر کے ساتھ ٹھیک نہیں رہتے۔ سوفلے، نازک کارپاچیو، کثیر اجزاء والی پلیٹڈ ڈیزرٹ — ان میں سے کوئی بھی ٹیک اوے مینو پر نہیں آنا چاہیے۔ انھیں ڈائن ان مینو پر رہنا چاہیے لیکن ایک ہی ٹوگل سے ٹیک اوے فہرست سے چھپا دیا جانا چاہیے، نہ کہ دو متوازی مینو برقرار رکھ کر۔
دو مرحلے کی آرڈر تصدیق
کلاسک غلطی ٹیک اوے آرڈر کو ایک ویب سائٹ چیک آؤٹ کی طرح سمجھنا ہے، جہاں گاہک سب کچھ آخر میں عہد کرتا ہے۔ عملی طور پر یہ ناکام ہو جاتا ہے کیونکہ ادائیگی کا مرحلہ سب سے سست، سب سے غلطی کا شکار حصہ ہے۔ بینک ٹرانسفر میں وقت لگتا ہے۔ گاہک رقم غلط لکھ سکتا ہے۔ پرچی غیر واضح ہو سکتی ہے۔ اگر ادائیگی کی تصدیق سے پہلے آرڈر لاک ہو جاتا ہے تو کچن ایسا کھانا پکانا شروع کر دیتا ہے جس کے لیے ریسٹورنٹ کو ادائیگی نہیں ہو سکتی۔
بہتر ورک فلو دو مرحلے کی ترسیل ہے۔ مرحلہ ایک: گاہک آرڈر دیتا ہے۔ سسٹم آئٹمز ریکارڈ کرتا ہے، کل حساب لگاتا ہے، اور انھیں ادائیگی کی کرنسی میں واضح کل دکھاتا ہے۔ مرحلہ دو: گاہک ادائیگی پرچی اپ لوڈ کرتا ہے۔ جب تک ریسٹورنٹ دستی طور پر پرچی کی توثیق نہیں کرتا، آرڈر "تصدیق کا انتظار" کی حالت میں رہتا ہے۔ کچن شروع نہیں کرتا۔ گاہک کا اسٹیٹس بیج کہتا ہے "ادائیگی تصدیق کے لیے ریسٹورنٹ کا انتظار" تاکہ انھیں پتہ ہو کہ گیند آپ کے پاس ہے، ان کے نہیں۔
یہ آہستہ لگتا ہے۔ عملی طور پر عملے کی تصدیق میں دس سیکنڈ لگتے ہیں — ڈیش بورڈ کھولیں، پرچی کی تصویر دیکھیں، بٹن ٹیپ کریں۔ کچن اس لمحے آرڈر دیکھتا ہے جب ادائیگی تصدیق ہوتی ہے، پہلے نہیں، جو بالکل صحیح لمحہ ہے۔
ادائیگی پرچی اپ لوڈز جو خراب نہ ہوں
پرچی اپ لوڈز کی سب سے عام ناکامی اجازتیں ہیں۔ گاہک کے فون بے ترتیب IP پتے استعمال کرتے ہیں۔ تصویر کے سائز 200 KB سے 10 MB تک مختلف ہوتے ہیں۔ کچھ گاہک بینک ایپ کا اسکرین شاٹ لیتے ہیں، دوسرے کیمرے سے پرنٹ شدہ رسید کی تصویر لیتے ہیں، دوسرے چیٹ سے فارورڈ کردہ تصویر پیسٹ کرتے ہیں۔ اپ لوڈ سسٹم کو یہ سب کچھ بغیر غلطی کے جذب کرنا ہوگا۔
چند عملی اصول۔ پہلا، متعدد امیج فارمیٹس قبول کریں: JPEG، PNG، اور WebP بنیادی طور پر ہر فون کیمرے اور اسکرین شاٹ ٹول کو کور کرتے ہیں۔ دوسرا، پری سائنڈ اپ لوڈ URLs استعمال کریں جو چند منٹ میں ختم ہو جائیں، تاکہ اپ لوڈ گاہک کے فون سے آپ کے اسٹوریج میں براہ راست ہو، آپ کے سرور کے درمیان میں آئے بغیر۔ تیسرا، URL جاری کرنے سے پہلے سرور کی جانب سے فائل کی قسم کی توثیق کریں۔ چوتھا، پرچیاں واضح طور پر نام والے راستے کے تحت ذخیرہ کریں تاکہ آپ بعد میں ان کا آڈٹ کر سکیں اگر ادائیگی پر تنازعہ ہو۔
گاہک سامنے والا UI ایک بڑا بٹن ہونا چاہیے جس پر "ادائیگی پرچی اپ لوڈ کریں" لکھا ہو، کثیر مرحلہ فارم نہیں۔ اپ لوڈ کے بعد، گاہک کو "تبدیل کریں" کے آپشن کے ساتھ پرچی کا تھمب نیل دکھائیں اگر انھوں نے غلط اسکرین شاٹ اپ لوڈ کیا۔ ان کا اسٹیٹس بیج فوری طور پر "ریسٹورنٹ کی تصدیق کا انتظار" میں بدلنا چاہیے تاکہ انھیں پتہ ہو کہ اپ لوڈ کامیاب رہا۔
پک اپ کے لیے حوالہ کوڈز
جب گاہک کلیکٹ کرنے آئے تو آپ کو اپنے اسکرین پر آرڈر کے ساتھ ان کے فون کو تیزی سے میچ کرنے کا طریقہ چاہیے۔ ایک خاموش ریسٹورنٹ میں قطار نمبر پکارنا کام کرتا ہے لیکن شور والی ببل ٹی شاپ میں ناکام ہو جاتا ہے جہاں لائن میں پانچ نمبر 12 ہیں۔
ایک مختصر حوالہ کوڈ، گڈبڈی سے پاک کریکٹر سیٹ سے چھ حروف، اسے حل کرتا ہے۔ اسے آرڈر کرنے کے وقت سرور کی جانب سے بنائیں۔ گاہک کے فون پر ان کے قطار نمبر کے ساتھ دکھائیں۔ عملے کے ڈیش بورڈ میں وہی کوڈ دکھائیں۔ جب گاہک آئے تو وہ اپنا فون دکھاتا ہے، آپ کوڈز کا موازنہ کرتے ہیں، اور آپ تھیلا دیتے ہیں۔ پوری تبادلہ تین سیکنڈ لیتا ہے اور کبھی بھی پکارے گئے ناموں پر انحصار نہیں کرتا۔
حوالہ کوڈ دھوکہ دہی کے خلاف بھی کام کرتا ہے۔ ایک گاہک "میں نمبر 42 ہوں" کا دعوی اس کوڈ کو دکھائے بغیر نہیں کر سکتا جو نمبر 42 کے ساتھ جاتا ہے۔ دو بے ترتیب لوگ ایک ہی دن ایک ہی کوڈ پر ٹکرا نہیں سکتے کسی قابل عمل منظرنامے میں۔
دن کے آخر کا مطابقت
ٹیک اوے آمدنی کو روزانہ بینک ٹرانسفر کے ساتھ مطابقت کی ضرورت ہے۔ اسے کرنے کا سب سے آسان طریقہ قطار ڈیش بورڈ میں ایک ہسٹری ویو ہے جو کسی دیے گئے دن سرو کے طور پر نشان زد ہر آرڈر کی فہرست بناتا ہے، قطار نمبر، حوالہ کوڈ، وقت، کل، اور پرچی کی تصویر کا لنک کے ساتھ۔ تاریخ منتخب کریں، فہرست دیکھیں، روزانہ کل دیکھیں، بینک اسٹیٹمنٹ کے ساتھ کراس ریفرنس کریں۔ فی دن پانچ منٹ، ترجیحاً بند کرنے کے معمول کے حصے کے طور پر۔
ہسٹری کو ٹائم زون کو صحیح طریقے سے سنبھالنے کی ضرورت ہے۔ بنکاک میں آدھی رات کو بند ہونے والا ریسٹورنٹ اس کیلنڈر دن کے تمام آرڈرز ایک ساتھ گروپ کردہ دیکھنا چاہیے، نہ کہ ڈنر سروس کے درمیان UTC آدھی رات کے اس پار تقسیم۔ سسٹم کو ریسٹورنٹ کا ملک معلوم ہونا چاہیے اور گروپنگ کے لیے مقامی ٹائم زون استعمال کرنا چاہیے۔
جب کچھ غلط ہو جائے تو کیا کریں
کسی بھی حقیقی ورک فلو میں کنارے کے معاملات ہوتے ہیں۔ گاہک غلط رقم ادا کرتا ہے۔ پرچی ناقابل پڑھ ہے۔ گاہک کبھی پک اپ نہیں کرتا۔ کچن آرڈر اور تصدیق کے درمیان کوئی آئٹم ختم ہو جاتا ہے۔
ان میں سے ہر ایک کے لیے ایک واضح راستہ ڈیزائن کریں۔ غلط رقم: عملہ آرڈر کھولتا ہے، مسئلہ دیکھتا ہے، اور یا تو نوٹ کے ساتھ جزوی ادائیگی قبول کرتا ہے یا گاہک سے دوبارہ ادائیگی کے لیے کہتا ہے۔ ناقابل پڑھ پرچی: عملہ گاہک کو پیغام دیتا ہے (اگر ان کا فون نمبر ہے) یا بس تصدیق نہیں کرتا؛ گاہک دیکھتا ہے کہ ان کا اسٹیٹس پھنسا ہوا ہے اور دوبارہ اپ لوڈ کرتا ہے۔ نو شو: قطار کا اندراج "تیاری" میں رہتا ہے جب تک دستی طور پر سرو یا منسوخ نشان نہ لگایا جائے، اس مقام پر یہ فعال فہرست چھوڑتا ہے۔
آرڈر اور تصدیق کے درمیان اسٹاک ختم ہونا سب سے تکلیف دہ معاملہ ہے۔ سب سے صاف جواب ایک فوری رقم واپسی ہے گاہک کے اسی بینک اکاؤنٹ میں، معذرت اور نوٹ کے ساتھ۔ سسٹمز کو اسے آسان بنانا چاہیے: آرڈر پر ایک منسوخ بٹن جو آپ پرچی دیکھنے کے بعد استعمال کر سکتے ہیں، گاہک کے فون پر فوری منسوخی ظاہر ہونے کے ساتھ۔
خوشی کا راستہ زیادہ جارحانہ طریقے سے بہتر نہ کریں
ٹیک اوے فلو ڈیزائن کرتے وقت جوش یہ فرض کرنا ہے کہ ہر آرڈر بالکل ٹھیک ہوگا، اور اس کے مطابق UI ڈیزائن کریں۔ یہ ایک جال ہے۔ زیادہ تر آرڈرز بالکل ٹھیک ہوتے ہیں، لیکن برے والے غیر متناسب وقت لیتے ہیں اور سب سے زیادہ کسٹمر سروس کا کام پیدا کرتے ہیں۔ پہلے خراب معاملات کے گرد ورک فلو بنائیں، اور اچھے معاملات خود سنبھال لیں گے۔
ایک واضح اسٹیٹس بیج جسے گاہک تین سیکنڈ میں پڑھ سکے۔ ایک ڈیش بورڈ جو عملے کو ایک نظر میں ہر چیز دکھائے۔ تیز حوالگی کے لیے حوالہ کوڈز۔ دن کے آخر کے مطابقت کے لیے ایک ہسٹری ویو۔ اس کے علاوہ یہ ڈیفالٹ توقع کہ کچھ آرڈروں کو دستی مداخلت کی ضرورت ہوگی، اور یہ کہ سسٹم اس مداخلت کو ناممکن کی بجائے آسان بناتا ہے۔ انھیں صحیح کریں اور آپ کے پاس ایک ٹیک اوے آپریشن ہوگی جو پیمانے پر کام کرے۔
