Delivery availability is an operating promise
Delivery can look like a simple toggle: on or off.
For a restaurant, it is not that simple. The ordering page is making a promise before the kitchen ever sees the ticket. It is telling the customer that the restaurant can prepare the food, a driver can be found, the order can travel well, and the timeline will still make sense by the time it reaches the door.
That promise should not depend on luck.
If there is no dispatchable driver capacity, delivery should not appear as available just because the restaurant technically offers delivery. Saying no early is better than taking an order the operation cannot complete cleanly.
OmNom is built around that kind of direct ordering discipline. Restaurants pay zero OmNom commission and zero monthly platform fees, while standard Stripe processing still applies. But the lower restaurant-side platform cost only matters if the ordering flow also protects trust.
Driver capacity should be checked before checkout
The worst time to discover a capacity problem is after the customer has already built a cart.
By then, the guest has chosen items, entered details, and decided that delivery is possible. If the order fails late, the restaurant gets the frustration even if the real issue is driver availability.
A healthier direct delivery flow checks capacity before it makes the promise:
- Is the restaurant delivery-enabled?
- Does the restaurant have the right location and delivery zone configured?
- Is the customer close enough for the restaurant to serve well?
- Is there a dispatchable driver available for that zone right now?
- Is delivery still a good option for the current hour and kitchen load?
If the answer is no, the ordering page should steer the guest toward pickup instead of pretending delivery might work.
This is not about being negative. It is about making the available choices reliable.
Do not treat waitlist presence as capacity
A driver who might become available later is not the same as a driver who can take the next order.
Restaurants can get into trouble when delivery availability is based on soft signals: someone is usually nearby, a driver has been online recently, or the restaurant expects delivery to be possible after the rush.
Those signals may be useful for planning. They should not be enough to promise delivery at checkout.
For customer-facing availability, capacity needs to mean a real driver can be dispatched under the current rules. If drivers are only waitlisted, paused, overloaded, out of zone, or unable to accept another offer, the ordering page should not sell delivery as if the path is ready.
That protects the guest from a late disappointment. It also protects staff from having to explain why an order that looked accepted online cannot actually leave the restaurant.
Keep pickup visible when delivery is unavailable
Hiding delivery does not mean hiding the restaurant.
When delivery is unavailable, pickup should still be easy to choose if the kitchen can support it. The customer should understand that the restaurant is open for direct ordering, but delivery is not currently offered for that address or moment.
That distinction matters. A guest who wants dinner from the restaurant may be willing to pick up if the alternative is no order at all. A guest who sees a broken delivery promise may lose confidence in the ordering page.
Use the unavailable state to keep the decision simple:
- show pickup as the reliable option
- avoid vague language like "try again later" when the reason is capacity
- do not let the guest reach payment for an impossible delivery order
- keep the direct ordering link active for future pickup and delivery attempts
For more on protecting pickup before expanding delivery, read Restaurant Pickup Order Handoff: How to Keep Direct Orders Moving.
Capacity rules should match the delivery radius
Driver capacity and delivery radius belong together.
A restaurant may have a driver available, but that does not mean every address should be eligible. Longer routes increase travel time, food-quality risk, and the chance that one driver stays unavailable for too long.
That is why a compact delivery area is easier to operate than a wide one. It gives the restaurant a cleaner promise: delivery is available when the customer is close enough and the driver pool can actually support the order.
If the radius is too wide, capacity becomes harder to trust. One distant order can absorb driver time that might have served several nearby orders. The restaurant may technically be "available" on the map while the real operation is strained.
Keep the radius honest. Then let capacity decide whether delivery should appear in the moment.
For a deeper radius framework, read Restaurant Delivery Radius: How to Keep Online Ordering Reliable.
Driver-first dispatch protects the restaurant
Restaurants should not have to accept delivery orders that no driver can move.
In a better direct delivery flow, the driver path is checked before the order becomes a restaurant-visible commitment. That means the order is not treated like a normal pickup ticket first and then casually handed to delivery later.
This matters operationally. If the restaurant sees the order before a driver accepts it, staff may start cooking food that cannot leave. If the customer is fully committed before dispatch is real, the restaurant may have to refund, remake, or explain a failure it did not cause.
Driver-first dispatch keeps the sequence cleaner:
- the customer chooses delivery only when delivery is truly available
- payment authorization can happen before final commitment
- drivers get the chance to accept before the restaurant is locked into the order
- the restaurant sees the delivery order once the delivery path is real
That is a stricter workflow than "turn on delivery and hope." It is also more honest.
Watch the reasons delivery becomes unavailable
Unavailable delivery should teach the restaurant something.
If delivery is almost always unavailable, the restaurant may need more driver coverage, a tighter radius, different hours, or a pickup-first launch period. If delivery disappears only during the dinner rush, the issue may be kitchen timing or driver load. If certain addresses often fail eligibility, the map may be wider than the food can support.
Track the pattern before changing the promise.
Useful questions include:
- Which hours lose delivery capacity most often?
- Are customers outside the intended radius trying to order?
- Does pickup still convert when delivery is unavailable?
- Are drivers declining because the route is too long?
- Are prep times realistic enough for driver handoff?
The goal is not to force delivery open. The goal is to understand what the direct ordering system is telling you.
Where OmNom fits
OmNom is built for restaurants that want direct ordering economics without turning delivery into a vague marketplace-style promise. Restaurants pay zero OmNom commission and zero monthly platform fees. Standard Stripe processing still applies.
For delivery, OmNom's position is practical: delivery should only be offered when the restaurant is enabled, the customer is close enough, and there is real driver capacity for the zone. If the capacity is not there, pickup should remain the clean path.
That may feel conservative. It is also how restaurants protect the channel.
An online ordering page earns trust by showing choices that work. Say yes when the restaurant can fulfill the promise. Say no early when it cannot. Then use the pattern to decide whether the next move is a tighter radius, more driver coverage, better prep timing, or a pickup-first operating plan.
If you are deciding how delivery should fit into direct ordering, read Tipless Restaurant Delivery: How to Set a Subsidy Without Guessing. If you are ready to set up direct ordering, start from OmNom or open the restaurant app.