Prep times are one of the first ways an online ordering page earns trust
OmNom gives restaurants a direct ordering path with zero commission and zero monthly platform fees. Standard Stripe processing still applies. That cost structure matters, but a direct ordering page still has to make realistic promises once a customer taps "order now."
One of the fastest ways to lose that trust is a bad prep-time estimate.
If the page says pickup will be ready in 15 minutes and the kitchen needs 28, the customer blames the restaurant. Staff have to apologize, the front counter gets tense, and the next order starts from a weaker position. The reverse problem is not great either. If every order is padded to 45 minutes just to stay safe, some customers will abandon checkout before the kitchen even sees the ticket.
That is why prep times deserve their own setup decision. They are not filler text. They are the promise that connects the ordering page to the actual line.
Start with the pace your kitchen can hit on an ordinary shift
Many restaurants set prep times by aiming for the best-case ticket, not the real one.
That usually sounds like this:
- fries drop fast
- the burger station is usually quick
- the salad only takes a minute to plate
- the kitchen can move fast when everything goes right
But customers do not order inside a best-case scenario. They order during lunch, during halftime, during the Friday rush, while a catering pickup is being bagged, or when one station is down a person.
The safer place to start is the time your kitchen can hit consistently on a normal, not perfect, shift.
For most restaurants, that means asking:
- How long does a simple pickup order really take when the line is moving normally?
- Which station usually sets the pace?
- Which popular items slow the whole order down?
- How much bagging and handoff time needs to be included?
If the honest answer for a standard order is closer to 20 or 25 minutes than 10 or 15, build the promise around the honest number. A believable estimate converts better over time than a fast estimate that repeatedly breaks.
Use one base window and a few clear exceptions
Restaurants do not need a complicated timing model on day one.
In most cases, a simple structure works better:
- Set a default prep window for ordinary orders.
- Add a longer rule for large or highly customized orders.
- Add a rush-period buffer when the kitchen predictably slows down.
That is enough for many operators to stop making obviously wrong promises.
For example, a restaurant might decide:
- standard pickup orders default to 20 to 25 minutes
- orders above a certain item count move into a longer window
- family packs, trays, or combo-heavy tickets get extra time
- Friday dinner and Sunday brunch carry a built-in buffer
This is better than pretending every order deserves the same estimate. The goal is not perfect mathematical precision. The goal is to keep the ordering promise close enough to reality that staff are not constantly recovering from it.
Build the customer promise around the slowest part of the order
Customers experience the whole order, not the fastest item in the cart.
If one dish takes 22 minutes and the other items take 8, the useful prep estimate is still driven by the 22-minute dish. The bag cannot leave without it.
That sounds obvious, but restaurants often set pickup estimates based on the median item instead of the ticket that is actually being assembled. That is how an ordering page can look fast while the expo station keeps telling guests to wait "just a few more minutes."
A better rule is simple: set the estimate based on the part of the order most likely to hold the handoff.
That often includes:
- proteins with longer cook times
- pizzas and baked items
- fried food during peak demand
- items with many modifiers
- mixed tickets that touch several stations
- large drink or dessert add-ons that still need staging
If those items are common, the published prep window should respect them. It is better to surprise a customer with an order that is ready a little early than to train them not to believe the ready time at all.
Give yourself a rush buffer before the kitchen needs rescue
The worst time to rethink prep times is after the screen is already full.
Busy dayparts are predictable for most restaurants, even if the exact volume changes. Lunch, dinner, post-school pickup, game-day rushes, and weekend brunch all create their own traffic pattern. If a restaurant knows the kitchen typically slows down during those periods, the ordering promise should change before customers start stacking unrealistic pickup slots.
That does not mean shutting online ordering off at the first sign of pressure. It means deciding in advance:
- when to add a buffer
- how much extra time the buffer should add
- who is responsible for switching to the slower promise
- when the kitchen has recovered enough to remove it
Even a modest buffer can prevent a messy front-of-house cycle where staff keep telling arriving guests that every order is running 10 minutes late. The customer would rather see a realistic time on the ordering page than hear a correction after they have already left home.
Large orders should not borrow the same promise as small ones
A 3-item pickup and a 14-item office order are not the same job.
Restaurants sometimes let large tickets flow through the same timing logic because the ordering system makes that easy, but operations usually pay for that shortcut later. One oversized order can pull attention away from a dozen smaller tickets, especially if the kitchen is also handling dine-in or phone orders.
Large-order timing rules do not need to be fancy. They just need to exist.
Useful triggers include:
- total item count
- number of entrees
- catering-style trays or bundles
- heavy modifier combinations
- orders placed close to a known rush
When that rule is clear, the ordering page can protect the line instead of surprising it. This is especially important for direct ordering because the restaurant owns the customer expectation more directly. If the order link is yours, the promise should sound like it came from your actual kitchen.
Test the promise from both sides of the counter
Before pushing traffic hard to a direct ordering page, run a few realistic checks.
Look at the ordering page like a customer:
- Does the prep window feel believable?
- Does the page make pickup timing easy to understand?
- Does a larger order show a different expectation when it should?
Then look at the same setup like the staff:
- Could the kitchen hit that promise during a normal rush?
- Does the handoff team have enough time to bag, label, and stage the order?
- Would anyone need to call the customer just to reset the ready time?
If staff would not trust the estimate, customers should not see it yet.
This is one reason a clean direct ordering setup matters. The restaurant should control the promise and then pressure-test it against real service, not hope that a generic default happens to fit the kitchen.
Where OmNom fits
OmNom is a strong fit for restaurants that want direct online ordering without adding another commission layer to the order itself. Restaurants pay no OmNom commission and no monthly platform fee. Standard Stripe processing still applies.
That simpler pricing model gives operators room to focus on the parts of ordering that customers actually feel: a clear menu, a believable pickup promise, and a handoff that matches what the page said would happen.
OmNom can also help with menu setup, which matters because prep times are easier to get right when the menu structure, modifiers, and ordering flow are already clean. If you are still tightening the menu before launch, read the Restaurant Online Ordering Menu Checklist. If you are trying to get direct ordering live quickly, start with how restaurants can launch online ordering in 15 minutes.
When the menu is ready and the timing promise is honest, the ordering page has a much better chance of feeling reliable from the very first week. If that is the setup you want, start from OmNom.