---
title: "রেস্টুরেন্ট ডেলিভারি status workflow: কোনো ধাপ skip নয়"
date: 2026-07-18
updated: 2026-08-29
lang: bn
tags: ["rider-management", "delivery", "operations"]
summary: "পরিষ্কার অপারেশন ও বিশ্বাসযোগ্য রিপোর্ট দেয় এমন কঠোর delivery status sequence।"
canonical: https://rosuii.com/blog/bn/restaurant-delivery-status-workflow
author: "Rosuii Team"
---

# রেস্টুরেন্ট ডেলিভারি status workflow: কোনো ধাপ skip নয়

পরিষ্কার অপারেশন ও বিশ্বাসযোগ্য রিপোর্ট দেয় এমন কঠোর delivery status sequence।

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

Delivery status সাজানোর label নয়, operational record। rider যদি assigned থেকে সরাসরি delivered করে, handoff বা যাত্রা সত্যি হয়েছে কি না কেউ জানে না।

## একদিকে চলা state ব্যবহার করুন

নির্ভরযোগ্য order assigned, picked up, on the way, তারপর delivered হয়। শুধু পরের state অনুমোদন করুন; skip বা reverse-এ পরিষ্কার error দিন।

## প্রতিটি transition-এর owner ঠিক করুন

Dispatch assign করবে; rider pickup ও travel নিশ্চিত করবে; handoff-এ delivered হবে। service analysis-এর জন্য timestamp রাখুন।

- Assignment owner
- Current state
- Last update time

## Rejection আলাদাভাবে সামলান

Rejection delivery failure নয়। কারণ নিন, order unassigned queue-তে ফেরান এবং dispatch-কে দ্রুত ব্যবস্থা নিতে দিন।

## এক status এক operational প্রশ্ন

Status order কোথায় ও next action কার তা বলবে। Completed বলতে kitchen, pickup, customer, payment বা support—সব একসঙ্গে নয়। Readiness, movement, payment/refund আলাদা রাখুন।

Dictionary-তে meaning, previous/next, actor, evidence, message ও exception লিখুন।

## Reference state machine

Name আলাদা হতে পারে, meaning clear। Latest value-এর সঙ্গে event history, actor/time রাখুন।

| State | Meaning | Owner |
| --- | --- | --- |
| Confirmed | Accepted | Kitchen |
| Preparing | Production | Kitchen |
| Ready | Handover ready | Dispatch |
| Assigned | Rider owner | Rider/dispatch |
| Picked | Left custody | Rider |
| Out | Trip active | Rider |
| Delivered | Handover proof | Cash/support |
| Failed/return | Not complete | Manager |

## Valid transition ও permission

Pickup-এর আগে delivered বা normal close-এর পরে silent return block করুন। Assignment eligible rider, pickup current rider, delivery required proof চাইতে পারে।

Kitchen readiness, dispatch assignment, rider trip, manager failed/reversal। Override original/new/actor/reason রাখবে।

## Event time বনাম edit time

Offline sync হলে occurrence ও recorded time আলাদা রাখুন। Sync time-কে delivery time করলে metric ভুল; arbitrary backdate-ও risk।

কোন event offline queue, conflict resolution ও pending UI define/test করুন।

## Handover check

Pickup custody boundary। Ready বলে pickup নয়; wrong rider controlled handover/reassign ছাড়া নয়।

| Check | Evidence |
| --- | --- |
| Order | ID match |
| Items | Checklist |
| Payment | Prepaid/COD |
| Rider | Current assignment |
| Time | Pickup event |
| Note | Necessary only |
| Problem | Exception owner |

## Customer message evidence অনুযায়ী

Ready message rider travelling claim করবে না। Verified নয় এমন arrival promise নয়। Correction message policy রাখুন।

Internal note/staff blame expose নয়; minimum customer data।

## Failed, cancelled, returned আলাদা

Cancel dispatch-এর আগে, failed pickup-এর পরে, return physical movement। Delivery, sale/refund, payment ও food disposition আলাদা।

Unreachable, address, refusal, payment, damage, safety বা restaurant error category দিয়ে manager reattempt/return/refund decide করবে।

## COD boundary

Delivered মানেই cash reconciled নয়। Expected, collected, deposit, cashier ও difference আলাদা। Prepaid pending settlement cash received নয়।

Refund financial event; delivery timeline backward নয়।

## Exception owner

- Preparing—kitchen
- Ready/no rider—dispatch
- No accept—dispatch
- Pickup mismatch—manager
- Delay/safety—support
- Failed—manager
- COD difference—cashier
- Wrong status—correction owner

## Audit/test

- Stuck
- Skipped/override
- Event vs sync
- Handover
- Failed owner
- No proof
- COD pending
- Early message
- Normal flow
- Offline
- Wrong rider
- Correction

## Status dictionary ছাড়া automation চালু করবেন না

Restaurant delivery status workflow একটি visible label list নয়; এটি order custody এবং next action-এর shared operating language। Confirmed মানে restaurant order accept করেছে, preparing মানে production শুরু, ready মানে নির্ধারিত handover condition পূরণ, picked up মানে restaurant custody শেষ—এগুলো লিখিত definition ছাড়া staff একই label ভিন্নভাবে ব্যবহার করবে।

Completed label সবচেয়ে বেশি ambiguity তৈরি করে। Kitchen finished, rider collected, customer received, COD জমা এবং support case closed আলাদা ঘটনা। একটি label দিয়ে সব close করলে delay কোথায় হয়েছে, cash কার কাছে এবং customer complaint-এর সময় evidence কী—এসব বোঝা যায় না। Readiness, delivery, payment/refund এবং support resolution আলাদা field বা state রাখুন।

Dictionary change হলে version ও effective date লিখুন। পুরোনো report নতুন definition দিয়ে silently recalculate করবেন না। Training card, dashboard tooltip এবং SOP একই current definition ব্যবহার করছে কি না branch launch-এর আগে review করুন।

| Field | যা লিখবেন | Control |
| --- | --- | --- |
| Status name | একটি unambiguous label | Branch জুড়ে একই meaning |
| Operational meaning | বাস্তবে কী ঘটেছে | UI colour দিয়ে meaning নয় |
| Allowed previous | কোন state থেকে আসবে | Impossible jump block |
| Allowed next | পরের valid action | Exception path আলাদা |
| Actor | Kitchen, dispatch, rider বা manager | Role permission |
| Evidence | ID, time, proof বা reason | Minimum required field |
| Customer message | যদি সত্যিই প্রয়োজন হয় | Event-supported wording |
| Correction | কে, কেন ও কীভাবে | History preserved |

## Readiness ও delivery movement parallel হতে পারে

Rider assignment food ready হওয়ার আগে হতে পারে, আবার food ready হলেও rider পাওয়া নাও যেতে পারে। তাই একটি linear label যেন অন্য timeline মুছে না দেয়। Kitchen readiness field এবং rider assignment/trip field পাশাপাশি দেখালে dispatcher বুঝতে পারে delay production-এ নাকি assignment-এ, কিন্তু elapsed time দেখেই দায় নির্ধারণ করা যাবে না।

Reference flow হিসেবে confirmed → preparing → ready for dispatch এবং assigned → picked up → out for delivery → delivered ব্যবহার করা যায়। Product names আলাদা হলেও operational meaning clear থাকতে হবে। Assigned state current rider ownership বোঝাবে; picked up হওয়ার আগে reassignment controlled হবে এবং previous rider, new rider, reason ও actor record করবে।

Ready timestamp তখনই দিন যখন packaging, item count, label এবং required dispatch check সত্যিই complete। শুধু estimated cook time শেষ বা rider এসে গেছে বলে ready mark করলে customer message ও rider wait analysis দুটোই ভুল হয়।

## Occurrence time, record time ও sync time আলাদা রাখুন

Connectivity না থাকলে rider customer handover শেষ করার পরে status sync করতে পারে। Sync time-কে delivery time ধরলে route metric ও customer support chronology ভুল হয়। আবার unrestricted backdate দিলে evidence manipulation-এর ঝুঁকি থাকে। কোন role কত সময়ের event back-record করতে পারে, কী reason লাগবে এবং manager review কখন হবে লিখুন।

Offline-capable বলা যাবে শুধু exact event queue, device, conflict ও recovery test করা থাকলে। Pending update UI-তে স্পষ্ট দেখান; operator যেন unsynced action-কে confirmed server state না ভাবে। একই order দুই device থেকে update হলে deterministic conflict rule এবং manual review queue প্রয়োজন।

Correction original event delete করবে না। Original state, attempted transition, actor, occurrence/record time, correction reason, approver এবং customer/payment follow-up link রেখে corrected current state দিন।

| Timestamp | Meaning | কেন দরকার |
| --- | --- | --- |
| Event occurred | বাস্তবে action হয়েছে | Operational sequence |
| Recorded | Actor system-এ লিখেছে | Delayed entry audit |
| Received/synced | Server event পেয়েছে | Connectivity diagnosis |
| Corrected | Authorised change হয়েছে | Original history |
| Customer notified | Message dispatch হয়েছে | Claim support |

## Restaurant-to-rider handover হলো custody boundary

Pickup button চাপা মানে শুধু rider উপস্থিত নয়; order restaurant custody থেকে current assigned rider-এর কাছে গেছে। Dispatcher order ID বা label, item/package count, seal বা packaging condition, special handling, prepaid/COD responsibility এবং current rider identity check করবে। প্রয়োজনের অতিরিক্ত customer data rider বা waiting area-তে প্রকাশ করবেন না।

Wrong rider pickup attempt হলে informal exchange নয়। Current assignment verify করুন, authorised reassignment হলে previous/new rider, reason এবং time record করুন। Food ready কিন্তু rider absent হলে ready state থাকে; picked up mark করে queue পরিষ্কার করা যাবে না। Rider food না নিয়ে চলে গেলে assignment বা exception update হবে, custody নয়।

Handover problem—damaged package, missing item, payment mismatch, unsafe condition বা unverified rider—একটি exception তৈরি করবে যার owner ও next action আছে। Kitchen remake, dispatch reassignment এবং customer communication কে approve করবে তা SOP-তে আলাদা রাখুন।

## Customer message শুধু verified event থেকে পাঠান

Ready message rider পথে আছে বলে দাবি করবে না; assigned message verified route model ছাড়া arrival time promise করবে না; delivered message required handover evidence ছাড়া যাবে না। Template-এর wording status dictionary-এর exact meaning অনুযায়ী review করুন। Integration event delayed হলে message hold, correction বা manual confirmation কোনটি হবে তা নির্ধারণ করুন।

Customer address, phone, landmark ও delivery note fulfilment-এর minimum প্রয়োজন অনুযায়ী role-limited রাখুন। Internal staff note, dispute language, rider ranking বা blame customer notification-এ expose করবেন না। Messaging channel-এর current opt-in, policy ও retention requirement restaurant-কে নিজ দায়িত্বে যাচাই করতে হবে।

Status ভুল হলে correction message সবসময় automatic পাঠানোও ঠিক নয়। Customer কী দেখেছে, ভুল claim-এর impact, order এখন কোথায় এবং support owner কী সিদ্ধান্ত নিয়েছে তা দেখে approved correction পাঠান। Original notification time ও resulting support case order history-তে link করুন।

## Failed, cancelled, returned ও financial outcome আলাদা record

Customer unreachable, unusable address, refusal, payment issue, damage, safety concern এবং restaurant error আলাদা reason category। Factual note ও attempted contact evidence রাখুন; blame-heavy free text বা অপ্রয়োজনীয় personal detail এড়িয়ে চলুন। একই failed label food, cash ও refund outcome স্বয়ংক্রিয়ভাবে ঠিক করবে না।

Cancellation pickup-এর আগে বা পরে হতে পারে; return physical item restaurant-এ ফিরে আসা বোঝায়। Food disposition local food-safety policy অনুযায়ী manager নির্ধারণ করবে—system কোনো returned food আবার sell করার অনুমতি ধরে নেবে না। Reattempt করলে নতুন assignment/attempt linkage দিন, পুরোনো failure মুছবেন না।

Refund authorised financial process। Delivery timeline backward করে refund দেখাবেন না। Request, approval, gateway/platform reference এবং completion state order-এর সঙ্গে link করুন; public copy-তে fixed refund timing promise করবেন না যদি current channel policy দিয়ে তা supported না হয়।

| Dimension | Example values | Decision owner |
| --- | --- | --- |
| Delivery outcome | Delivered, failed, reattempt | Dispatch/support |
| Order state | Active, cancelled, closed | Restaurant manager |
| Food disposition | Customer, returned, discarded | Manager/food safety |
| Payment | Prepaid, COD expected, collected | Cashier/finance |
| Refund | None, requested, approved, completed | Authorised finance/support |
| Responsibility | Reason category ও evidence | Review owner |

## Delivered এবং COD reconciled একই নয়

Delivered customer handover evidence বোঝাতে পারে, কিন্তু COD cash এখনও rider-এর কাছে থাকতে পারে। Expected amount, rider collected declaration, deposit handover, receiving cashier, received amount, difference এবং close approval আলাদা রাখুন। Cash deposit incomplete থাকলে delivery complete হলেও finance exception open থাকবে।

Prepaid order-এ authorised payment state verify করুন; pending settlement বা gateway display-কে bank cash received বলা যাবে না। Payment credential, OTP বা full sensitive transaction data delivery screen-এ expose করবেন না। Reference এবং role-appropriate status যথেষ্ট।

COD difference হলে delivery status reverse নয়। Difference amount, reason, rider statement, cashier evidence, approver ও resolution record করুন। Shift close এবং rider offboarding-এর আগে unresolved cash ownership dashboard ও signed handover দিয়ে clear করুন।

## Exception queue-তে owner, next action ও deadline দিন

Warning colour নিজে action নয়। Exception row-তে order, current state, detected time, impact, owner, next action, due time এবং resolution evidence থাকুক। Safety concern-এ speed target-এর চেয়ে safe escalation priority পাবে।

Escalation threshold restaurant, delivery zone ও operation অনুযায়ী test করুন; এই guide কোনো universal মিনিট নির্ধারণ করে না। Preparation time, traffic, weather, distance, building access, customer response ও integration delay context ছাড়া elapsed time rider performance conclusion নয়।

- Preparing দীর্ঘ: kitchen বা shift manager review
- Ready কিন্তু rider নেই: dispatcher assignment action
- Assigned কিন্তু accept নেই: dispatcher re-offer rule
- Pickup identity mismatch: dispatch ও manager hold
- Trip delay বা safety issue: rider support escalation
- Failed delivery: support/manager outcome decision
- Delivered কিন্তু COD pending: cashier/finance owner
- Wrong status: authorised correction owner
- Customer message mismatch: support correction review

## Branch launch acceptance test

প্রতি test-এর expected result, actual result, evidence, severity, owner ও retest date লিখুন। Production-equivalent role ও branch configuration ব্যবহার করুন, কিন্তু live customer personal data নয়। Critical transition, custody, cash বা access failure থাকলে affected workflow launch করবেন না।

Pilot branch pass করলে অন্য branch automatically pass নয়। Rider pool, printer/KDS, permission, delivery zone ও staff training আলাদা হতে পারে। Limited rollout-এর পরে stuck state, override, correction, missing proof, COD pending এবং early customer-message audit করুন।

Status workflow-এর লক্ষ্য শুধু দ্রুত delivered count নয়। Traceable custody, truthful customer communication, safe exception handling এবং cash closure একসঙ্গে কাজ করছে কি না review করুন। Improvement deploy করলে metric definition ও status dictionary version update করে আবার edge-case test চালান।

- Normal confirmed থেকে delivered sequence
- Food ready হওয়ার আগে rider assignment
- Ready order কিন্তু rider unavailable
- Pickup-এর আগে controlled reassignment
- Wrong rider pickup block
- Offline event পরে sync ও conflict handling
- Failed attempt, return ও optional reattempt
- Delivered COD with difference
- Manager wrong-status correction
- Customer message supporting event-এর আগে block
- Active delivery চলাকালে user access revoke

ছোট state machine kitchen, dispatch, rider ও customer support-এর জন্য একই ভাষা তৈরি করে।

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

- [রাইডার অ্যাসাইন workflow](https://rosuii.com/blog/bn/restaurant-rider-assignment-workflow)
- [নিরাপদ রাইডার লগইন](https://rosuii.com/blog/bn/secure-rider-login-delivery-app)
- [ফুড ডেলিভারি ম্যানেজমেন্ট সফটওয়্যার](https://rosuii.com/blog/bn/food-delivery-management-software)
- [Restaurant management software তুলনা](https://rosuii.com/bn/compare)

**রসুইয়ে এই ফিচারটি দেখুন:** [ডেলিভারি update ট্র্যাক করুন](https://rosuii.com/bn/features#rider-management)

[বিনামূল্যে রসুই ব্যবহার শুরু করুন](https://rosuii.com/bn/register)

## সচরাচর জিজ্ঞাসা

### Assigned order কি rider সরাসরি delivered করতে পারে?

না। আগে picked up ও on-the-way state পার হতে হবে।

### Status reversal কেন বন্ধ করবেন?

Reversal timestamp ও performance report অস্পষ্ট করে; correction নিয়ন্ত্রিত admin process-এ হওয়া উচিত।

### কোন delivery status?

Confirmed, preparing, ready, assigned, picked, out, delivered এবং controlled failed/return।

### Ready ও picked same?

না; ready restaurant custody, picked rider handover।

### Delivered মানে COD reconcile?

সবসময় নয়; cash deposit আলাদা evidence।

### Manager correct করতে পারে?

Prior state/actor/time/reason রেখে controlled correction-এ।

---
Canonical: https://rosuii.com/blog/bn/restaurant-delivery-status-workflow
Machine-readable site overview: https://rosuii.com/llms.txt