Allow Promising calculation APIs to factor in a configurable remorse period when computing EDD, so post-checkout remorse hold delay is reflected in the delivery promise.

The Promising calculation APIs do not factor in the remorse hold period when computing EDD. Remorse hold is a configurable post-checkout delay (e.g., 3–4 hours) during which the order is held and not scheduled/released for fulfillment, allowing the customer to cancel or modify. Once the remorse period expires, the order is scheduled and released.
Promising APIs already consider multiple post-order delays in EDD calculation: item lead time, processing time, schedule and release lead time, and carrier pickup times/cutoffs. Remorse period is also a known, constant configurable value, but it is not currently included.
Result: EDD shown at checkout is optimistic by the duration of the remorse hold.
Example: lead time = 0 hours, processing time = 4 hours → today, 4 hours of lag is considered from referenceTime. With a 3-hour remorse hold, actual delivery is 7 hours after referenceTime, but the EDD reflects only 4.

The enhancement: allow Promising APIs to accept or reference a configured remorse period and include it in EDD calculation the same way other post-order delays are considered.
Apply across:

/promising/{tenantId}/v2/edd
/promising/{tenantId}/v1/cachedEDD
/promising/{tenantId}/v2/calculateCheckoutAssignments
/promising/{tenantId}/v2/calculateCheckoutAssignmentsUsingCosts

What is your industry?	Retail
How will this idea be used? This enhancement allows the remorse period in EDD calculation so the delivery promise at checkout reflects all post-order delays.

Post comment

Guest

Jun 5, 2026

Thanks, this is helpful. Both suggestions do produce the delayed EDD, so they work well as short-term workarounds. The reason we'd still like to see this in the product is that each approach couples the remorse delay to something it shouldn't.
1. ReferenceTime adjustment distorts availability. referenceTime anchors the ATP/availability calculation, not just the EDD timeline. Shifting it to now + remorse moves the inventory snapshot forward, so any inbound supply (receipts/ASNs/transfers) with an ETA inside the remorse window is treated as already on hand. That over-states availability and can change the sourcing decision — the order may be promised from a node that only has stock after the hold expires. Remorse should offset the fulfillment-start timeline only; it shouldn't move the availability snapshot off "now."
2. Lead time / processing time is the wrong home for this.Node and node-type lead time and processing time vary by node and item, and reflect that node's actual fulfillment characteristics. Remorse is a constant tenant-level hold applied regardless of sourcing node. It also can't be turned on or off per order type. For example, we have a priority orders use case where we explicitly do not want the remorse period applied — those should be fulfilled ASAP.
Hence, for these reasons, we'd prefer to have this as part of the product.

Reply
Hide replies

Admin
Sampson Wong

Jun 3, 2026
Sterling Intelligent Promising does not currently provide a dedicated “remorse hold” configuration that is automatically applied during EDD calculations.
However, equivalent behavior can be achieved using existing capabilities:
1. ReferenceTime Adjustment (Recommended)
  When invoking the EDD APIs, the caller can add the configured remorse period to the current timestamp and pass the resulting value as the ReferenceTime. Since SIP calculates EDD relative to the provided reference time, the remorse period will be included in the delivery estimate.
2. Lead Time Configuration
  Alternatively, the remorse duration can be incorporated into the configured Node or Node Type Lead Time. This causes the EDD calculation to account for the additional delay before fulfillment activities begin.
From a product perspective, SIP already supports modeling fixed delays through ReferenceTime and Lead Time constructs. Therefore, the requested outcome can be achieved today without requiring a product enhancement.

The key consideration is whether the remorse period should be managed externally by the calling application (ReferenceTime approach) or centrally through fulfillment configuration (Lead Time approach).

The only additional use case I can envision is supporting a tenant-level remorse period configuration. In this model, the configured remorse period would automatically be applied to all EDD calculations, effectively delaying all promised delivery timelines. While this would provide centralized management, it could also negatively impact channel conversion rates and order capture by presenting later delivery dates to customers.
Reply
Hide replies

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.

Shape the future of IBM!

Search existing ideas

Post your ideas

Specific links you will want to bookmark for future use

Allow Promising calculation APIs to factor in a configurable remorse period when computing EDD, so post-checkout remorse hold delay is reflected in the delivery promise.

Please enter your email address

RELATED IDEAS

Allow Promising calculation APIs to factor in a configurable remorse period when computing EDD, so post-checkout remorse hold delay is reflected in the delivery promise.