The date on the checkout page is a promise.
You make it before anyone has looked at tomorrow's capacity.
OkPilot ecommerce delivery software sets the date customers see at checkout from your real order cutoff and your measured daily capacity, not from a hopeful estimate, and captures proof at the door so a disputed drop does not turn into an automatic refund. Built for online and retail delivery operations that run their own drivers or a managed fleet.
A slightly later date, reliably met, is cheaper than an earlier one missed.
The promise is made by a checkout page at eleven at night. The capacity is known by a depot at six the next morning. Nothing connects the two, so the date is usually set by whatever the marketing team thought was competitive, or by a flat rule that has not been looked at since it was written.
When the date slips, the cost is not the delivery. It is a contact into support, often two. It is a goodwill refund on the shipping, sometimes on the order. And a meaningful share of those customers do not come back, which costs far more than the parcel did.
The honest answer is that nobody can tell you the right buffer, because it depends on your own miss rate and your own cutoff. What you can do is measure both, pick a date you hit nearly every time, and stop competing on a number you cannot deliver.
What happens when you type "Can we still promise Thursday?"
“Can we still promise Thursday on orders placed today?”
Not for everything. You have 148 orders inside today's 2pm cutoff plus 23 carried over from yesterday, which is 171 against a measured capacity of about 165 stops a day. The two outer postcodes are the overflow. Hold Thursday for the city zones and show Friday for OX and SN, or add a sixth van and keep Thursday everywhere.
It flags the promise before the customer does
Today's order volume is running 18 percent above the last four Mondays. At this rate the Thursday date on the checkout page is not safe past about 3pm. Switch the outer zones to Friday?
Riverside has missed its promised date on 6 of the last 90 drops, all of them in the IP postcodes. Those zones are being promised a day earlier than the depot actually achieves. Add a day there only?
Forty-one orders are sitting unpicked and the van leaves in 50 minutes. Anything not in the cage by then misses the date you already told the customer. Pull the picking list forward?
Your driver sees the promise, not just the next address
The app shows what was actually committed to at checkout, so the driver knows which drops have no slack left and what proof the order needs. At the door it captures what support will be asked for later.
- The promised date and any delivery instruction the customer typed, on the stop itself rather than buried in the order record.
- A photo at the point of handover with time and location attached. For a parcel left in a safe place, that photo is the only thing standing between you and a refund.
- Signature or a one-time code on the orders that need it, and nothing extra on the ones that do not. Requiring a signature on every parcel is how you create failed deliveries.
- A live tracking link to the customer, which cuts the "where is it" contacts that arrive on the promised day.
Tell it what you actually promise
“We take orders until 2pm for next-day. Two depots, about 160 stops a day each. Parcels under fifty pounds can be left in a safe place with a photo, anything above that needs a signature. We would rather quote a day later than miss.”
That is the setup. OkPilot creates:
- A cutoff time per depot that drives the date shown at checkout
- A capacity ceiling per day, measured from what the depot has really been completing
- A buffer per zone, sized from that zone's own miss rate rather than one number for the whole network
- Two proof rules by order value: photo and safe place below the threshold, signature above it
Since 2018
In market
2,000,000+ tasks
Handled
48 hours
To full setup
Ecommerce and retail delivery questions
How does it decide what date to show at checkout?
From three things you control: the cutoff time for the depot that will ship the order, the number of stops that depot has actually been completing per day over the last few weeks, and the buffer you have set for that zone. If today's volume has already eaten the capacity, the next date is offered instead of the one you would rather show.
How big should the buffer be?
There is no industry figure worth quoting here, and anyone who gives you one is guessing. Size it from your own data: take the last 90 days of promised versus actual dates for a zone, and add enough days that you would have hit the promise in the large majority of cases. Most operations find it differs by zone, which is why a single network-wide buffer either over-promises in the hard postcodes or under-promises in the easy ones.
What happens when a date is going to be missed anyway?
OkPilot flags it while there is still a decision to make, before the van leaves, and the dispatcher chooses: move it to a van with slack, split the zone, or notify the customer early. The AI suggests the move and a person approves it. It does not message your customer on its own.
Does it work with our Shopify or WooCommerce store?
Orders come in over an API or a scheduled import, so a store on Shopify, WooCommerce or a custom platform can push orders and receive status back. Setup normally takes about 48 hours, including the order feed. Tell us what your order payload looks like and we will map it rather than asking you to change it.
OkPilot also handles grocery, restaurant, courier. See all delivery features.
See it set your own checkout dates
Book a demo. Bring 90 days of promised dates and actual delivery dates, and we will show you which zones you are over-promising in and what date you could hold instead.