What Is handlingTime in ShippingService?

handlingTime is the typical delay between receiving an order and the goods leaving the warehouse or being prepared for on-site pickup.

The property can use QuantitativeValue or ServicePeriod and appears on ShippingDeliveryTime and ShippingService. In the ShippingService context, the vocabulary directs publishers to use ServicePeriod so duration, cutoff time, and business days can travel together.

handlingTime is not carrier transit time and not the total customer delivery window. It covers the merchant-controlled preparation stage. The final promise may combine handling with transit and additional fulfillment rules.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Define receipt time.
• Define readiness or dispatch event.
• Use ServicePeriod for ShippingService.
• Keep transit separate.

Use the free backlink checker to identify linked pages before changing shared fulfillment timing.

Primary specification: Schema.org definition for handlingTime.

handlingTime is accurate when it measures the same preparation interval the fulfillment system uses for dispatch or pickup readiness.

handlingTime can be used on ShippingDeliveryTime and ShippingService, with the appropriate value structure determined by the parent context.

On ShippingDeliveryTime, QuantitativeValue commonly carries minValue, maxValue, and unitCode, with day units conventionally counted as business days. On ShippingService, use ServicePeriod for a richer operational schedule.

Do not attach handlingTime directly to Product, Offer, OfferShippingDetails, ShippingConditions, or ShippingRateSettings. Those entities can connect to the service or total delivery structure but are not listed parents for this property.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Identify the actual parent.
2. Select its expected value structure.
3. Keep entity boundaries intact.
4. Validate the rendered graph.

Review ShippingService and ServicePeriod.

Correct placement ensures a parser reads preparation time in the same structural context in which it was defined.

ShippingService should use ServicePeriod because it can combine duration, cutoffTime, and businessDays into one constrained preparation period.

A bare duration cannot explain when an order starts processing. ServicePeriod can show that a thirty-minute pickup preparation applies only during operating days, or that a one-day warehouse delay begins the next business day after cutoff.

Use the smallest complete structure supported by the source policy. Do not add schedules that the warehouse does not maintain, but do not omit cutoff or calendar rules when they can change the customer-facing date.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Collect duration.
• Collect cutoff and zone.
• Collect business-day policy.
• Build one ServicePeriod.
• Test date output.

ServicePeriod is useful when every included constraint comes from real operations and materially explains the preparation promise.

duration expresses the length of handling and should use a supported Duration or QuantitativeValue with a unit that matches the fulfillment source.

Minutes may suit store pickup preparation, hours may suit same-day warehouse handling, and days may suit standard order processing. Decimal values and min/max ranges need money-like precision discipline so conversion between hours and days does not change boundaries.

Do not assume one day equals twenty-four operational hours. When duration is counted over business days, the calendar determines which periods advance the clock. Preserve units through feeds, templates, APIs, and checkout.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Read the source unit.
2. Preserve range boundaries.
3. Avoid lossy conversion.
4. Apply the business calendar.
5. Compare readiness timestamps.

A duration is trustworthy when its value, range, and unit produce the same readiness time as operations.

cutoffTime marks the time after which orders are no longer processed that day, so an order after cutoff adds one day to the delivery-time estimate.

The value uses an ISO 8601 time format and should carry an offset where required to establish local context. A cutoff without a time zone can shift behavior across warehouses, daylight-saving changes, or server locations.

Define what happens exactly at cutoff in the commerce source. Test one instant before, exactly at, and one instant after for each warehouse, service, and relevant daylight-saving period.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Store local cutoff and zone.
• Document equality behavior.
• Apply the correct warehouse calendar.
• Test boundary timestamps.

cutoffTime is accurate when exact-boundary orders receive the same processing start in markup, messaging, and checkout.

businessDays defines the days on which the merchant typically operates and determines which days count toward handling duration.

The property can use DayOfWeek or OpeningHoursSpecification. A Monday-through-Friday schedule does not cover holidays, inventory shutdowns, seller calendars, or warehouse-specific closures by itself. Operational exceptions still need an authoritative mechanism.

Avoid copying one corporate calendar across every origin. Join each ShippingService to the warehouse, store, seller, or pickup location that controls its preparation, then test weekends and closures.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Identify fulfillment authority.
2. Record regular operating days.
3. Apply closures and holidays.
4. Test Friday and weekend orders.

businessDays is correct when only real operating periods advance the handling clock.

Pickup handling ends when goods are prepared for collection, while delivery handling ends when goods leave the warehouse and carrier transit begins.

A store may prepare an item in thirty minutes during opening hours, whereas a delivery warehouse may need one business day before dispatch. These options should use distinct ShippingService entities when their fulfillment type, location, calendar, or readiness logic differs.

Do not add transit time to pickup unless the shopper's selected fulfillment path actually includes movement to a collection point. Pickup availability, stock location, store hours, and reservation expiry can also affect readiness.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Separate pickup and delivery services.
2. Use the correct readiness event.
3. Apply location calendars.
4. Validate stock and availability.
5. Compare customer messages.

Connect the service through hasShippingService.

Pickup and delivery handling remain honest when each stops at its own operational handoff and uses its own service context.

Common handlingTime mistakes include using the wrong parent or value type, omitting units, confusing handling with transit, ignoring cutoff time, omitting time zones, using one calendar for every origin, and promising pickup readiness without stock evidence.

Other defects include negative ranges, minValue above maxValue, stale holiday schedules, day-hour conversion errors, duplicate services with conflicting handling, and syntax validation without calculating a real timestamp.

Repair fulfillment operations data and the structured-data generator together. Shared timing defects can affect large Offer cohorts, so stage changes and retain timestamp-based regression cases.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Crawl every handlingTime.
• Validate parent and type.
• Check ranges, units, and calendars.
• Calculate boundary timestamps.
• Repair shared sources.

handlingTime defects require structure, duration, calendar, cutoff, fulfillment, and live readiness evidence together.