টেকআওয়ে ডাইন-ইনের চেয়ে ভিন্ন ব্যবসা। গ্রাহকরা বসেন না। তাদের পার্ক করার জন্য কোনো টেবিল নেই। তারা দুটি জিনিস জানতে চান: খাবার কখন প্রস্তুত হবে এবং কীভাবে পেমেন্ট করব। এই দুটি প্রশ্নের পথে যা আসে তা ঘর্ষণ, এবং ঘর্ষণ অর্ডার হারায় প্রতিযোগীর কাছে যার প্রক্রিয়া মসৃণ।
গত কয়েক বছরে টেকআওয়ের প্লেবুক ফোন কল ও ওয়াক-ইন কাউন্টার থেকে সরে গেছে একটি QR-এন্ড-কিউ ওয়ার্কফ্লোর দিকে যা স্কেল করে। গ্রাহকরা একটি কিউ নম্বর নেন, তাদের নিজের ফোনে অর্ডার তৈরি করেন, ব্যাংক ট্রান্সফার স্লিপ আপলোড করে পেমেন্ট করেন এবং তাদের নম্বর ডাকলে পিকআপ করেন। পুরো জিনিসটা ব্রাউজারে চলে — কোনো অ্যাপ নেই, কোনো হোস্ট স্টেশন নেই, কোনো হেডসেট নেই।
এই নিবন্ধটি ব্যবহারিক সিদ্ধান্তগুলির মধ্য দিয়ে হাঁটে যা এই ওয়ার্কফ্লো একটি বাস্তব রেস্তোরাঁয় কাজ করায়।
পৃথক টেকআওয়ে মূল্য নির্ধারণ
প্রথম সিদ্ধান্ত হলো টেকআওয়ে মূল্য ডাইন-ইনের মতো হওয়া উচিত কিনা। অনেক দেশে উত্তর না। ডাইন-ইনে প্লেট, গ্লাসওয়্যার, টেবিল সেবা এবং একটি অভিজ্ঞতা অন্তর্ভুক্ত। টেকআওয়েতে প্যাকেজিং এবং গ্রাহক অন্য কোথাও খাবেন এই অনুমান অন্তর্ভুক্ত। খরচের কাঠামো ভিন্ন, এবং পেমেন্ট করার ইচ্ছাও ভিন্ন।
একটি সাধারণ প্যাটার্ন হলো টেকআওয়েতে সামান্য বৃদ্ধি — হয়তো দশ থেকে পনেরো শতাংশ — প্যাকেজিং ও ব্যাগ করার প্রান্তিক শ্রম কভার করতে। কিছু রেস্তোরাঁ এটি উল্টো করে ডিশওয়াশিং ও টেবিল টার্নওভার বাঁচিয়ে টেকআওয়েতে ছোট ছাড় দেয়। যেভাবেই হোক, মেনু সিস্টেমে প্রতিটি আইটেমে পৃথক মূল্য ক্ষেত্র সমর্থন করতে হবে, ডাইন-ইন মূল্য থেকে আলাদা, যা কেবল গ্রাহক পিকআপের জন্য অর্ডার করলে দেখা যায়।
আইটেমের টেকআওয়ের জন্যও পৃথক প্রাপ্যতা ফ্ল্যাগ দরকার। কিছু ডিশ ভালো বহন করে না। একটি সুফলে, একটি সূক্ষ্ম কার্পাচ্চিও, একটি বহু-উপাদানের প্লেটেড ডেজার্ট — এগুলোর কোনোটিই টেকআওয়ে মেনুতে থাকার কথা নয়। সেগুলো ডাইন-ইন মেনুতে থাকবে কিন্তু একটি টগলে টেকআওয়ে তালিকা থেকে লুকানো হবে — দুটি সমান্তরাল মেনু বজায় না রেখে।
দুই-পর্যায়ের অর্ডার নিশ্চিতকরণ
ক্লাসিক ভুল টেকআওয়ে অর্ডারকে ওয়েবসাইট চেকআউটের মতো ট্রিট করা, যেখানে গ্রাহক শেষে সব কিছু নিশ্চিত করেন। ব্যবহারিকভাবে এটি ব্যর্থ হয় কারণ পেমেন্ট পদক্ষেপ সবচেয়ে ধীর, সবচেয়ে ত্রুটি-প্রবণ অংশ। ব্যাংক ট্রান্সফার সময় নেয়। গ্রাহক পরিমাণ ভুল করতে পারেন। স্লিপ অস্পষ্ট হতে পারে। পেমেন্ট নিশ্চিত হওয়ার আগে অর্ডার লক হলে, রান্নাঘর রান্না শুরু করে এমন খাবার যার জন্য রেস্তোরাঁ কখনো পেমেন্ট নাও পেতে পারে।
একটি ভালো ওয়ার্কফ্লো হলো দুই-পর্যায়ের হ্যান্ডঅফ। পর্যায় এক: গ্রাহক অর্ডার দেন। সিস্টেম আইটেম রেকর্ড করে, মোট হিসাব করে এবং তাদের একই মুদ্রায় একটি স্পষ্ট মোট দেখায়। পর্যায় দুই: গ্রাহক পেমেন্ট স্লিপ আপলোড করেন। রেস্তোরাঁ ম্যানুয়ালি স্লিপ বৈধ নিশ্চিত না করা পর্যন্ত, অর্ডার "নিশ্চিতকরণের অপেক্ষায়" অবস্থায় থাকে। রান্নাঘর শুরু করে না। গ্রাহকের স্ট্যাটাস ব্যাজ বলে "রেস্তোরাঁ পেমেন্ট নিশ্চিত করার অপেক্ষায়" তাই তারা জানেন বল তাদের কোর্টে নয়, আপনার কোর্টে।
এটি ধীর শোনায়। ব্যবহারিকভাবে কর্মীর নিশ্চিতকরণ দশ সেকেন্ড নেয় — ড্যাশবোর্ড খুলুন, স্লিপের ছবি দেখুন, একটি বাটন ট্যাপ করুন। রান্নাঘর পেমেন্ট নিশ্চিত হওয়ার মুহূর্তে অর্ডার দেখে, আগে নয় — যা ঠিক সঠিক মুহূর্ত।
স্লিপ আপলোড যা ভাঙে না
স্লিপ আপলোডের সবচেয়ে সাধারণ ব্যর্থতার মোড হলো অনুমতি। গ্রাহকের ফোন র্যান্ডম IP ঠিকানা ব্যবহার করে। ছবির আকার ২০০ KB থেকে ১০ MB পর্যন্ত ভিন্ন হয়। কিছু গ্রাহক ব্যাংক অ্যাপ স্ক্রিনশট করেন, অন্যরা ক্যামেরা দিয়ে মুদ্রিত রসিদ ফটোগ্রাফ করেন, অন্যরা চ্যাট থেকে ফরওয়ার্ড করা ছবি পেস্ট করেন। আপলোড সিস্টেম ত্রুটি দিয়ে এই সব শোষণ করতে হবে।
কয়েকটি ব্যবহারিক নিয়ম। প্রথমত, একাধিক ছবির ফরম্যাট গ্রহণ করুন: JPEG, PNG এবং WebP প্রায় প্রতিটি ফোন ক্যামেরা ও স্ক্রিনশট টুল কভার করে। দ্বিতীয়ত, প্রি-সাইনড আপলোড URL ব্যবহার করুন যা কয়েক মিনিটে মেয়াদ শেষ হয়, তাই আপলোড আপনার সার্ভার মাঝে না রেখে সরাসরি গ্রাহকের ফোন থেকে আপনার স্টোরেজে হয়। তৃতীয়ত, URL জারি করার আগে সার্ভার-সাইডে ফাইল টাইপ যাচাই করুন। চতুর্থত, স্লিপ একটি স্পষ্টভাবে-নামকরণকৃত পাথের নিচে সঞ্চয় করুন যাতে পরে পেমেন্ট বিবাদ হলে অডিট করতে পারেন।
গ্রাহকমুখী UI হবে "পেমেন্ট স্লিপ আপলোড করুন" লেবেলযুক্ত একটি বড় বাটন, মাল্টি-স্টেপ ফর্ম নয়। আপলোডের পরে, স্লিপের একটি থাম্বনেইল গ্রাহককে ফেরত দেখান "প্রতিস্থাপন" বিকল্পসহ যদি ভুল স্ক্রিনশট আপলোড করে থাকেন। তাদের স্ট্যাটাস ব্যাজ তাৎক্ষণিক "রেস্তোরাঁ নিশ্চিত করার অপেক্ষায়"-এ পরিণত হওয়া উচিত তাই তারা জানেন আপলোড কাজ করেছে।
পিকআপের জন্য রেফারেন্স কোড
গ্রাহক কালেক্ট করতে এলে, তাদের ফোনকে আপনার স্ক্রিনের অর্ডারের সাথে মেলানোর একটি দ্রুত উপায় দরকার। একটি শান্ত রেস্তোরাঁয় কিউ নম্বর ডাকা কাজ করে কিন্তু লাইনে পাঁচটি নম্বর ১২ আছে এমন একটি গোলমালের বাবল টি শপে ব্যর্থ হয়।
একটি সংক্ষিপ্ত রেফারেন্স কোড — বিভ্রান্তি-মুক্ত চরিত্রের সেট থেকে ছয় অক্ষর — এটি সমাধান করে। এটি অর্ডার দেওয়ার সময় সার্ভার-সাইডে জেনারেট করুন। গ্রাহকের ফোনে তাদের কিউ নম্বরের পাশে দেখান। কর্মী ড্যাশবোর্ডে একই কোড দেখান। গ্রাহক এলে ফোন দেখান, আপনি কোড তুলনা করেন এবং ব্যাগ হস্তান্তর করেন। পুরো বিনিময় তিন সেকেন্ড নেয় এবং কখনো চেঁচানো নামের উপর নির্ভর করে না।
রেফারেন্স কোড অ্যান্টি-ফ্রড হিসেবেও কাজ করে। গ্রাহক "আমি নম্বর ৪২" দাবি করতে পারেন না ৪২ নম্বরের সাথে যাওয়া কোড না দেখিয়ে। একই দিনে দুটি র্যান্ডম মানুষ একই কোডে সংঘর্ষ করতে পারে না কোনো প্রশংসনীয় পরিস্থিতিতে।
দিন-শেষ নিমেষ
টেকআওয়ে রাজস্ব প্রতিদিন ব্যাংক ট্রান্সফারের সাথে মেলানো দরকার। এটি করার সহজতম উপায় হলো কিউ ড্যাশবোর্ডের একটি হিস্টরি ভিউ যা প্রদত্ত দিনে সার্ভড চিহ্নিত প্রতিটি অর্ডার সূচিবদ্ধ করে, কিউ নম্বর, রেফারেন্স কোড, সময়, মোট এবং স্লিপের ছবির লিঙ্ক সহ। একটি তারিখ বাছুন, তালিকা দেখুন, দৈনিক মোট দেখুন, ব্যাংক স্টেটমেন্টের সাথে ক্রস-রেফারেন্স করুন। প্রতিদিন পাঁচ মিনিট, আদর্শভাবে বন্ধের রুটিনের অংশ হিসেবে।
হিস্টরি টাইমজোন সঠিকভাবে সামলাতে হবে। ব্যাংককে মধ্যরাতে বন্ধ হওয়া একটি রেস্তোরাঁ স্থানীয় সময় সেই ক্যালেন্ডার দিনের সব অর্ডার একসাথে দেখা উচিত, UTC মধ্যরাতে ডিনার সার্ভিসের মাঝে বিভক্ত নয়। সিস্টেমের রেস্তোরাঁর দেশ জানা উচিত এবং গ্রুপিংয়ের জন্য স্থানীয় টাইমজোন ব্যবহার করা উচিত।
কিছু ভুল হলে কী করবেন
যেকোনো বাস্তব ওয়ার্কফ্লোতে প্রান্তিক ক্ষেত্র ঘটে। গ্রাহক ভুল পরিমাণ পেমেন্ট করেন। স্লিপ অপঠনযোগ্য। গ্রাহক কখনো পিকআপ করেন না। রান্নাঘর অর্ডার ও নিশ্চিতকরণের মধ্যে একটি আইটেম শেষ করে ফেলে।
প্রতিটির জন্য একটি স্পষ্ট পথ ডিজাইন করুন। ভুল পরিমাণ: কর্মী অর্ডার খোলেন, সমস্যা দেখেন এবং হয় একটি নোটসহ আংশিক পেমেন্ট গ্রহণ করেন বা গ্রাহককে পুনরায় পেমেন্ট করতে বলেন। অপঠনযোগ্য স্লিপ: কর্মী গ্রাহককে মেসেজ করেন (ফোন নম্বর থাকলে) বা কেবল নিশ্চিত করেন না; গ্রাহক লক্ষ্য করেন তাদের স্ট্যাটাস আটকে আছে এবং পুনরায় আপলোড করেন। নো-শো: কিউ এন্ট্রি "প্রিপেয়ারিং"-এ থাকে যতক্ষণ না ম্যানুয়ালি সার্ভড বা ক্যান্সেলড চিহ্নিত হয়, সেই সময়ে সক্রিয় তালিকা থেকে চলে যায়।
অর্ডার ও নিশ্চিতকরণের মধ্যে আউট অব স্টক সবচেয়ে কষ্টদায়ক ক্ষেত্র। পরিষ্কার উত্তর হলো গ্রাহকের একই ব্যাংক অ্যাকাউন্টে দ্রুত ফেরত, ক্ষমা ও একটি নোট সহ। সিস্টেম এটি সহজ করা উচিত: স্লিপ দেখার পরে ব্যবহার করতে পারেন এমন অর্ডারে একটি ক্যান্সেল বাটন, গ্রাহকের ফোন তাৎক্ষণিক বাতিল প্রতিফলিত করে।
হ্যাপি পাথ খুব বেশি অপ্টিমাইজ করবেন না
টেকআওয়ে প্রবাহ ডিজাইন করার সময় প্রলোভন হলো প্রতিটি অর্ডার নিখুঁতভাবে যায় ধরে নেওয়া, এবং সেই অনুযায়ী UI ডিজাইন করা। এটি একটি ফাঁদ। বেশিরভাগ অর্ডার নিখুঁতভাবে যায়, কিন্তু খারাপগুলো অনুপাতহীনভাবে সময় খায় এবং সবচেয়ে বেশি গ্রাহক-সেবা কাজ তৈরি করে। প্রথমে খারাপ ক্ষেত্রগুলো ঘিরে ওয়ার্কফ্লো তৈরি করুন, এবং ভালো ক্ষেত্রগুলো নিজেরাই সামলে নেবে।
গ্রাহক তিন সেকেন্ডে পড়তে পারেন এমন একটি স্পষ্ট স্ট্যাটাস ব্যাজ। কর্মীর এক নজরে যা দরকার তা দেখানো একটি ড্যাশবোর্ড। দ্রুত হ্যান্ডঅফের জন্য রেফারেন্স কোড। দিন-শেষ নিমেষের জন্য একটি হিস্টরি ভিউ। প্লাস ডিফল্ট প্রত্যাশা যে কিছু অর্ডারে ম্যানুয়াল হস্তক্ষেপ দরকার হবে, এবং সিস্টেম সেই হস্তক্ষেপকে অসম্ভব নয় বরং সহজ করে। সেগুলো ঠিক করুন এবং আপনার একটি টেকআওয়ে অপারেশন আছে যা স্কেল করে।
