Most delivery conversations start in the wrong place: which company should carry the food. The more useful question is who decides. Once the decision is yours, made by a rule you wrote, the carrier becomes an operational detail you can change on a Tuesday rather than a platform you are married to.
What dispatch actually decides
Dispatch is the moment between a ready order and a courier holding it. Orders arrive from your website, your apps, a kiosk, the call center, your AI Ordering Agents and the marketplaces you still list on, and they all enter the same queue. Dispatch answers one question for each of them: who takes this, and when. Everything else, including the tracking the customer watches, follows from that answer.
There are three answers, and a business of any size will use more than one of them in the same week.
Model one: your own fleet
Employees or contractors, working on the Driver App. You set the zones, the fees, the shifts and the payouts. Assignment happens automatically by distance, load and who is on shift, with nearby orders batched, or drivers accept from a pool if that is how your team prefers to work.
The driver gets pickup, navigation, customer chat, cash handling and proof of delivery with a photo or a signature. You get the most control over cost per order and the part that is harder to price: the person at the door is yours, wearing your brand, and the data about how that delivery went stays in your system.
Model two: a partner network
Connected courier networks can fulfill orders placed in your own channel. Ordering.co lists integrations including Uber Direct, DoorDash Drive and Lalamove. Confirm account eligibility, address-level coverage, fees and tracking behavior for each store before relying on a partner.
A partner can help test a new delivery territory without first recruiting a fleet, provided onboarding and local service availability are confirmed.
Model three: hybrid, and the rule underneath it
The common answer is both. Your drivers take what they can, and the orders they cannot take fall to a network automatically. The rule is the product here, and it is worth being explicit about which of these you want:
- Overflow: your drivers are all out, so the next order goes to a network instead of waiting
- Out of zone: the address sits past your own delivery polygon but inside a partner's coverage
- By hour: your fleet works the lunch and dinner peaks, a network covers late night
- By store: a location without drivers of its own runs entirely on partners
- By cost or time: whichever quote is cheapest, or whichever arrives first, on a threshold you set
Define the selection and fallback rules per store with the available connector. Demonstrate each rule, including unavailable couriers and out-of-zone addresses, before relying on it in production.
The goal is not to own every driver. It is to own the rule that decides which driver takes the order.
Dispatch path: one order queue feeds a dispatch rule, which assigns either an own-fleet driver in the Driver App or a partner-network courier. One queue, one rule, two kinds of courier behind it.
The customer sees one tracking page
Customers follow the status available to their order. A connected courier may supply its own tracking link, while your own Driver App supports the local delivery workflow. Check the actual map, ETA, notifications and support handoff for each provider; not every external tracking page can be restyled.
Preserve the order reference and support contact through a provider change so customers can still get help if an event or location update is delayed.
How to choose, in practice
Start with the model that matches the volume you have today, not the one you want in a year. A single busy location with steady delivery demand often justifies its own drivers. A network of stores with uneven demand tends to start on partners and build a fleet in the locations where the density justifies it.
What matters is that the second decision is not a rebuild. Zones, fees, shifts, fallbacks and payouts are settings in the same system, so the model can follow the business instead of the business following the model.
Compare fleet and couriers city by city
Calculate owned-fleet cost per completed delivery as driver pay, payroll costs, vehicles, insurance, fuel, dispatch, software and failed-delivery costs divided by completed deliveries. For partners, include delivery invoices, waiting and cancellation fees, software, support and failed attempts on the same denominator. For hybrid operations, add both cost pools and count each completed delivery once. Subtract customer delivery-fee revenue separately to show the net subsidy. Keep marketplace acquisition commissions separate from last-mile costs.
Repeat the calculation by city, store and shift with matching date ranges. Dense dinner routes and dispersed off-peak deliveries can produce different decisions. Assign store teams to readiness and handoff, dispatch to acceptance and fallback, the courier to transport under its contract, and support to customer communication and claims. Do not assume outsourcing removes your customer-service responsibility.
A POS integration needs more than a logo. For Toast or another POS, demonstrate order creation, modifiers, acceptance, readiness, cancellations and status return in the proposed connector. For a replacement fleet system, include driver onboarding, app usability, proof retrieval and report exports in the pilot. Confirm setup fees and responsibilities without assuming any named POS connection is available for your account.
Ordering.co supports assignment, grouping with traffic-aware estimates and Google Maps or Waze navigation; it is not a full route optimizer. Compare driver reports across the same filters, and use the fleet operating page to scope the workflow rather than expecting universal commission savings.