CustomerDiscover, configure, pay, track, resolve
- Location + search
- Basket + checkout
- Status + support
Validation dossier · FD-MKT-01 · revision B
One order.
Four operations.
One marketplace.
A complete planning packet for an original multi-restaurant delivery product—connecting customer demand, restaurant capacity, courier movement and dispatcher control before a build path is chosen.
- Product preview
- See screens and demo access
- Purpose
- Architecture and scope validation
- Operating loop
- Discover → prepare → dispatch → deliver → reconcile
- Status
- Illustrative; decisions require project discovery
Deployable Product ArchitectureFood delivery marketplace / system register
Prepared for validationNot a production specification
RestaurantPublish, accept, prepare, hand off
- Menu + capacity
- Kitchen queue
- Handoff proof
CourierGo online, accept, collect, deliver
- Offer + route
- Pickup checks
- Delivery proof
DispatcherConfigure, supervise, intervene, reconcile
- Supply view
- Exception desk
- Audit + reporting
IdentityCatalogueOrderDispatchLedgerAudit
Follow a food order from discovery to restaurant operations.
Review the customer storefront, restaurant order records and marketplace catalogue together. Use these references to decide how ordering, courier handoffs and support decisions should work in your restaurant marketplace, then ask to follow an order through checkout, dispatch and a refund in a guided demo.
Customer food-discovery reference showing dishes, sample prices, cuisine categories and order navigation
Customer discovery reference with sample dishes, restaurant names, ratings and prices. It illustrates browsing, not current offers, a deployed client product or a completed checkout.
What to check in the walkthrough
- How should delivery location, restaurant hours and menu availability determine what a customer can order?
- Which item options, dietary details, fees and promotions must be clear before checkout?
- Ask to place an order and test an unavailable item or failed payment; this browsing screen does not establish basket validation or payment handling.
Restaurant order-history reference with delivered and cancelled orders, refund filter and sample amounts
Restaurant order-history reference with demonstration records and status filters. Acceptance, preparation, courier assignment and refund execution need a separate walkthrough.
What to check in the walkthrough
- Who may accept, reject or cancel an order, and what happens when the restaurant does not respond?
- Ask to follow preparation, ready-for-pickup and courier handoff, including a delay or an order with no available courier.
- How should staff escalate a missing item or refund request, and which customer notices and payment records confirm the outcome?
Marketplace admin food-list reference showing restaurant, category, price, stock and status columns with edit controls
Marketplace catalogue reference with demo branding and sample food records. Visible stock and editing controls do not establish permission enforcement, live dispatch or payment reconciliation.
What to check in the walkthrough
- Which menu changes can restaurants publish themselves, and which require marketplace review?
- How should an unavailable dish or suspended restaurant affect discovery, open baskets and orders already accepted?
- Ask to inspect the operator order timeline, courier reassignment and refund approval with actor and reason history; those operational controls are outside this catalogue screen.
Validation premise
The storefront is the visible edge of an operational network.
A credible marketplace does more than list menus. It resolves who can sell, what can be ordered, whether a restaurant can prepare it, which courier may carry it, what the customer sees when reality changes, and how every financial and support action can be explained later.
This dossier makes those dependencies reviewable without pretending that one template, provider or policy fits every operator.
01
Operator decisions
Choose the business before choosing the build.
Each row is a decision axis, not a promised inclusion. Combinations alter permissions, contracts, checkout, dispatch, settlement, support and jurisdictional review.
Supply model
- 01Open multi-restaurant marketplace
- 02Curated restaurant network
- 03Single operator / virtual brands
Fulfilment
- 01Platform courier fleet
- 02Restaurant delivery
- 03Hybrid or pickup-only by zone
Commercial model
- 01Commission
- 02Restaurant subscription
- 03Listing, service or delivery fees
Territory
- 01Single city and currency
- 02Multi-zone operation
- 03Multi-country or multi-tenant
Ordering
- 01On-demand
- 02Scheduled windows
- 03Group, catering or pickup
Dispatch
- 01Rules-led auto dispatch
- 02Manual dispatch desk
- 03Third-party delivery orchestration
02
Connected workflows
Four workdays surround every order.
Every participant receives only the actions, information and escalation paths appropriate to their role.
Customer
- 1Set delivery location
- 2Compare available menus
- 3Configure items and basket
- 4Select time and tender
- 5Track fulfilment
- 6Rate or raise an issue
Restaurant
- 1Complete venue checks
- 2Publish menu and hours
- 3Accept or reject order
- 4Manage substitutions
- 5Prepare and mark ready
- 6Verify courier handoff
Courier
- 1Complete onboarding checks
- 2Set availability and zone
- 3Review and accept offer
- 4Navigate to restaurant
- 5Confirm collection
- 6Deliver with agreed proof
Dispatcher
- 1Monitor demand and supply
- 2Review unassigned orders
- 3Override or reassign
- 4Contact participants
- 5Approve support actions
- 6Close with audit reason
03
Order-state control
One timeline, multiple truths, no invisible jumps.
The order service governs allowed transitions. Participant views are projections of the same versioned history, not separate informal statuses.
| Lane | Intent | Authorise | Confirm | Prepare | Collect | Deliver | Resolve |
|---|---|---|---|---|---|---|---|
| Customer | Submit order | Authorised | Confirmed | Track prep | Track courier | Receive | Closed |
| Platform | Validate basket | Create order | Notify parties | Match courier | Track events | Capture / settle | Archive |
| Restaurant | Receive request | Accept / reject | Prepare | Mark ready | Verify pickup | Complete | Settlement view |
| Courier | — | Offer queued | Accept task | Travel to pickup | Collect | Deliver + proof | Earnings view |
Exception branches
Restaurant rejects / times out
Release or reverse authorisation as provider rules allow; notify customer; optionally offer a replacement path.
Item unavailable
Restaurant requests an approved substitution or removal; recalculate totals and obtain customer consent where required.
No courier accepts
Expand or change matching rules, surface revised expectation, enable manual dispatch, cancellation or alternate fulfilment.
Courier cancels after pickup
Escalate to operator; protect customer and food-safety decisions; record custody and re-delivery outcome.
Delivery cannot be completed
Apply contact attempts, wait policy and evidence rules; operator decides return, disposal, redelivery or refund path.
Duplicate / late event
Use idempotency and order version checks; preserve event history and suppress invalid state regression.
04
Application suite
A marketplace is a portfolio, not one app.
Surfaces may be web, mobile, tablet or service-only according to users, environment, budget and release strategy.
Customer applications
Responsive web or native/cross-platform mobile experiences for discovery, ordering, tracking, account, consent and support.
Restaurant workspace
Tablet-friendly order queue plus web operations for menus, hours, capacity, staff access, promotions and settlement views.
Courier application
Onboarding status, availability, offers, navigation context, pickup and delivery evidence, incidents and earnings records.
Dispatcher console
Live order map, supply and queue health, assignment controls, communications, exception cases and action history.
Marketplace admin
Configuration, access control, restaurant lifecycle, territories, commercial rules, trust, content, finance operations and reporting.
Platform services
Identity, catalogue, search, basket, order, dispatch, payment orchestration, notifications, support, audit and analytics contracts.
04A
Detailed modules
Domain depth behind the suite.
Discovery & catalogue
- Address eligibility
- Cuisine and dietary facets
- Search and ranking rules
- Venue pages
- Menu schedules
- Modifiers and availability
Commerce & orders
- Basket validation
- Minimums and fees
- Promotions
- Tax inputs
- Tender orchestration
- Receipts and order history
Fulfilment & dispatch
- Prep estimates
- Courier eligibility
- Offer sequencing
- Reassignment
- Geofence events
- Proof and completion
Accounts & trust
- Role onboarding
- Consent and preferences
- Verification hooks
- Device and session controls
- Ratings and reports
- Audit trail
Support & finance ops
- Case timeline
- Reason codes
- Partial adjustments
- Disputes
- Restaurant statements
- Courier earnings records
Growth & intelligence
- Campaign rules
- Referral controls
- Experiment flags
- Funnel events
- Operational metrics
- Data exports
04B
Control plane
The operator needs levers, evidence and limits.
Administrative power is permissioned, auditable and separated from routine dispatcher work where the risk requires it.
Network
Restaurants, branches, service zones, opening rules, delivery modes and capacity controls
Commercial
Commission configuration, fee eligibility, promotion funding, tax inputs and settlement policy references
Operations
Order search, live queue, dispatch overrides, cancellation and refund permissions, support cases and reason codes
Risk & access
Role-based permissions, approval steps, verification status, abuse signals, blocks, audit events and retention controls
Content & quality
Cuisine taxonomy, menu moderation, merchandising, ratings review, policy content and accessibility checks
Reporting
Demand, acceptance, preparation, assignment, fulfilment, cancellation and reconciliation exports
04C
Order economics
Trace the money without inventing the numbers.
Rates, minimums, taxes, fee labels, promotions, tips, commissions and payout logic are configuration and policy decisions—not generic claims on this page.
| Ledger view | Potential components | Validation rule |
|---|---|---|
| Customer charge | Item subtotal, taxes, delivery/service/small-order fees, discount and tip where supported | Calculated from configured rules and disclosed before confirmation |
| Restaurant side | Gross food sales, restaurant-funded promotion, commission or subscription, adjustments | Contract and territory dependent |
| Courier side | Base logic, distance/time inputs, incentives, tip allocation, adjustments | Requires local worker-model and payout review |
| Platform side | Recognised fees or commission less funded promotions, provider fees, support adjustments and taxes | Accounting treatment must be confirmed by advisers |
| Reconciliation | Order ledger, payment-provider events, refunds, disputes, restaurant settlement and courier payout records | Differences enter a review queue; no silent balancing |
05
Release boundary
V1 is complete enough to operate—not everything imaginable.
V1 foundation
One launch territory; core customer ordering; restaurant queue and menu controls; courier offer-to-proof flow; dispatcher console; payments, maps and notifications; admin permissions; support/refund reasons; essential analytics; release and handover pack.
V1 validation gates
Operating choices agreed; happy path and priority exceptions proven; provider accounts ready; security and privacy review completed; accessibility acceptance criteria tested; reconciliation and support drills passed.
V2 candidates
Scheduled/group orders, loyalty, subscriptions, advanced promotion funding, multi-tenant controls, sophisticated batching, POS depth, restaurant self-serve growth tools, richer experimentation and warehouse analytics.
Explicit exclusions unless scoped
Guaranteed delivery times, regulated alcohol/pharmacy flows, autonomous dispatch optimisation, proprietary navigation, call-centre staffing, courier hardware, tax/legal advice, provider fees, menu content production and ongoing marketplace operations.
06
Architecture & boundaries
Stable contracts around a changing operation.
A modular monolith or selected services can both be valid. The choice follows scale, team, failure isolation and change patterns—not diagram fashion.
CustomerRestaurantCourierOperations
Authenticated API / policy enforcement / rate limits / request tracing
IdentityCatalogueBasketOrderDispatchPaymentsSupport
Transactional dataEvent / job transportCache + searchObject evidenceAnalytics pipeline
Data boundary
Order and ledger records remain authoritative in transactional stores; search, maps, analytics and notifications receive only the projections needed for their purpose.
Trust boundary
External clients are untrusted; privileged operations require server-side authorisation, scoped roles, auditable reasons and protection against replay or duplicate actions.
Integration boundary
Provider adapters translate contracts, verify callbacks, apply idempotency and isolate retries so an outage does not silently corrupt order state.
06A
Integration register
Buy commodity rails. Own the operating intent.
| Boundary | Expected capability | Responsibility note |
|---|---|---|
| Payments | Tokenised checkout, authorisation/capture, refunds, disputes, marketplace settlement or payouts where the selected provider and operating model support them. | Provider is system of record for processor events; platform retains mapped order/ledger references. |
| Maps & location | Address search, geocoding, routes, ETA inputs, distance matrices and optional geofence signals. | Provider terms, accuracy and cost controls apply; operator owns service-zone rules. |
| Notifications | Transactional email, SMS and push with templates, preference checks, retries and delivery receipts where available. | Providers deliver messages; platform owns notification intent and audit status. |
| POS / restaurant systems | Menu import, availability and order injection/acknowledgement using vendor APIs or middleware. | Capabilities vary by vendor and market; manual fallback remains a scoped decision. |
| Analytics | Consented product events, operational events, aggregated reporting and governed exports. | Operational database is not a free-form analytics interface; minimise personal data. |
07
Trust & market readiness
Launch obligations are part of product design.
These are planning considerations, not legal conclusions or certifications. Applicability and evidence must be assessed for the selected market and model.
Privacy & security
Apply data minimisation, purpose and retention decisions, encryption, secrets management, least privilege, auditability, incident procedures and vendor review. Exact obligations depend on launch jurisdictions and roles such as controller/processor.
Marketplace trust
Define restaurant and courier verification, rating/report handling, prohibited use, account action, fraud review and appeals. Identity or background checks require lawful providers, notices and local review.
Accessibility
Target agreed WCAG criteria across web and operational surfaces; test keyboard, focus, labels, contrast, zoom, errors and assistive technology. Mobile platform accessibility and ongoing content quality also need acceptance checks.
App stores
Prepare privacy disclosures, account deletion paths, permission explanations, content moderation/support details and payment-model review. Apple and Google policies change and approval cannot be guaranteed.
Jurisdiction specifics
Food safety, allergen information, tax, invoicing, tipping, pricing disclosure, consumer cancellation/refund rights, worker classification, age-restricted items and accessibility duties vary. Qualified local advisers must confirm the applicable model.
07A
Failure, refund & support
Design the uncomfortable order before launch.
| Scenario | Customer/support response | Financial control | Evidence retained |
|---|---|---|---|
| Payment authorised, restaurant rejects | Customer sees cancellation and reason-safe status | Void/reversal or refund path per provider state | Order, payment and restaurant event log |
| Restaurant delay exceeds policy | Updated status and support entry point | Operator applies configured remedy; not automatic unless approved | Prep timestamps, notices, case decision |
| Courier unavailable / reassigns | Revised fulfilment state and contact path | No financial action unless policy threshold or cancellation is reached | Offer history, reassignment reason, ETA changes |
| Missing or incorrect item | Issue form with item selection and evidence rules | Partial/full adjustment subject to policy and permissions | Items, evidence reference, actor, reason and payment event |
| Marked delivered, customer disputes | Case acknowledgment; avoid exposing private courier data | Hold for review, refund or deny according to evidence and policy | Proof, location/time signals, contacts, decision |
| Provider outage / unknown result | Pending message; prevent duplicate action | Reconcile before retrying irreversible operations | Request keys, webhooks, retries, operator resolution |
07B
Quality system
Prove behaviour. Watch it. Release it reversibly.
QA
Contract and state-machine tests; role/permission tests; basket and fee permutations; payment sandbox cases; location edge cases; accessibility checks; device/browser coverage; load and recovery exercises.
Observability
Structured logs with redaction, correlation IDs, order-state metrics, queue lag, provider latency/errors, notification outcomes, dispatch health, dashboards and actionable alerts.
Release
Environment separation, protected secrets, migration rehearsal, feature flags, staged rollout, store release checklist, rollback/run-forward plan, incident ownership and post-release verification.
Operational acceptance
Restaurant, courier and dispatcher simulations; refund and reconciliation drill; support macros and escalation; data export/deletion drill; provider failover or degraded-mode walkthrough.
07C
Handover & rights
Name every output and its governing right.
The signed agreement, licences and provider terms control. This matrix avoids implying that every component can be transferred or owned outright.
| Register item | Examples | Rights / custody position |
|---|---|---|
| Product outputs | Validated scope, original experience specification, workflow/state definitions, backlog and acceptance criteria | Customer, subject to the signed engagement and third-party restrictions |
| Custom implementation | Project-specific source code, configuration and test assets identified in the agreement | Rights/license are defined by contract after applicable obligations are met; not stated unconditionally |
| Pre-existing materials | Reusable libraries, methods, templates, know-how or separately licensed foundation | Original owner; customer receives only the agreed licence or access |
| Third-party services | Cloud, maps, payment, messaging, analytics, POS SDKs and open-source packages | Respective providers/licensors under their terms; accounts and billing assigned as agreed |
| Brand and content | Customer-selected original name, marks, menus, policies and media | Customer supplies or commissions lawful materials and clearances |
| Access and operations | Repositories, environments, domains, store records, credentials, runbooks and support boundary | Named custodian and transfer method recorded in the handover register |
08 · Delivery stages
Each stage leaves evidence.
Sequence and commercial terms are set in a project proposal. No generic duration is implied.
- 01
Validate
Decision dossierOperating model, users, territory, reference analysis, state map, risks, exclusions and success measures.
- 02
Specify
Build packetOriginal UX direction, application map, service contracts, data boundaries, integration plan, backlog and acceptance criteria.
- 03
Construct
Reviewable incrementsWorking surfaces and services, automated checks, environment configuration, demos and decision log.
- 04
Prove
Release evidenceEnd-to-end and exception tests, security/privacy/accessibility findings, performance evidence and operational drills.
- 05
Transfer
Launch + handover packRelease records, runbooks, architecture and API notes, inventory, credentials register, training and support boundary.
08A
Build-path comparison
Fit the foundation to the product—not the reverse.
| Path | Best when | Advantage | Watch-outs | Decision test |
|---|---|---|---|---|
| Configured foundation | Existing lawful codebase fits core roles and states | Faster validation of standard loops; known modules | Inherited constraints, upgrade path, licence and deep customisation limits | Use only after technical and rights diligence |
| Composable build | Managed providers can own commodity capabilities | Focused custom product layer; replaceable integrations | Vendor coordination, event consistency and cumulative usage costs | Good when boundaries and fallbacks are explicit |
| Custom platform | Operating model or differentiation requires original domain logic | Maximum control over workflows and evolution | More design, engineering, QA and operational responsibility | Use where control justifies lifecycle cost |
Continue the review
Relevant services & planning resources.
Use these existing routes to deepen product, delivery and technical decisions.
09
Detailed FAQ
Questions that change the plan.
01Is this a ready-made product or a final proposal?+
Neither. It is a validation dossier showing the questions, systems and evidence a food-delivery marketplace scope should resolve. A proposal follows discovery of the actual territory, business model, foundation and integrations.
02Can a familiar marketplace be used as the first reference?+
Yes, as a conversation aid for workflows and expectations. The resulting name, brand, copy, assets and interface should be original, and any code, data or content used must have appropriate rights.
03Does V1 include all modules shown here?+
No. The page maps the complete operating domain. V1 is the smallest coherent slice selected in the signed scope; V2 candidates and exclusions remain outside until expressly added.
04How are delivery charges, commissions and courier earnings decided?+
Through configurable commercial rules approved for the operating territory. This dossier deliberately does not invent rates or amounts; tax, consumer and worker-model implications require qualified review.
05Can restaurants use their existing POS?+
Potentially. Feasibility depends on each POS vendor, API access, market, menu model and acknowledgement capabilities. The design should include monitoring and a manual or degraded-mode decision.
06Can one platform support multiple cities or countries?+
It can be architected for zones, currencies, languages, brands or tenants, but multi-country launch materially changes legal, tax, payment, privacy, support and configuration requirements.
07Who handles refunds and delivery disputes?+
The product can provide policy-based workflows, permissions, evidence and audit history. The operator remains responsible for approved policies, trained decision-makers and compliance with payment-provider and local consumer rules.
08Is app-store approval or legal compliance guaranteed?+
No. The build can prepare evidence and implement agreed controls, but platforms and regulators make their own determinations and rules change. Independent legal, tax, privacy, employment and accessibility advice may be needed.
09What is needed from the operator before build?+
Named decision-makers, target markets, commercial and fulfilment model, policy owners, provider preferences, brand direction, representative menus, operations participants and timely access to required accounts.
10What does handover mean?+
The contract should enumerate repositories, custom outputs, licences, third-party accounts, credentials, documentation, training, support and acceptance. Rights are allocated by that agreement rather than assumed from a generic page.
Read before use
First-reference naming & IP note
“Clone” describes using a familiar product category or named service as an initial functional reference. It does not authorise copying. A project should use an original name, identity, interface expression, copy and assets. No affiliation, endorsement or compatibility with any referenced company is implied. The operator must have rights to all supplied code, data, menus, media, marks and other materials; third-party names remain the property of their respective owners.
Page-specific disclaimer
This page is an illustrative validation artifact, not a live product, client case study, binding scope, quote, delivery schedule, warranty, legal opinion, compliance certification or promise of app-store approval, provider availability, market performance or operational outcome. Features, architecture, deliverables, rights, support, security controls and acceptance criteria are confirmed only through discovery and a signed agreement. Payment, map, messaging, cloud, POS, analytics and identity services are subject to provider capabilities, terms, fees and regional availability. Privacy, consumer, tax, food, accessibility, employment, courier, insurance, invoicing and age-restricted-item obligations vary by jurisdiction and operating model; obtain qualified local advice. Any refund, cancellation, dispatch, verification or retention rule shown here is a design prompt to be replaced by an approved policy.
Validation starts with decisions
Turn the reference into an original operating plan.
Bring the market, model and must-have loop. Leave with clearer boundaries, risks and a build-path decision.
Request a validation conversation