Delivery Time Window Optimizer

A delivery time window optimizer scores candidate appointment slots for each stop using historical first-attempt outcomes. For a given recipient address (or a stable delivery cohort), it ranks windows by predicted success probability and surfaces the top options to the planner or booking flow.

Each suggested window carries two machine-readable fields: a success probability and a cohort ID that identifies which historical segment produced the score. When history is too thin to support a reliable estimate, the model returns an empty suggestion set rather than a weak default. The planner or customer still chooses and confirms the appointment; the optimizer does not book, lock, or override calendar capacity on its own.

The cost outcome is direct. Failed first attempts drive redelivery labor, vehicle miles, and customer contacts. Improving window fit raises first-attempt success and cuts those repeat costs without changing the carrier’s underlying network design.

Redelivery is one of the most expensive failure modes in last-mile operations. A miss is rarely a pure routing error. It is often a mismatch between when the van arrives and when someone can receive the parcel: residential daytime empties, gated access hours, B2B receiving docks with narrow cutoffs, or apartment buildings where lobby handoff only works in evening peaks.

Traditional booking offers fixed templates (morning/afternoon, 2-hour blocks, next-day only) that ignore address-level patterns. A planner who knows a neighborhood well may compensate manually, but that knowledge does not scale across fleets, seasonal demand, or new territories. An optimizer that learns from attempted-vs-successful history can recommend windows that match observed behavior while leaving final appointment control with operations.

This capability pairs naturally with exception handling downstream. When a first attempt still fails, workflows described in failed delivery resolution and delivery exception classification pick up the case. Window optimization reduces how often those paths fire; it does not replace them.

Training data comes from completed delivery attempts: address or stop key, offered or planned window, attempt timestamp, outcome (success, no-answer, refused, access blocked, and similar codes), and optional context such as day of week, product type, or service level. The model groups stops into cohorts so sparse addresses borrow strength from similar neighbors without pretending every door has its own long history.

Cohort definitions typically combine geography (cluster or zone), dwelling or site type, and temporal pattern (weekday vs weekend, morning vs evening). The cohort ID on each prediction lets audit and ops teams see which segment drove the score. That transparency matters when a planner challenges a recommendation or when compliance asks why a customer was offered a particular slot.

For each open capacity window on a planning day, the model outputs a success probability conditioned on the stop and cohort. Ranking is usually by probability, with optional secondary sorts for operational fit (distance to adjacent stops, SLA deadline, premium service). Thresholds decide when to show suggestions at all: below a minimum attempt count or confidence band, the API returns empty so the UI falls back to standard booking rules.

The optimizer does not solve the full vehicle routing problem. It answers “which windows are likeliest to succeed for this recipient?” Route construction, load balancing, and territory assignment remain with the planner or with dedicated solvers. For fleet-level sequencing and cost tradeoffs, see AI-assisted route optimization. Window scores can feed those solvers as preferred time bounds or soft constraints, but ownership of the tour stays outside this use case.

In practice the optimizer sits between CRM or OMS booking and the dispatch plan. A customer or CSR requests delivery; the booking service asks for ranked windows for the ship-to location and service date; suggested slots appear with probability labels or plain-language confidence; the selected appointment is written back as a firm commitment.

On the day of service, ETAs and proactive messages should reflect the booked window, not a fresh model guess. Proactive ETA notification keeps recipients informed as traffic and sequence change. If live conditions invalidate the original slot, exception and redelivery flows take over rather than silently re-ranking the same appointment.

Vendors and platforms that already expose time-window or delivery experience APIs can host or call this logic. Bringg and Onfleet provide last-mile orchestration and customer experience surfaces where preferred windows and success metrics are operational levers. ORTEC and Google OR-Tools address planning and optimization at the solver layer, where predicted success can become preferred intervals or penalties for off-window service. Many operators keep the ML service in-house and push scores into whichever TMS or route engine they already run.

Integration checklist for a first release:

• Stable stop identity (address hash, place ID, or account+location) so history attaches correctly
• Outcome taxonomy aligned with exception codes used elsewhere in the stack
• Explicit empty-response behavior when history is thin
• Planner override that does not penalize the model for manual choices
• Logging of suggested vs booked vs attempted vs succeeded for continuous evaluation

Primary KPI is first-attempt success rate on stops that received a model suggestion versus a matched baseline (same zones, service levels, and demand periods without suggestions, or a holdout). Secondary KPIs include redelivery rate, cost per delivered stop, and contacts per delivery related to “not home” or access issues.

Attribute carefully. Route density, weather, peak season, and product mix all move first-attempt rates. Compare cohorts and periods where those factors are similar, and track suggestion coverage (share of stops with non-empty recommendations) so a thin-history region is not scored as a model failure.

A useful operating rule: only count cost savings on stops where a suggestion was shown, accepted, and attempted inside the booked window. That keeps the metric tied to the optimizer’s actual influence and avoids claiming credit for planner skill or unrelated network improvements.

The model predicts; people appoint. Empty results are a feature when data is insufficient. Planners retain authority to set appointments for VIP accounts, hard SLAs, or access constraints the history does not capture (new construction, temporary roadworks, recipient vacation).

Do not treat success probability as a guarantee of on-time arrival. Congestion, van breakdowns, and upstream depot delays belong to ETA and routing systems. Do not collapse distinct failure modes into a single “miss” label if you need the window model to learn access patterns separately from refusal or address error.

Ownership usually sits with last-mile product or network planning, with data science maintaining the cohort pipeline and probability calibration. Dispatch supervisors need a clear override path and a weekly review of suggestion acceptance versus realized success so the system stays aligned with how the fleet actually works.