Food Court Management Software in Bangladesh: Guide
Food court operator-এর vendor settlement লাগে; individual stall-এর fast restaurant operation লাগে।
সর্বশেষ যাচাই: 2026-08-28
Food court management software এক venue-র বহু counter-এর order, bill, kitchen, token, vendor sales ও report চালায়। কঠিন অংশ হলো independent vendor আলাদা রেখে customer experience পরিষ্কার রাখা।
এক owner-এর food hall ও mall-এর independent stall এক নয়। Ownership ও settlement আগে map করুন।
Operating model
Single operator-এ ownership ও finance shared হতে পারে; multi-vendor-এ price, tax, stock, staff ও settlement আলাদা।
Vendor data ও permission আলাদা থাকতে হবে।
Ordering ও billing
Counter, central cashier, kiosk বা QR model ঠিক করুন। দুই vendor-এর item দিয়ে test করুন।
True multi-vendor system shared cart split করে; রসুই cross-tenant cart বা auto settlement দেয় না।
Kitchen ও token
প্রতি stall শুধু নিজের KOT/KDS দেখবে। Pickup clear হবে।
রসুই এক tenant-এর station KDS/CDS দেয়; unrelated tenant combine করে না।
Vendor settlement
Gross, refund, tax, fee, commission ও net payable আলাদা report দরকার।
রসুই landlord commission, vendor payout বা multi-merchant settlement করে না।
Rosuii fit
Individual stall POS, modifier, KDS, token, online order, stock, payroll ও report ব্যবহার করতে পারে।
Mall/multi-vendor court-এর shared cart ও settlement-এর জন্য dedicated software দরকার।
Demo
সবচেয়ে কঠিন order ও payout test করুন।
- দুই vendor cart
- এক item cancel
- Separate kitchen
- Pickup
- Fee split
- Data restriction
- Audit
Platform, operator ও vendor-এর দায়িত্ব আগে নির্ধারণ করুন
একটি food court-এ independent vendor till, central cashier, shared ordering kiosk, table QR ordering অথবা hybrid model থাকতে পারে। কে customer order গ্রহণ করে, payment collect করে, প্রতিটি line fulfil করে, refund handle করে, discount fund করে, customer support দেয় এবং vendor settle করে—লিখিতভাবে নির্ধারণ করুন। Commercial ও operating model অস্পষ্ট হলে software একা ownership conflict সমাধান করতে পারে না।
প্রতিটি menu item, order line, kitchen route, payment allocation এবং settlement entry-তে vendor identity ও location scope রাখুন। Mixed basket customer-এর জন্য একটি order হতে পারে, কিন্তু production ও finance-এর জন্য vendor line আলাদা থাকতে হবে। Split করার সময় customer-level order reference হারালে support team পুরো basket trace করতে পারবে না।
Operator এবং vendor agreement-এর current version, effective date ও approval owner রাখুন। Commission, rent, promotion funding, shared service বা refund responsibility সম্পর্কে পুরোনো rate বা অন্য vendor-এর term universal ধরে নেবেন না। এই guide workflow control বোঝায়; কোনো নির্দিষ্ট commercial rate প্রকাশ করে না।
Mixed-basket event model
এক vendor কাজ শেষ করলেই পুরো order ready mark করবেন না। Partial, complete, failed, cancelled এবং substituted state নির্ধারণ করুন এবং customerকে কীভাবে জানানো হবে লিখুন। Combined pickup হলে সব required line ready না হওয়া পর্যন্ত final handover কীভাবে আটকে থাকবে test করুন; split pickup হলে customer token ও notification অস্পষ্ট হয় কি না দেখুন।
একটি item unavailable হলে payment-এর আগে remove, replace বা customer confirmation workflow কী—নির্ধারণ করুন। Payment-এর পরে problem হলে line-level correction, refund এবং vendor settlement effect trace করুন। Replacement-এর price বা allergen information evidence ছাড়া অনুমান করবেন না। Customer consent record করুন এবং kitchen ticket-এ approved outcome পাঠান।
| Event | Customer view | Vendor বা operator record |
|---|---|---|
| Order placed | একটি পরিষ্কার basket ও total | Line সঠিক vendor-এ assigned |
| Payment | Authoritative result | Collection owner ও reference |
| Production | Vendorভিত্তিক status | Station ticket ও acknowledgement |
| Ready | উপযোগী combined বা split notice | Vendor line completion |
| Handover | Token বা order verification | কোন line release হয়েছে |
| Refund | স্পষ্ট amount ও status | Line responsibility ও settlement adjustment |
| Close | Support route | Order-to-vendor reconciliation |
Ordering, payment ও token flow পরীক্ষা
Target channel-এ simple item, required modifier, paid add-on এবং দুই vendor-এর item দিয়ে basket বানান। Cart total, payment request, receipt এবং vendor line total মেলে কি না দেখুন। Pending, failed, duplicated notification এবং successful payment scenario চালান। Payment provider বা integration availability intended account-এ current evidence ছাড়া claim করবেন না।
Token একটি stable customer order-এর সঙ্গে যুক্ত থাকবে, তবে vendor station-এ line-level reference দেখা দরকার। Token display, printed slip বা SMS-এ কোন information প্রয়োজন এবং privacy রক্ষায় কোন detail বাদ থাকবে তা ঠিক করুন। একই token দ্বিতীয়বার handover হতে গেলে warning ও authorized correction flow আছে কি না test করুন।
Cash, digital এবং operator-collected payment model আলাদা হতে পারে। Cash drawer, central counter ও vendor payout relationship লিখুন। Customer payment success দেখলেও platform record pending থাকলে কে decision নেবেন এবং duplicate collection কীভাবে ঠেকবে তা failure playbook-এ রাখুন।
Production routing ও kitchen control
প্রতিটি line সঠিক vendor, kitchen station, printer বা display-তে route হচ্ছে কি না controlled order দিয়ে দেখুন। Customer-facing item name এবং kitchen name আলাদা হতে পারে, কিন্তু stable item ও order reference অক্ষত থাকতে হবে। Modifier, special instruction এবং quantity ticket-এ সম্পূর্ণ দেখা যায় কি না test করুন।
Vendor acknowledgment, preparing, ready, failed এবং handed-over state-এর owner নির্ধারণ করুন। Unacknowledged ticket কত সময় পরে escalation হবে সেটি actual operating policy থেকে ঠিক করুন; universal preparation-time promise করবেন না। Cuisine ও order complexity ভিন্ন হওয়ায় vendor comparison context ছাড়া প্রকাশ করা উচিত নয়।
Printer বা display unavailable হলে fallback route কী এবং reconnect-এর পরে duplicate ticket তৈরি হয় কি না test করুন। Manual kitchen note ব্যবহার হলে পরে system order-এর সঙ্গে reconcile করার rule রাখুন। Wrong routing correction original event delete না করে reason ও actorসহ preserve করুন।
Vendor settlement control
Immutable order line এবং payment event থেকে settlement শুরু করুন। এরপর current signed commercial rule অনুযায়ী commission, rent, shared promotion, refund, payment fee বা অন্যান্য adjustment প্রয়োগ করুন। প্রতিটি adjustment-এর type, amount basis, reason, evidence, approver এবং affected order or period রাখুন। Unexplained difference net payout-এর মধ্যে লুকাবেন না।
Vendor নিজস্ব relevant order, rule application, refund এবং adjustment দেখতে পারবেন; অন্য vendor-এর private sales নয়। Operator cross-vendor operational ও finance view role-based access-এ ব্যবহার করবেন। Vendor statement থেকে order reference ও applied rule বোঝা যায় কি না sample করুন। Dispute route, submission deadline যদি agreement-এ থাকে, এবং responsible reviewer পরিষ্কার করুন।
Accepted settlement period lock করুন। পরে refund, charge correction বা late payment event এলে closed statement silently edit না করে next visible adjustment হিসেবে carry করুন। Opening balance prior accepted close-এর সঙ্গে মিলিয়ে নিন। Statement prepared, reviewed ও accepted date এবং version রাখুন। Formal accounting বা tax treatment qualified process অনুযায়ী হবে।
Food-court system demo
Intended ordering channel, printer বা display এবং peak network condition-এ test করুন। Cross-vendor cart, token display, refund এবং settlement native, configured, custom নাকি manual—evidenceসহ লিখুন। Sales demo-র statement নয়, authenticated workflow ও exportকে acceptance proof হিসেবে নিন।
Role test-এ vendor cashier, vendor manager, operator support, finance এবং administrator account ব্যবহার করুন। Vendor user অন্য outlet-এর menu, customer detail বা settlement দেখতে পান কি না পরীক্ষা করুন। Staff offboarding, password recovery এবং device loss scenario দেখুন। Shared credential এবং content file-এ password বা OTP সংরক্ষণ এড়িয়ে চলুন।
- দুই vendor এবং restricted user তৈরি করুন
- Modifierসহ একটি mixed basket বানান
- প্রতিটি line সঠিক station-এ route করুন
- Payment-এর আগে একটি unavailable item handle করুন
- Vendor দুটি ভিন্ন সময়ে complete করুন
- Pending ও failed payment scenario চালান
- Approvalসহ একটি line refund করুন
- Vendor settlement calculate ও inspect করুন
- Operator ও vendor view export করুন
Customer support, refund ও exception ownership
Mixed basket-এর customer সমস্যা কে প্রথমে গ্রহণ করবেন operating agreement-এ নির্ধারণ করুন। Customerকে এক vendor থেকে অন্য vendor-এ ঘোরানোর আগে traceable case ID, order reference ও immediate resolution route দিন। এরপর underlying vendor, operator, payment বা system responsibility evidence দিয়ে assign করুন।
Support case-এ affected line, event time, factual reason, customer communication, approval, refund status এবং settlement effect রাখুন। Screenshot-এ অপ্রয়োজনীয় phone, address বা payment detail redact করুন। Refund initiated, provider pending এবং completed state আলাদা রাখুন; customerকে verified status বলুন।
Repeated unavailable item, wrong routing, token conflict বা handover failure weekly review করুন। Count দেখলেই cause নিশ্চিত হয় না। Menu mapping, staff action, device, network ও system event মিলিয়ে দেখুন। Fix করার পরে controlled order দিয়ে একই path পুনরায় test করুন।
Daily operating review ও period close
প্রতিদিন stuck line, wrong route, unacknowledged ticket, token conflict, customer case, refund, unmatched payment এবং vendor close status দেখুন। Documented process দিয়ে customer impact আগে resolve করুন, তারপর operator, vendor বা system action owner নির্ধারণ করুন। প্রতিটি exception-এর due date ও closure evidence রাখুন।
Vendorভিত্তিক comparable data দেখলেও cuisine, preparation method, basket complexity এবং sample size বিবেচনা করুন। Evidence ও approved methodology ছাড়া public speed, ranking বা performance claim করবেন না। Internal dashboard improvement-এর প্রশ্ন তুলতে পারে; একা কারণ বা quality প্রমাণ করে না।
Period close-এ platform collection, refund এবং adjustment মোট vendor settlement line ও operator share-এর সমষ্টির সঙ্গে reconcile করুন। Rounding, late payment, cross-period refund এবং manual entry investigate করুন। প্রতিটি vendorকে reproducible statement ও dispute route দিন। Accepted statement preserve করুন; later correction approved adjustment হিসেবে দেখান।
Implementation ও human-review gate
প্রথমে commercial responsibility matrix, vendor master, stable item mapping, event state এবং permission model লিখুন। এরপর দুই vendor-এর representative menu দিয়ে test environment-এ order-to-settlement journey চালান। Customer personal data প্রয়োজনের বাইরে ব্যবহার করবেন না। Pilot acceptance-এর আগে finance ও operations owner একই control total reproduce করতে পারেন কি না দেখুন।
Go-live migration-এ vendor, item, station, payment owner, opening settlement balance এবং user access sample করুন। Backup ও rollback owner রাখুন। Staffকে mixed basket, unavailable item, partial ready, customer case, refund এবং period close task করতে দিয়ে training verify করুন।
এই বাংলা draft human reviewer-এর natural language, food-court terminology, current agreement model এবং Rosuii-র actual feature set যাচাই ছাড়া publish করা যাবে না। Review gate অক্ষত থাকবে। কোনো rate, vendor result, customer count, processing speed বা integration claim source evidence ছাড়া যোগ করবেন না; pricing কেবল live `/pricing` source of truth থেকে নিন।
Counter সংখ্যা নয়, ownership ও settlement দেখে software বাছুন।
এক stall/operator-এ Rosuii; vendor payout দরকার হলে dedicated layer।
সম্পর্কিত গাইড
- Multi Chain Restaurant Software
- Bangladesh QSR Software
- Restaurant Reporting Software
- রেস্টুরেন্ট ম্যানেজমেন্ট সফটওয়্যার তুলনা
রসুইয়ে এই ফিচারটি দেখুন: রসুইয়ের branch ও ordering feature দেখুন
হালনাগাদ:
সাধারণ প্রশ্ন
Food court software কী?
এক stall-এ Rosuii চলে?
Shared vendor cart আছে?
Vendor payout আছে?
এক company বহু counter চালাতে পারে?
Food court management software কী করে?
এক order-এ একাধিক vendor-এর item রাখা যায়?
Food court vendor settlement কীভাবে করব?
Mixed-basket customer problem কে handle করবে?
সব vendor কি পুরো food-court sales database দেখবে?
রসুই দিয়ে আপনার রেস্টুরেন্ট চালান
পিওএস, মেনু, ইনভেন্টরি, পে-রোল এবং আরও অনেক কিছু — বাংলাদেশের রেস্টুরেন্টের জন্য তৈরি।
শুরু করুন
