একটি ড্যাশবোর্ড থেকে ফুডপান্ডা ও পাঠাও অর্ডার যেভাবে সামলাবেন

সর্বশেষ যাচাই: 2026-08-28

এক dashboard claim করার আগে current integration যাচাই করুন

Foodpanda, Pathao Food বা অন্য marketplace-এর logo কোনো software website-এ দেখা গেলেই live integration প্রমাণ হয় না। Restaurant-এর country, partner account, outlet, subscription plan এবং প্রয়োজনীয় workflow অনুযায়ী current API, webhook, menu sync, cancellation, rider handover ও settlement import সত্যিই supported কি না vendor-এর current documentation এবং authenticated test দিয়ে যাচাই করুন। একই provider-এর এক outlet-এ যে feature চলে, অন্য outlet বা account-এ approval ছাড়া সেটি নাও চলতে পারে।

Verification sheet-এ platform, outlet identifier, enabled action, authoritative system, test date, test order ID, result এবং unresolved gap লিখুন। Marketing demo, old screenshot বা sales conversation production readiness-এর বিকল্প নয়। Restaurant-এর password, OTP বা recovery code কোনো unapproved aggregator বা consultant-কে দেবেন না; official delegated access বা approved authentication route ব্যবহার করুন।

Official integration unavailable হলে workflow-কে automatic sync বলবেন না। Controlled manual desk ব্যবহার করা যায়, তবে staff যেন source channel, external order ID, amount এবং status স্পষ্টভাবে record করে। Manual fallback-এর label operator ও report—দুই জায়গাতেই দেখা দরকার, যাতে পরে automatic event এলে duplicate sale তৈরি না হয়।

One dashboard-এর operational scope আগে লিখুন

এক dashboard কথাটি আলাদা restaurant-এর কাছে আলাদা অর্থ বহন করতে পারে। কেউ শুধু consolidated reporting চায়, কেউ order acceptance থেকে KOT পর্যন্ত automation চায়, আবার কেউ menu availability ও cancellation-ও একই screen থেকে চালাতে চায়। Required scope লিখে test না করলে partial view-কে full integration মনে হওয়ার ঝুঁকি থাকে।

প্রতিটি action-এর authoritative system ঠিক করুন। Dashboard-এ status দেখালেও partner app-এ cancellation বা support case চালাতে হলে SOP-তে সেটি স্পষ্ট রাখুন। দুই system-এ action করা গেলে precedence এবং conflict rule লিখুন; staff যেন অনুমান করে একই order দুইবার accept, print বা cancel না করে।

Canonical order mapping তৈরি করুন

একটি marketplace order-এর identity external order ID এবং outlet scope দিয়ে স্থির করুন। শুধু customer phone, amount বা সময় দিয়ে match করবেন না—একই মান একাধিক order-এ হতে পারে। Platform-এর original item name, modifier, amount এবং status event preserve করলে kitchen error, customer complaint বা settlement mismatch পরে reproduce করা যায়।

External state-কে vague completed label-এ collapse করবেন না। Accepted, restaurant cancelled, customer cancelled, rider collected, delivered এবং refunded ভিন্ন operational ও financial event। Internal label ব্যবহার করলেও original source value, event time, received time এবং mapping version রেখে দিন।

Duplicate print ও missing order প্রতিরোধ

Webhook retry, page refresh, network recovery বা staff retry যেন একই order দ্বিতীয়বার তৈরি বা print না করে। Platform order ID, outlet এবং tenant scope থেকে idempotency key তৈরি করে repeated event-কে existing mapped order update করতে দিন। Duplicate prevented event log করুন; silently discard করলে genuine conflict খুঁজে পাওয়া কঠিন হয়।

Accepted marketplace order-এর internal kitchen record না থাকলে alert বা exception queue প্রয়োজন। বিপরীতভাবে internal order থাকলেও source platform reference না থাকলে operator review করবে। Order received, mapped, kitchen acknowledged এবং printed—এগুলো আলাদা checkpoint; একটি সবুজ connection indicator পুরো chain সফল হওয়ার প্রমাণ নয়।

Outage-এ manually entered order-এ source channel, external ID, entry reason ও operator লিখুন। Connection ফিরলে automatic event সেই record-এর সঙ্গে reconcile করবে, নতুন sale নয়। External ID তখন পাওয়া না গেলে temporary reference এবং later-match queue রাখুন; collision কে resolve করবে এবং কোন evidence লাগবে তা আগেই নির্ধারণ করুন।

Menu, modifier ও availability আলাদাভাবে test করুন

এক system-এ menu edit করলেই সব marketplace-এ তা চলে যায়—এমন ধরে নেবেন না। Item identifier, variant, addon, mandatory choice, price, tax treatment এবং availability প্রতিটি enabled channel-এ কীভাবে map হয় test করুন। বাংলা/ইংরেজি নাম বা একই নামে একাধিক size থাকলে KOT-এ unambiguous label দেখা প্রয়োজন।

Sold-out control-এর propagation delay এবং direction verify করুন। Dashboard থেকে change source platform-এ যায় কি না, platform edit আবার dashboard value overwrite করে কি না, এবং next-day schedule কীভাবে reset হয় লিখুন। Sync supported না হলে channel-by-channel checklist ও second-person confirmation ব্যবহার করুন।

একটি complex test basket বানান: দুই quantity, variant, required addon, optional note, discount এবং unavailable item। Source screen, mapped order, KOT ও final report পাশাপাশি compare করুন। Test failure থাকলে launch scope কমান বা manual check রাখুন; menu parity প্রমাণ না হওয়া পর্যন্ত oversell reduction claim করবেন না।

Kitchen handoff ও status ownership

Order dashboard-এ দেখা গেলেও kitchen তা পেয়েছে—এটি আলাদা event। KOT printer বা KDS-এর destination, station routing, modifier readability, reprint permission এবং acknowledgement test করুন। Marketplace, direct online, dine-in ও takeaway ticket visual label দিয়ে আলাদা করুন, কিন্তু kitchen production priority restaurant-এর written policy অনুযায়ী চলবে।

Restaurant accepted, preparing, ready, rider arrived, picked up, cancelled ও delivered state-এর actor ঠিক করুন। Kitchen readiness এবং rider movement এক field-এ মেশাবেন না। Partner-controlled rider state dashboard-এ delayed হলে staff যেন unverified ETA বা arrival claim customer-কে না দেয়।

Rider early এলে food ready না হওয়া, wrong rider pickup, order changed after acceptance এবং cancellation during preparation—এই exceptionগুলো test করুন। Current rider/order identity ও pickup time record করে custody handover দিন। Internal note-এ customer-এর অপ্রয়োজনীয় personal data বা staff blame লিখবেন না।

Channel-specific commercial reconciliation বজায় রাখুন

Unified operations screen commercial agreement এক করে না। Foodpanda, Pathao বা অন্য channel-এর current contract, fee definition, discount funding, tax treatment, refund এবং payout period আলাদা থাকতে পারে। প্রতিটি platform-এর source report ও agreement version preserve করে reconcile করুন, তারপর management summary combine করুন।

Dashboard sales total-কে bank payout ধরে নেবেন না। Order gross থেকে discount, fee, refund, adjustment ও settlement timing আলাদা হতে পারে। একটি representative order source acceptance থেকে kitchen record, final status, settlement line এবং bank transfer পর্যন্ত trace করুন; তারপর period-level totals accept করুন।

কোনো public commission rate, savings percentage বা profit improvement অনুমোদিত current evidence এবং documented calculation ছাড়া প্রকাশ করবেন না। Contract confidential হলে exact rate public copy-তে না দিয়ে restaurant-কে নিজের current agreement field বসাতে বলুন।

Integration health view-তে কী দেখা উচিত

Connected badge-এর চেয়ে operational health বেশি গুরুত্বপূর্ণ। Alert নির্দিষ্ট owner-এর কাছে যাবে এবং outlet/channel scope দেখাবে, কিন্তু credential, full customer address বা unnecessary personal data expose করবে না। Alert fatigue এড়াতে severity ও acknowledgement rule দিন।

Recovery-র সময় queued event occurrence order অনুযায়ী idempotently process করুন। Outage window-এর manual register, duplicate prevention, missed KOT, status correction ও settlement impact reconcile না করে incident complete বলবেন না। Root cause, affected orders, control change এবং verification test লিখে রাখুন।

• প্রতি outlet ও channel-এর last successful event
• Delayed বা retrying event count
• Authentication, permission বা partner approval error
• Unmapped item বা modifier
• Duplicate prevented এবং collision review
• Accepted order without kitchen acknowledgement
• Manual fallback order waiting for reconciliation
• Status mismatch বা settlement import failure
• Responsible owner এবং last review time

Access control ও offboarding

Marketplace partner portal এবং dashboard user access একসঙ্গে review করুন। Order view, accept/cancel, menu edit, report export, integration settings ও settlement access role অনুযায়ী সীমিত রাখুন। Shared owner password বা shared OTP workflow audit trail নষ্ট করে এবং account recovery risk বাড়ায়।

Employee, agency বা consultant role বদলালে উভয় system থেকে access revoke করুন, active session এবং recovery contact review করুন। API credential থাকলে approved rotation process অনুসরণ করুন; secret ticket, screenshot বা spreadsheet-এ কপি করবেন না।

Customer address, phone ও delivery note শুধু fulfilment/support-এর প্রয়োজনীয় role দেখবে। Retention এবং export policy লিখুন। Training screenshot বা test environment-এ live personal data ব্যবহার না করাই ভালো; প্রয়োজন হলে mask করুন।

Branch rollout-এর আগে acceptance test

Test production-equivalent outlet configuration-এ controlled order দিয়ে করুন এবং actual customer data ব্যবহার করবেন না। Expected result, actual result, evidence link, severity, owner ও retest date লিখুন। Critical gap থাকলে affected capability launch করবেন না; partner device বা documented fallback চালু রাখুন।

এক branch pass করলে সব branch pass—এমন নয়। Outlet mapping, menu, printer/KDS, staff permission ও marketplace approval branch-specific হতে পারে। Pilot branch-এর পরে limited time window-এ monitor করুন, তারপর evidence দেখে next branch enable করুন।

• প্রতি enabled channel থেকে একটি normal order
• Complex modifier ও বাংলা/ইংরেজি item
• এক item sold-out এবং restoration
• Repeated event-এ duplicate print prevention
• Restaurant ও customer cancellation path
• Rider ready হওয়ার আগে/পরে arrival
• Dashboard বা connector outage এবং manual entry
• Recovery-র পরে manual/automatic reconciliation
• প্রতি channel report ও representative payout trace
• User offboarding ও permission denial test

Daily ও period-end control

Shift শুরুতে device/connection নয়, test event path, menu availability এবং responsible operator confirm করুন। Shift চলাকালে accepted-but-unmapped, no-KOT, cancellation conflict এবং fallback queue দেখুন। End-of-shift-এ source order count, internal mapped count, duplicate prevented, manual order এবং unresolved exception sign off করুন।

Period-end finance review প্রতিটি channel-এর report version, covered dates, opening unresolved item, current exceptions, payout এবং bank match ধরে চলবে। Locked period correction silently historical total বদলাবে না; approved adjustment এবং audit note ব্যবহার করুন।

Volume বাড়লেও exception rate, missing mapping ও reconciliation workload monitor করুন। Dashboard useful কি না শুধু screen count দিয়ে নয়—order traceability, kitchen acknowledgement, unresolved difference ও recovery test দিয়ে বিচার করুন।

Rosuii বা অন্য vendor-কে যে প্রশ্ন করবেন

Vendor-এর উত্তর current product documentation, authenticated demo এবং restaurant-এর own account test দিয়ে মিলিয়ে নিন। Feature roadmap-কে current feature হিসেবে কিনবেন না। Contract বা support scope-এ connector ownership, incident contact, data export এবং exit process বোঝুন।

এই guide কোনো নির্দিষ্ট Rosuii marketplace connector live আছে বলে দাবি করে না। Rosuii-এর direct online storefront, marketplace tagging বা অন্য supported workflow বিবেচনা করলে বর্তমান product page এবং account-specific demonstration দিয়ে scope verify করুন। Manual channel attribution automatic partner integration নয়—দুটির label সবসময় আলাদা রাখুন।

• আমার Bangladesh account ও outlet-এর কোন marketplace connector এখন live?
• Order receive ছাড়া accept, cancellation, menu এবং status—কোন action supported?
• Official authentication কী এবং password share লাগে কি?
• External ID ও duplicate event কীভাবে handle হয়?
• KOT/KDS mapping ও complex modifier কীভাবে test করব?
• Outage fallback এবং recovery reconciliation কী?
• Source commercial fields ও settlement report কতটুকু preserve হয়?
• Customer data, access log ও credential security control কী?
• Feature unavailable হলে visible limitation কোথায় documented?

সম্পর্কিত গাইড

• রেস্টুরেন্ট ম্যানেজমেন্ট সফটওয়্যার তুলনা

বিনামূল্যে রসুই ব্যবহার শুরু করুন