Order-to-Door Fulfilment Control Plane
Food delivery & restaurant fulfilment software
We design fulfilment control planes that connect diners, kitchens, dispatch desks, and couriers — with honest order-state visibility and no invented delivery-time guarantees.
Order-state ownership map
Order states flow across diner, kitchen, dispatch, and courier ownership; exception work is deliberately visible.
STATE 01
Menu discovery
Owner · Customer
Browse venues, menus, modifiers, and availability windows.
STATE 02
Cart & checkout
Owner · Customer + payment
Item selection, fees, and payment authorization boundary.
STATE 03
Kitchen accept
Owner · Kitchen
Venue accepts or rejects with prep-time estimate — not a guarantee.
STATE 04
Prep & assembly
Owner · Kitchen
Line items move through prep states with item-level exceptions.
STATE 05
Ready for pickup
Owner · Kitchen + dispatch
Order marked ready; dispatch queue notified.
STATE 06
Courier assignment
Owner · Dispatch
Match rider to order based on rules and capacity signals.
STATE 07
In-transit
Owner · Courier
Location updates and customer notifications within provider limits.
STATE 08
Delivery handoff
Owner · Courier + customer
Proof-of-delivery capture and completion state.
Order states: Menu discovery, then Cart & checkout, then Kitchen accept, then Prep & assembly, then Ready for pickup, then Courier assignment, then In-transit, then Delivery handoff, then Exception / refund, then Rating & support.
Select an operating model to inspect order states, kitchen/dispatch boundaries, courier integration edges, and fulfilment risks.
Select an operating model to inspect order states, kitchen/dispatch boundaries, courier integration edges, and fulfilment risks.
Multi-venue discovery with platform-owned dispatch and courier pool.
Inspect order state responsibility
Active state: Placed
Owner context: Menu sync · Prep timers · Item 86 · Busy mode · Auto-accept rules
Exception risks: Kitchen timeout cascades · Double assignment · Stale menu pricing · Refund policy drift
Diners / customers
Clear menu, fees, order status, and support paths without false ETA promises.
Restaurant operators
Kitchen panels, prep control, busy modes, and payout visibility.
Dispatch coordinators
Assignment queues, reassign tools, and exception dashboards.
Couriers / riders
Reliable offers, navigation handoff, and handoff proof workflows.
Platform operators
Policy enforcement, refund rules, and operational reporting.
Discovery, cart, checkout, tracking, and support tied to order state.
Accept/reject, prep queues, item exceptions, and ready signals.
Assignment rules, rider apps, and third-party logistics boundaries.
Operational dashboards, refund workflows, and menu governance.
Items, modifiers, availability, and scheduled menu windows.
Fees, tips, promos, and payment authorization.
Explicit transitions with audit and exception branches.
Ticket routing, prep timers, and item-level holds.
Rules engine, manual override, and reassign on timeout.
Offers, pickup, transit updates, and proof-of-delivery.
Status notifications within honest operational bounds.
Policy-driven partial/full refunds with agent review.
Menu import, hours, zones, and compliance document boundaries.
Venue remittance records — finance scope remains client-owned.
Campaign rules without guaranteed uptake claims.
Order lookup, comms templates, and escalation paths.
Prep times, cancellation reasons, and zone load — operational not marketing.
Roles, policies, and feature flags per market.
PCI scope with provider; platform stores tokens/references only.
ETA displays are estimates — not guaranteed delivery times.
Menu and ticket sync contracts vary by vendor.
Delivery notifications subject to carrier and consent rules.
Customer, venue staff, courier, and admin scopes with least privilege.
No raw card storage; processor handles sensitive fields.
Who moved an order and when — critical for disputes.
Accept-to-ready durations by venue and daypart.
Assignment time, reassign rate, and idle courier signals.
Cancellations, remakes, and refund categories.
Order density for staffing decisions — not revenue guarantees.
Food delivery fails when kitchen prep is treated as a black box. Decision table: kitchen owns accept, prep, and ready; dispatch owns assignment; a timeout or item exception routes to support; automated state changes must not override a venue's food-safety decision.
Customers see progress signals derived from real state changes — not marketing ETAs. Maps integrations provide estimates with clear boundaries.
Customer, courier, and kitchen apps share one order record with role-scoped views and offline-tolerant handoff where feasible.
Orders stall when venues do not respond. Mitigation: Auto-cancel or reroute rules with customer notice templates.
Rider accepts but never arrives. Mitigation: Reassign timers, penalties policy, and ops alerts.
Platform and POS/courier states diverge. Mitigation: Reconciliation jobs and unknown-state handling.
Map kitchen, dispatch, and courier ownership before state design.
Define transitions, exceptions, and notification triggers.
Launch ordering or kitchen panel first based on operational priority.
Test timeout, reassign, and refund paths before high-volume periods.
Confirm each order-state owner, exception escalation, and customer notice before expansion.
No. We implement order-state tracking and estimate displays. Actual delivery depends on kitchen load, traffic, and courier availability.
Often yes, via vendor-specific APIs. Menu mapping and status backfeed require a scoped integration contract.
Yes — offer/accept, pickup, transit, and proof-of-delivery flows with dispatch integration.
Policy-driven workflows with partial/full paths and agent review. We do not automate chargeback outcomes.
Share your kitchen, dispatch, and courier constraints — we will map order states without overclaiming delivery times.
Discuss your industry workflow