Delivery dates an AI agent can actually use

Almost every product page states a delivery expectation, and almost none of them states it in a form a machine can compute with. The difference matters more than it sounds, because a shopper reads "ships in 1 to 2 days" and forms a rough expectation, while an agent asked whether something arrives before Friday has to produce a date. It will either do the arithmetic from fields you published, or it will guess, or it will quietly recommend a competitor who made the sum easy.

Reviewed September 21, 2026 · 10 min read

Most of what a merchant publishes is a state. Your price is a number. Your hours are a schedule. Your return window is a count of days. Those sit still, and stating them clearly is mostly a matter of stating them at all.

A delivery date is not like that. It is the output of a small calculation that has to be run fresh at the moment somebody asks, using the current time, the buyer’s location, and four separate facts about how you operate. Publish the answer instead of the operands and it is stale within hours. Publish nothing and the agent has to invent something, which it will do with more confidence than you would like.

A delivery date is a computation, not a property#

Schema.org models this properly, which is unusual and helpful. Shipping information hangs off an offer as OfferShippingDetails, and the timing half of it lives in a ShippingDeliveryTime object carrying four properties that are exactly the four operands:

Give an agent those four and today’s date and it can answer the question a buyer actually asked. Give it a sentence on a page and it is reading tea leaves. The rest of OfferShippingDetails carries the cost side, shippingRate as a monetary amount and shippingDestination as a defined region, so the same block answers what it costs and where you will send it.

{
  "@type": "OfferShippingDetails",
  "shippingRate": { "@type": "MonetaryAmount", "value": 0, "currency": "USD" },
  "shippingDestination": { "@type": "DefinedRegion", "addressCountry": "US" },
  "deliveryTime": {
    "@type": "ShippingDeliveryTime",
    "cutoffTime": "16:00:00-05:00",
    "handlingTime": { "@type": "QuantitativeValue", "minValue": 0, "maxValue": 1, "unitCode": "DAY" },
    "transitTime": { "@type": "QuantitativeValue", "minValue": 2, "maxValue": 4, "unitCode": "DAY" }
  }
}

Note that none of this is marked required. Google lists the shipping properties as recommended, which is the same structural reason so few merchants publish a return policy either. Nothing is withheld from you for leaving it blank, so it stays blank, and the absence only shows up as answers you never hear about.

Handling time is counted in business days, which makes businessDays load-bearing#

This is the part that quietly breaks. The specification for handlingTime says that by common convention it means business days, counting only days when the business normally operates. So handlingTime of one to two days is not a duration. It is a duration in a unit you have not defined.

The fix is small and almost nobody does it: businessDays is expressed through the same opening hours markup you may already publish for a storefront, so for many businesses this is a matter of pointing an existing fact at a second use rather than producing a new one.

The cutoff time is the field that earns its keep in Q4#

cutoffTime is the order deadline after which you stop processing for the day, and the specification states the consequence plainly: for orders placed after the cutoff, one day is added to the delivery estimate. It is written as an ISO 8601 time including the offset, so a 4pm Eastern cutoff is 16:00:00-05:00, and the offset is not optional decoration. Without it, a merchant on the east coast and an agent computing in UTC disagree by five hours in exactly the window where the answer flips.

Saying you do not ship somewhere beats saying nothing#

OfferShippingDetails carries a doesNotShip boolean, described as indicating when shipping to a particular destination is not available. It looks like a field for admitting a limitation. It is closer to a filter you get to apply on your own behalf.

The reason is asymmetric cost. An agent that does not know you exclude a region may recommend you to a buyer there, who then spends time on a checkout that cannot complete, and you spend time on a support message. Nobody gains from that exchange. Stating the exclusion removes you from a set of results you were never going to convert, which is the cheapest kind of qualification there is.

Three places the numbers live, and which one wins#

If you sell products, your shipping data exists in more than one place, and the precedence is worth knowing before you spend an afternoon editing the copy that loses.

• Account-level settings in Merchant Center, which apply broadly across your products.
• The shipping attribute in your product feed, which Google documents as overriding account-level settings for the matching location when the price sub-attribute is submitted.
• On-site structured data on the product page, which is the copy an agent reading your site directly will find, and which nothing in your feed corrects.

That third line is where the drift happens. Merchants update the feed because a disapproval forced them to and leave the page markup carrying last year’s numbers, and the page is what a crawler sees. Product feeds for AI agents covers why consistency between those expressions is a hard requirement rather than a tidiness preference.

The conservative number is the profitable one#

Everywhere else in retail the instinct is to make the claim as attractive as it can honestly be. Delivery is the place to invert that, and the reason is what happens to the number after you publish it.

When an assistant tells a buyer the item arrives Thursday, the buyer does not hear an estimate derived from a range you published. They hear a commitment, made by a neutral party, on your behalf. A missed date on an ordinary purchase is an annoyance. A missed date on a gift is a refund, a support thread and a review, and the review outlasts the order by years, which reviews and ratings covers in its own right.

So publish the maxValue you actually hit rather than the one you hit on a good week. A range you beat is a pleasant surprise that costs you nothing. A range you miss is a refund with a permanent record attached, and the agent will have quoted the optimistic end of it.

What to do, in order#

1. Find your real numbers before writing any markup. Pull the last ninety days of orders and measure the actual gap between order and dispatch, and dispatch and delivery. Most merchants discover their published handling time was set years ago by someone guessing.
2. Publish businessDays first, because every day count above it is ambiguous without it. For a storefront this is the opening hours you already have.
3. Set cutoffTime with the UTC offset included. A time without an offset is a time in an unspecified zone, and this field is only useful near the boundary.
4. State handlingTime and transitTime as separate ranges rather than collapsing them into one total. They change for different reasons, and an agent can only reason about a late carrier if it knows which half is which.
5. Set doesNotShip for regions you genuinely exclude, rather than leaving an agent to find out at checkout.
6. Reconcile the three copies: account settings, the feed attribute, and the markup on the page. Check the page last, because it is the one that silently keeps old numbers.
7. Use the maxValue you hit reliably, not the one you hit occasionally, and revisit it after peak with real data rather than with optimism.

The whole job is perhaps an afternoon, and the reason it is worth an afternoon is that it converts a sentence nobody can compute with into four numbers anybody can. A buyer asking whether something arrives in time is a buyer with their wallet already out. The only thing standing between that question and your answer is whether you published the operands.