A WooCommerce delivery date must reflect what operations can actually fulfil. Displaying a calendar and disabling a few weekdays is insufficient. Availability may depend on postcode area, route, daily capacity, time slot, cut-off, collection capacity and orders already placed or temporarily reserved.
The calendar is therefore the final step of a planning decision, not its source.
From date field to delivery promise
When a customer chooses a date, it creates an expectation that the online store, administration, warehouse, planning and customer service must share. Store the chosen time as a recognisable part of the order and pass it to the relevant systems.
A good model distinguishes:
- the selected delivery or collection date;
- a time window, if operations use one;
- the logistical zone or route on which the choice is based;
- the reservation status before and after payment;
- later changes and who made them.
An isolated text entry in an order note is too weak for this. Use structured order data that is also available through the WooCommerce API.
Calculate availability with business rules
Start with the delivery address. A postcode can determine which weekdays a route serves an area. Then exclude closed days and days beyond the ordering cut-off. Finally, check whether the day or time slot still has capacity.
A simplified sequence is:
- normalise and validate country and postcode;
- determine the appropriate delivery zone and allowed weekdays;
- apply minimum preparation time and the daily cut-off;
- exclude manually blocked days;
- subtract confirmed bookings and active temporary reservations;
- show only times that are currently bookable.
Collection often has different rules. A location may use fixed time slots with its own capacity and closing time. Do not mix delivery and collection rules into one generic date field.
Reserve capacity during checkout
Two customers may select the last available time almost simultaneously. If capacity is checked only after payment, both may be promised the same place. Create a short-lived reservation when customers choose a time.
Such a hold must be linked to checkout, count towards capacity and expire automatically if the purchase is not completed. If the customer changes the time, release or replace the old reservation. The final order then takes over the place in a controlled way.
Concurrency must be handled on the server; a browser check is insufficient. The server ultimately decides whether capacity is available.
Design a safe fallback
A planning service may be temporarily unavailable. Decide beforehand how checkout responds. Blocking entirely prevents an invalid promise but may also stop every sale. A fail-open process can accept the order while clearly stating that its delivery time will be confirmed manually.
The appropriate choice depends on the product, delivery promise and operational flexibility. Crucially, the fallback must become a visible task. An order without a confirmed time must not silently join normal orders.
Apply the same rules to changes
A customer or employee changing the date after purchase must be checked again against capacity, zone and cut-off. An address change may require another route or delivery day. Do not simply overwrite the address while retaining the existing plan.
Retain the previous and new choices, check whether the order may still be changed and update all relevant representations together. Prevent a planning update from triggering the same action again as a webhook echo.
Test more than the calendar
- A postcode on the boundary between two zones.
- Two simultaneous checkouts choosing the last time slot.
- A customer changing the date several times.
- An abandoned checkout whose reservation must expire.
- An order around the moment the cut-off takes effect.
- A shipping method changed from delivery to collection.
- A temporarily unreachable planning service.
- An address changed to a different logistics zone.
Make planning explainable
Customers do not need to see the full calculation, but an understandable reason helps. ‘Unavailable for this postcode area’ or ‘this time slot is full’ is better than a grey date without explanation. Customer service must also be able to see why a time could or could not be selected.
The ForaVida case study shows how the online store, AFAS and route planning are connected in one process. On Yindle Connect you can see how validation and distribution between these systems are configured. For the general architecture, see reliably integrating an online store and ERP.
Frequently asked questions about delivery times
Does the calendar itself need to know all the capacity?
No. The browser requests and presents available times, but the server calculates and confirms the arrangement. This keeps the same rule in place for checkout, customer service and any other sales interface. A manipulated request cannot bypass the capacity check.
What happens to a time slot if payment fails?
Do not make the temporary reservation permanent immediately, but hold it long enough for a normal return from the payment flow. When checkout is cancelled or expires, release capacity in a controlled way. Link the final reservation to the confirmed order status that counts as acceptance in your process.
How do you handle holidays and exceptions?
Alongside recurring weekday rules, use a manageable calendar for closures and exceptional days. An administrator must be able to record the reason and scope without changing code. Check existing bookings before closing a day and show affected orders as tasks.
Monitor the quality of the delivery promise
Track more than how many slots are filled. Also look at orders without a confirmed time, expired holds, manual rescheduling and differences between the chosen and actual delivery day. Use these signals to improve cut-offs, capacity or zone configuration, without promising savings percentages that have not been measured.
WooCommerce uses its documentation on delivery dates and time slots to describe the common checkout interaction. For processes involving external planning and shared capacity, the underlying server decision must also be safeguarded across all systems involved.
Want to turn a date field into a delivery promise you can fulfil? Discuss your capacity and delivery rules with Yindle.