Let Customers Choose a Delivery Date

Customers who are not home when the van arrives cost you twice: once for the failed delivery, once for the support ticket that follows. Letting them name the day removes most of that, which is why a date picker at checkout is one of the highest-return additions a WooCommerce store can make. The work is not the field itself — it is making sure every date on offer is a date you can actually hit.

What "choose a delivery date" really requires

Four pieces, in this order:

1. A date field at checkout that saves to the order.
2. Availability rules so unavailable dates are never selectable.
3. Visibility for fulfilment — the order screen, packing slip and picking list.
4. Confirmation back to the customer in the order email and My Account.

Skipping step two is the classic mistake. An open calendar invites Sunday, tomorrow at 6am, and the week you are closed for stocktake.

Availability rules that matter

• Lead time. The minimum number of days between order and delivery. If you pick and pack overnight, that is one working day, not "tomorrow" in calendar terms.
• Delivery weekdays. Close the days you never deliver. Most stores close Sunday; many close Monday too because Sunday has no dispatch.
• Cut-off time. After your dispatch deadline, today and often tomorrow must disappear from the calendar. This is the single most valuable rule and it deserves care — see the delivery cut-off time guide.
• Blocked dates. Public holidays, closures and carrier blackout days. Set them a year ahead; nobody remembers in December. Our blackout dates guide covers the maintenance pattern.
• Maximum horizon. Do not accept a date four months out; you cannot promise stock that far ahead.

Time slots: only if you can honour them

A morning/afternoon choice reduces failed deliveries further, but it is a promise. If your own van does the route you can plan around it; if a national carrier delivers, you usually cannot, and an unmet slot is worse than no slot. When you do offer slots, cap each one — otherwise every customer picks Saturday morning and your route falls apart. That is slot capacity, and it needs a counter, not a hope.

Build it yourself, or configure it

A minimal custom field is genuinely small:

```php add_action( 'woocommerce_after_order_notes', function () { woocommerce_form_field( 'delivery_date', [ 'type' => 'date', 'label' => __( 'Preferred delivery date', 'your-textdomain' ), 'required' => false, 'custom_attributes' => [ 'min' => date( 'Y-m-d', strtotime( '+2 days' ) ) ], ] ); } );

add_action( 'woocommerce_checkout_update_order_meta', function ( $order_id ) { if ( ! empty( $_POST['delivery_date'] ) ) { update_post_meta( $order_id, '_delivery_date', sanitize_text_field( wp_unslash( $_POST['delivery_date'] ) ) ); } } ); ```

What it does not do: block weekends, honour a cut-off, count slot capacity, validate server-side, render in the block checkout, appear on the packing slip, or let a shop manager change the rules. That is the whole gap between a field and a delivery date system, and it is what our Delivery Date & Timeslot for WooCommerce plugin exists to close.

Validation must run on the server

Anything enforced only by the browser's date input can be bypassed by a modified request, and occasionally by an autofill quirk. Re-check the chosen date in `woocommerce_checkout_process` against the same rules and add a checkout error if it fails. The customer sees a clear message rather than you seeing an impossible order.

Getting the date into the warehouse

The date is worthless if the person packing the box cannot see it. Add it as a column in the orders list, sort by it, and print it on the packing slip. Fulfilment teams work from the picking list, not from a plugin settings page.

If you also charge differently for a specific day — a Saturday surcharge, for example — treat that as a shipping rule, not a date rule, and keep the two configurations separate so a pricing change does not silently alter availability.

Measure it after launch

Watch three numbers for the first month: checkout completion rate (a required field can dent it), failed first-delivery rate (this should fall), and support tickets about delivery timing (these should fall faster). If completion drops and failures do not, make the field optional and default it to your standard lead time.