SAP Delivery Slot Booking

How SAP derives a delivery date today

SAP’s delivery-date logic is more sophisticated than a plain date picker. It is still route-blind, because the routing plan lives outside core S/4HANA.

• aATP (advanced Available-to-Promise). Confirms whether material is available against demand. Proposes a Material Availability Date. Inventory-centric.
• Delivery scheduling. Adds transit time, loading time, pick / pack time and goods-issue lead time to the Material Availability Date to derive a Requested Delivery Date and Goods Issue Date. Driven by configurable shipping point and route master data, not by today’s actual vehicle availability.
• SAP Commerce Cloud checkout. The storefront can call aATP and delivery scheduling at checkout to offer a date. Still inventory-and-transit-time-based, not route-aware.
• Customer portal / self-service reschedule. Where deployed, customers can request a different date; the request lands as an update on the outbound delivery and waits for back-office processing.
• CSR workflow. A CSR taking a phone order works from the same date logic. Whatever the system proposes, the CSR confirms.

None of those queries the actual optimized route plan or the day’s remaining own-fleet capacity. The first time anyone checks whether the proposed date fits operationally is when the planner runs optimization the next morning.

What goes wrong when slots are not route-aware

Three patterns predictably show up at scale.

• Failed visits. Customer asked for Tuesday. Tuesday’s route is at capacity. Either the planner squeezes the order on (drive time spikes, other SLAs miss) or the order misses the date and the customer takes a failed-visit hit.
• Planner burnout. Every morning the planner spends an hour reconciling impossible dates against the route plan, calling customers to renegotiate. Linear cost in the planner’s time.
• Reschedule call volume. When the customer’s requested date can’t be served, someone has to call to renegotiate. Aggregate cost at scale: significant.

The fix is to never offer a date that doesn’t fit. The slot booking co-pilot is that calculation.

How eLogii’s slot booking co-pilot works

The co-pilot is a route-aware availability service exposed via REST. Given the customer’s delivery address, the order details (weight, volume, special handling), and the requested date range, it returns the set of slots that can be served without breaking optimized routes.

• Live calculation against the plan. The co-pilot looks at the current optimized plan, vehicle capacity, time windows, SLAs and depot coverage, and returns only slots that fit.
• Per-stop precision. Slots are scoped to a window (e.g. 8 to 10 AM) that matches what the route can actually deliver.
• SLA preservation. Customer-confirmed slots are protected from re-optimization downstream. The slot the customer picks is the slot they get.
• Capacity-aware. If the day is full, the co-pilot offers the next achievable day rather than letting the customer book onto a route that can’t fit them.
• REST-callable. Same endpoint serves CSR workflow, storefront checkout, customer portal reschedule, mobile app and any custom UI.

Where the co-pilot surfaces in a SAP S/4HANA stack

The co-pilot is a REST endpoint, so it can appear anywhere that captures a delivery date. Four common surfaces in a SAP stack:

1. CSR workflow. When the CSR is taking an order on the phone, the SAP order-entry surface (custom Fiori app or SAP CRM-style screen) calls the eLogii slot endpoint and shows the agent a list of real options. The agent offers one of those; customer confirms; the slot writes to the sales order.
2. SAP Commerce Cloud checkout. Customer picks delivery during checkout. The SAP-supplied date proposal (aATP + delivery scheduling) is replaced or augmented with a slot list returned by the eLogii endpoint. Customer never sees a date that can’t be served. Order writes to S/4HANA with the confirmed slot.
3. Customer portal self-reschedule. Customer logs in to your SAP-based self-service portal, sees their open outbound delivery, requests a reschedule. eLogii returns the achievable slot list; customer picks; reschedule confirms; new slot writes back to S/4HANA. Around 70% of reschedule requests handled this way without coordinator involvement.
4. SMS-link reschedule. Day-before SMS to customer with a tracking link. If the customer can’t take the slot, they tap to reschedule onto an achievable alternative directly from the link, no log-in required.

The endpoint is the same. The display surface depends on where you want the customer or CSR to interact.

How the confirmed slot writes back to S/4HANA

Once a slot is confirmed (CSR, checkout, customer-self-reschedule, SMS link), the chosen window writes to the S/4HANA sales order or outbound delivery via OData (or BAPI on on-prem). The exact target field is a configuration choice during the integration build, typically against custom Z-fields for the slot window (e.g. ZZ_DELIVERY_SLOT_START, ZZ_DELIVERY_SLOT_END) or against the requested delivery date / time fields.

The planner sees the slot on the order in S/4HANA. eLogii holds the slot against the optimized plan. The driver picks up the order at the right time. No reconciliation, no day-after surprises, no failed visits because the slot was achievable to begin with.

Frequently asked questions

Does SAP check whether a requested delivery date is achievable?

Partially. SAP’s advanced Available-to-Promise (aATP) confirms inventory availability and proposes a Material Availability Date, and SAP’s delivery scheduling adds transit-time and lead-time tables to derive a delivery date. None of that checks whether the resulting date is achievable against the current optimized route plan and own-fleet vehicle capacity for the day. The customer or CSR is offered a date that may not fit operational reality; the planner discovers the mismatch the next morning. aATP is route-blind.

What is a slot booking co-pilot?

An availability service that queries the live route plan and returns only delivery slots that can be served without breaking optimized routes. The customer or CSR picks from real options, not from a generic calendar. eLogii’s slot booking co-pilot is the route-aware availability calculation: given the current plan, the vehicles, the depots, the time windows, the SLAs, which slots can actually be offered.

Where can eLogii’s slot booking co-pilot surface in a SAP S/4HANA stack?

Three common places. The CSR workflow when an agent is taking an order or rescheduling a delivery (CSR calls the eLogii slot API and offers real options). The SAP Commerce Cloud storefront at checkout (customer picks a route-aware slot before submitting the order). The customer portal self-service reschedule (existing customer logs in and reschedules onto a slot that already fits). All three surfaces call the same eLogii REST endpoint.

What’s the outcome of route-aware slot booking?

Two measurable effects from customers running this pattern: around 35% fewer failed visits because the slot was achievable to begin with, and around 70% of reschedule requests handled without coordinator involvement because the customer picks from real options rather than calling in. Both translate directly to fewer support tickets and lower miles per delivered stop.

How does the confirmed slot write back to S/4HANA?

Once the customer or CSR confirms a slot, the chosen window is written to the S/4HANA sales order or outbound delivery via OData (or BAPI on on-prem): typically against custom Z-fields for the slot window or directly onto the requested delivery date / time fields. The planner sees the slot on the order, eLogii holds the slot against the optimized plan, and the route picks up the order at the right time.