Delivery dates an AI agent can actually use

'Ships in two days' tells a buyer when an item may leave, not when it will arrive. A useful delivery estimate also needs the destination, carrier service, cutoff time and the days your fulfillment operation runs.

Reviewed October 1, 2026 · 6 min read

A delivery estimate depends on the order as well as the product. The destination, selected service, stock location and time of purchase can all change the answer to 'Will this arrive by Friday?'

Publish the relevant rules and, where available, a current destination-specific estimate. Label estimates and guarantees accurately. Neither clear prose nor structured data can remove carrier delays or make an unsupported promise reliable.

Describe the parts of the estimate#

Schema.org's ShippingDeliveryTime can describe several timing inputs within shipping information. Consumer support varies, so use it alongside readable terms and the requirements of your shopping platform.

Also state the applicable destination and shipping cost. This illustrative block uses a weekday operation and a fixed offset. Adapt it to your real service and check what your target consumer supports:

{
  "@context": "https://schema.org",
  "@type": "OfferShippingDetails",
  "shippingRate": { "@type": "MonetaryAmount", "value": 0, "currency": "USD" },
  "shippingDestination": { "@type": "DefinedRegion", "addressCountry": "US" },
  "deliveryTime": {
    "@type": "ShippingDeliveryTime",
    "businessDays": {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["https://schema.org/Monday", "https://schema.org/Tuesday", "https://schema.org/Wednesday", "https://schema.org/Thursday", "https://schema.org/Friday"]
    },
    "cutoffTime": "16:00:00-05:00",
    "handlingTime": { "@type": "QuantitativeValue", "minValue": 0, "maxValue": 1, "unitCode": "d" },
    "transitTime": { "@type": "QuantitativeValue", "minValue": 2, "maxValue": 4, "unitCode": "d" }
  }
}

Schema.org vocabulary and a platform's eligibility requirements are different things. Check the current shipping specification for the destination you use. A property being optional in one context does not mean shipping information is unnecessary everywhere.

Use fulfillment days, not storefront opening hours#

A shop can be open on Sunday while its warehouse dispatches only Monday to Friday. Publish the schedule relevant to fulfillment, and distinguish the merchant's handling calendar from the carrier's delivery calendar.

Document holiday exceptions and unusual operating days in the systems that calculate the estimate. A normal weekday schedule alone cannot describe every seasonal closure.

Make cutoff times unambiguous#

State the cutoff and its time zone, then keep the machine-readable offset correct. For example, 4pm US Eastern is 16:00:00-05:00 in standard time and 16:00:00-04:00 during daylight saving time. A fixed offset is not a year-round time-zone rule.

Saying you do not ship somewhere beats saying nothing#

State shipping exclusions clearly in the formats your destination supports. Schema.org includes doesNotShip for a specified destination, but support and mapping vary between consumers.

A buyer outside your service region needs to know before checkout. Explain restrictions for territories, remote areas, PO boxes or particular products where they apply. Do not rely on a country-wide 'free shipping' statement if important exceptions exist.

Reconcile each published shipping configuration#

Review the places that describe shipping, because different consumers may read different sources:

• Account-level settings in your merchant platform.
• Item-level feed attributes or rules, which may override broader settings under documented conditions.
• Visible product and policy pages, plus any structured data they publish.
• The destination-specific options and total shown at checkout.

Inspect the effective value after overrides, not just the default you entered. A current feed does not update a hand-written policy page. The product feed guide explains how to check these outputs together.

Use evidence to set delivery ranges#

Measure order-to-dispatch and dispatch-to-delivery separately, grouped by relevant service and destination. Use that evidence to set realistic ranges and identify recurring delays.

Make the uncertainty visible. If the date is an estimate, say so; if you offer a guarantee, explain its conditions and remedy. A customer should not have to infer whether the earliest date in a range is a commitment.

Choose a range that reflects normal performance and review it during disruptions or peak periods. An artificially wide range can also mislead shoppers, so aim for accuracy rather than optimism or excessive padding.

What to do, in order#

1. Measure handling and transit from recent representative orders.
2. Confirm fulfillment and carrier calendars, including holidays.
3. Set cutoff times with correct time-zone handling.
4. Publish destination-specific ranges and applicable exclusions.
5. Reconcile account settings, item overrides, visible terms, structured data and checkout.
6. Test orders before and after cutoff, near weekends and to restricted destinations.
7. Review estimates when carrier performance or operations change.

The practical result should be an answer your team can stand behind: what is likely to arrive, where, when and under which conditions. Structured fields help communicate that answer, but the fulfillment operation has to support it.