Lead Times and Pickup Windows for Food Businesses — The Guide

A pastry chef gets an enquiry: a wedding cake, pickup on Saturday. Can he say yes?

The cake needs two hours of work, then two days in the fridge, then another thirty minutes for decoration. The work has to fall inside his production hours — he isn't standing in the kitchen at three on a Sunday morning. The chilling time, on the other hand, runs by itself, weekend included.

Ask him how he calculates it and he says: "Hard to tell. I quote seven days, then there's always a weekend in there."

That isn't a calculation, it's a safety cushion. It works — and it costs him orders, because he turns away customers he could have served.

This guide sets out the variables you need in order to genuinely calculate the answer to "When can I pick this up?" It is written for businesses that sell online, and for anyone configuring or building an ordering system.

Why the question is so hard

Because three completely different things are bundled inside it, and almost everyone mixes them up:

1. Durations — how long something takes
2. Schedules — when something is allowed to happen
3. Capacity — how much can run at once

The pastry chef has a duration problem. The pizzeria has a capacity problem. The food retailer has a pure schedule problem. Squeeze all three into a single field called "lead time in days" and you get a wrong answer for every one of them.

Separate them cleanly, and every business fits the same model.

This guide covers the first two. Capacity is the third variable; it has rules of its own and gets an article of its own.

First: which point in time are you actually calculating?

Before anything gets computed, it has to be clear which moment is meant. An order contains at least five:

Order → Production start → Ready → Handover → Delivery

"Handover" is either the customer collecting the order or the carrier accepting the parcel, depending on the route. If you don't separate these points, you end up promising a delivery date while meaning a completion time.

Two directions of calculation follow from this, and you need both:

Forward — from now to the earliest possible date. This is the as-soon-as-possible question: "How fast can I get it?"

Backward — from the requested date to the latest possible production start. This is the pre-order question: "Is Saturday at 2 pm possible?" Only the backward calculation can decline a requested date before it has been confirmed.

The starting point for all of this is server time at the location of the business, not the clock in the customer's browser. Otherwise every guest with a different device setting gets a wrong answer, and at every daylight-saving change everyone does.

Building block 1: a duration is not a number

A duration consists of two pieces of information:

The schedule it runs on. Work runs on the production schedule. Chilling runs on a schedule with no restrictions at all — call it 24/7. A shipping time runs on the carrier's schedule.

Whether it can be split, that is, spread across several time windows. Two hours of uninterrupted work usually cannot be split into one hour on each of two consecutive days.

That's all you need. The distinction people often add on top — "attended or unattended", meaning whether staff are required — is already contained in the schedule: whatever runs on the production schedule occupies someone. Whatever runs on 24/7 runs by itself.

This explains the pastry chef's problem completely. A single field reading "lead time: 50 hours" cannot capture the difference. It either counts the chilling time as working hours — in which case the cake is finished far too late — or it counts the working time as calendar hours, in which case the system confirms a slot when nobody is in the kitchen.

Durations are a sequence of steps, not a sum

The second half of the same problem: production consists of ordered steps, as many as you like, each with its own schedule.

1. Bake and assemble   2 h      Production schedule
2. Chill              48 h      24/7
3. Decorate           30 min    Production schedule
4. Pack               10 min    Production schedule

Only this ordering makes it visible that the last step has to fall inside a production window as well. A cake that comes out of the fridge at six on Saturday morning is not finished if forty minutes of work remain and the kitchen isn't staffed until eight.

A side effect: packing and setup times need no concept of their own. They are steps like any other.

And the order itself is a definition. If chill → decorate silently becomes decorate → chill, the result still looks plausible — but the cake cannot be produced that way.

The seven-day trick, and why it can still be right

Back to the pastry chef. His rule — "seven days, then there's always a weekend in there" — is justified incorrectly: the chilling time doesn't need a weekend, it runs regardless. The actual constraint is:

Two hours of work must fit into a production window that ends at least 48 hours before the final working step — and that step in turn must fit into a window before the pickup time.

His rule isn't stupid, though. It is a minimum lead time — a deliberate cushion for everything the model doesn't know about: illness, supply problems, a full order book.

So both values belong in the system, and they combine like this:

Effective lead time = max(calculated step sequence, minimum lead time)

The model calculates, the business has the last word. And because the minimum can be set per customer group or sales zone, the same pastry chef can demand seven days from private customers and three from a café.

Building block 2: schedules, and why public holidays are not days off

This is where most systems built for logistics or office work fail, because they carry an assumption that is simply false in food:

In food businesses, public holidays are not days off. They are the busiest days of the year.

Good Friday, Easter, Mother's Day, Christmas — those are the days when a pastry shop makes its annual figures. A system that hard-wires "holiday = closed" is unusable in this trade.

The consequence: instead of a statutory holiday calendar, every schedule gets its own closing days. The business defines when it doesn't work, regardless of what the official calendar says.

A business works on its own closing day

This isn't only about different businesses having different closing days. It happens within a single business:

The pastry shop is closed on Mondays. No sales, no pickups. They bake anyway — otherwise there'd be nothing on Tuesday.

A single business calendar cannot express this. Separate schedules for production and handover can.

Which schedules you need

Production schedule — when work actually happens. In many bakeries that starts at three in the morning; the shop opens at eight.

Pickup points — more on these shortly, each with its own schedule.

Delivery times — a schedule of their own, usually with quotas.

Carrier schedule — the one place where a real holiday calendar survives. Carriers genuinely don't run on public holidays, and which days those are varies by region. An individual business can neither know nor maintain this; it only picks its region.

24/7 — a schedule with no windows and no closing days. Sounds trivial, but it matters: it means unattended time is not a special case in the system. Chilling, working and shipping times all go through the same calculation, they just carry a different schedule.

Opening hours — and here comes the surprise: these don't enter the calculation at all.

Opening hours are a statement to customers, not a constraint

Opening hours describe when somebody is in the shop. They belong on the contact page. They only matter to the calculation if a pickup point happens to be located in the shop — and even then it is that pickup point's schedule that counts, not the shop's opening times.

They do have one practical use, though, as a fallback: if a business has configured nothing else, its opening hours are the best available assumption.

That is more than a convenience. It is the difference between a model that is powerful and one that is powerful and usable. A time model with six schedules doesn't fail in practice because of its logic — it fails because nobody fills in six schedules. Opening hours are the one field every business maintains, because it is visible. Make it the default for the invisible calculation and a business is up and running with zero configuration.

A pickup point is an object in its own right

The obvious modelling choice would be a "pickup calendar" attached to the business. It's wrong, because the constraint is physical rather than organisational. A business can have several pickup points, each with its own schedule:

• A bakery with a counter (opening hours), a collection locker (24/7) and a market stall (Saturdays 8 am–1 pm)
• A pastry shop: normal collection in the shop, but wedding cakes only via the side entrance by arrangement
• A restaurant: the takeaway hatch opens at 11, the dining room at 12

None of these can be expressed with a single pickup calendar. With pickup points they are simply three objects.

One display question follows from this: "earliest pickup from…" becomes answerable once the customer has chosen between collection and delivery. A hint such as "Earliest Friday 10 pm at the collection locker, in the shop from Saturday 9 am" answers the question and sells the locker at the same time.

What "business days" actually means

As soon as a duration refers to a schedule, "business days" dissolves as a special unit. "5 business days" simply becomes: 5 days, counted on the carrier's schedule. And "2 days of chilling" becomes: 2 days, counted on the 24/7 schedule.

One subtlety remains, and it costs real money:

Work finishes Friday at 4 pm. Plus two days of chilling — Sunday 4 pm, or Sunday midnight?

Counted as a rolling duration it is 48 hours, so Sunday 4 pm. Counted as calendar days it would be Sunday at midnight — eight hours early, and in the dangerous direction. With shipping it's the other way round: "5 business days" means counted days, not 120 rolling hours.

The rule needs no field of its own, it follows from the schedule:

On a schedule with no windows, days are rolling. On a schedule with windows or closing days, days are counted.

The fulfilment method determines the type of promise

Collection, own delivery and carrier shipping are not variants of the same process. Each brings its own schedules, its own lead times and its own capacity — and above all its own type of promise:

The distinction isn't cosmetic. An estimated range is explicitly non-binding; an exact time is a commitment. Present them identically and you create expectations you cannot meet.

The role of production time is a switch

"Production time doesn't really matter for us" — businesses say this constantly, and it means something different every time. Which is why it belongs in the product as a field of its own:

blocking — enters the date calculation. The cake.

informational — shown to the customer but shifts nothing. The paella that takes twenty minutes longer than anything else on the menu.

ignored — stock. The jar of honey that is simply taken off the shelf.

Basket: maximum, not sum — but not always

When someone orders several items, the order is ready when the slowest item is ready, not when all the durations have been added up. The kitchen works in parallel.

In a restaurant that's the whole story, because everything goes to the table together anyway. In hotels it gets more interesting, because partial delivery is normal there:

Four main courses for room service, one of them a paella that takes twenty minutes. Either everything after twenty minutes — or three plates after five and the paella brought up afterwards.

So maximum is the default, not the law. Where partial delivery is possible, the decision belongs to the guest.

And that is exactly what the product warning is for. It isn't cosmetic, it is the basis for the decision. A guest who reads "paella, approx. 20 min longer" before ordering will either swap it, accept the wait, or choose to have it brought up later. Without the note they don't make the decision — they only experience the consequence.

How to display the result

The calculation is one half. The other is the presentation, and a surprising amount of trust is lost there.

Always round up

If the real answer is 14.2 days and you show "approx. 14 days", you have promised something the business cannot deliver. At 15 you are safe.

Later than promised is grounds for a complaint; earlier than promised is a pleasant surprise. That asymmetry has to live in the rounding function, not in somebody's judgement: minutes to the 5-minute grid, hours to the full hour, days to the full day — always upwards.

Short is a duration, long is a date

"Ready in approx. 15 days" is barely usable for someone planning a birthday cake. They have to count it out themselves, and they count wrong, because they don't know whether it starts today or tomorrow. Beyond a certain length, people think in dates, not durations:

A side effect: absolute times don't go stale. A browser tab left open for twenty minutes shows a wrong number if it says "in approx. 20 minutes". "From 6:30 pm" stays correct.

And what's preselected follows the same boundary. For a pizza, as-soon-as-possible is the sensible default. For a cake, almost nobody wants the earliest possible slot — they want one specific Saturday. There the date picker belongs up front, with the earliest date shown as a hint.

"Approx." comes from the type of promise, not from the rounding

A common mistake is to write "approx." whenever something has been rounded. But customers read something else into it, namely: they aren't sure.

A confirmed collection slot is a commitment, even when displayed rounded — no "approx." belongs there. Shipping quoted at five business days is highly uncertain even without rounding — there it always does.

What else you have to define

• Minimum lead time — per fulfilment method and per customer segment
• Cutoff time — "order by 6 pm for tomorrow"
• Pre-order horizon — how far ahead bookings are allowed
• Slot grid — 15 minutes is enough for collection preselection and delivery slots
• Travel time per delivery zone

Four businesses, one model

The test of whether a model holds: do real businesses fit into it without rebuilding anything? Four completely different bottlenecks — and the same engine.

Pastry shop

• Steps — 2 h production schedule → 48 h 24/7 → 30 min production schedule
• Production time — blocking
• Capacity — a limit per day
• Collection — dedicated pickup point with its own schedule
• Delivery — as soon as possible
• Minimum lead time — 7 days for private customers
• Promise — exact time

Pizzeria

• Steps — none relevant to the calculation
• Production time — ignored
• Capacity — 50 per hour in the kitchen, 5 per delivery window
• Collection — as soon as possible, 15 minutes lead
• Delivery — slots between 11 am and 2 pm
• Promise — time window

Food retail

• Steps — none, stock items
• Production time — ignored
• Capacity — no limit
• Collection — pickup point scheduled Friday and Saturday
• Shipping — 5 days, counted on the carrier schedule
• Promise — estimated range

Hotel

• Steps — informational, for the guest
• Production time — informational
• Capacity — a limit per hour
• Collection — as soon as possible
• Basket — maximum, warning on slow dishes
• Promise — approximation

None of this is special-case logic or a branch in the code — it is "only" a different set of configuration values.

The eight most common mistakes

1. Lead time as a single number. The origin of nearly every other mistake.

2. Resting times on the wrong schedule. Dough proves on Sundays too.

3. Treating public holidays as days off. In food they are the busiest days. Closing days belong to the business.

4. Rounding down instead of up. Rounding errors measured in hours go unnoticed until a cake is promised half a day too early.

5. Confusing capacity with duration. The pizzeria does not have a duration problem.

6. Hiding the catalogue when the shop is closed. A customer arriving at 10 pm sees "We're closed" and nothing else — and leaves. If pre-ordering is possible, the product catalogue has to stay visible. The same goes for search engines: they crawl at night.

7. No reservation at the time of ordering. Leads to overbooking in exactly the slots that are scarce.

8. Sum instead of maximum in the basket. Drives customers away with wildly overstated waiting times.

Checklist

Before you configure or commission an ordering system:

• Which point in time is being promised — ready, handover or delivery?
• Can the system calculate backwards, or only forwards?
• Can a duration state which schedule it runs on?
• Can any number of production steps be modelled in a fixed order?
• Does every schedule have its own closing days, independent of public holidays?
• Can exceptions be set in both directions, closing and opening?
• Are pickup points objects in their own right, with their own schedules?
• Can production and delivery capacity be configured separately?
• Is capacity reserved at the time of ordering?
• Does the display always round up?
• Is "open or closed" determined server-side at the location of the business?

If any question is left open, you now know where the system will cost you orders later on.

Why this matters right now

Customers increasingly ask AI assistants rather than search engines: "Where can I get a cake for twelve people on Saturday?"

For an assistant to answer that, it needs a machine-readable answer to "by when is this feasible?". That is exactly where a clean time model pays off: it isn't just configuration, it is structured availability data. A business that has it can be found. A business whose website says "lead time on request" cannot.

The OIDO Online Shop is shop software for bakeries, pastry shops, butchers, delicatessens, caterers and food service businesses that sell online themselves. You configure production steps with their own schedules, schedules with their own closing days, any number of pickup points, and quotas per time slot.

Try it, no commitment →