What Is ServicePeriod in Shipping Schema?

ServicePeriod is a structured-data type that represents a shipping duration together with the business days and cutoff time that control how the duration is counted.

In merchant shipping policies, it can describe handling time for a ShippingService or transit time for a ShippingConditions rule. Its duration is a QuantitativeValue range. The surrounding calendar and cutoff keep a one-day duration from being misread as one calendar day under every order circumstance.

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.

• Use a defensible whole-day range.
• Define the operating calendar.
• Make cutoff time unambiguous.

Use the free backlink checker while reviewing linked product destinations.

Primary specification: Schema.org definition for ServicePeriod.

ServicePeriod is accurate when duration, business days, and cutoff reproduce the operational timing rule together.

ServicePeriod belongs in policy-level handlingTime on ShippingService and in transitTime on ShippingConditions, with each placement describing a different phase of fulfillment.

Handling is often shared by a warehouse or service, while transit varies by destination and shipping condition. Putting one handling period inside every route duplicates data; placing one transit period at service level can hide regional differences. The entity hierarchy should follow operational ownership.

• 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. Map the Organization and ShippingService.
2. Identify shared handling behavior.
3. Split destination-specific conditions.
4. Attach transit periods to those conditions.
5. Validate the rendered policy graph.

Review ShippingConditions and ShippingDeliveryTime for the surrounding models.

ServicePeriod and ShippingDeliveryTime solve related but distinct modeling problems. ServicePeriod is useful in the reusable ShippingService policy graph, where handling can be shared and transit can vary by condition. ShippingDeliveryTime packages handling and transit inside OfferShippingDetails for a product-specific Offer. Do not publish both structures merely to repeat the same timing claim. Choose the scope that owns the rule, keep any required override narrower than the shared policy, and confirm that the resulting customer ETA is identical. If two models remain on the site, audit precedence and freshness so an old Offer override cannot silently defeat a newer merchant policy.

Correct placement separates service-wide processing from route-specific carrier travel.

Duration uses QuantitativeValue with non-negative whole-number minValue and maxValue plus unitCode DAY to express the expected service period.

The minimum must not exceed the maximum. Zero can represent same-day processing under the stated cutoff. A broad range should be based on normal performance rather than the fastest and slowest outliers. If two services have materially different timing, create separate policies or conditions.

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.

• Measure timestamped operational intervals.
• Choose a normal defensible range.
• Keep numeric values whole and non-negative.
• Recheck after service-level changes.

Duration does not state whether weekends count; businessDays supplies that missing calendar context.

A valid duration is an ordered, whole-day range grounded in actual service behavior.

BusinessDays lists the weekdays that count toward the ServicePeriod, allowing processing and transit calendars to differ from ordinary calendar days.

A Monday-through-Friday warehouse can hand orders to a carrier that delivers Saturday. Those are two calendars, not one. Policy markup should reflect the calendar for the specific period. If a warehouse temporarily processes weekends during peak season, the data and ETA engine must change together.

• 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. Document the warehouse calendar.
2. Document each carrier calendar.
3. Assign the correct days to each period.
4. Test orders spanning weekends.
5. Review temporary calendar changes.

A list of weekdays should be generated from the same service configuration used by checkout, not maintained as SEO-only copy.

BusinessDays keeps duration honest by counting only the weekdays when the relevant operation actually moves.

CutoffTime should state the daily order boundary with an explicit offset so orders before and after the same instant enter the correct handling day.

A time such as 14:30 without a zone is ambiguous across US warehouses and customers. A value such as 14:30:00-07:00 identifies the local offset at that moment. Daylight-saving changes require the source system to preserve the intended local operational time rather than freezing the wrong UTC offset year-round.

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.

• Choose the operational timezone authority.
• Store a timezone identifier upstream.
• Render an unambiguous time value.
• Test before and after the boundary.

A one-minute cutoff error can add an entire business day to handling.

CutoffTime is trustworthy when one timezone-aware rule drives both structured data and checkout ETA.

A handling ServicePeriod measures merchant processing before carrier handoff, while a transit ServicePeriod measures carrier movement from handoff to delivery.

The endpoint of handling should equal the starting event of transit so a delay is neither omitted nor counted twice. Made-to-order production belongs in handling. Carrier sorting, line haul, customs movement, and last-mile delivery belong in transit. Customs preparation by the merchant may require an explicit operational definition.

• 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. Define order-received timestamp.
2. Define carrier-handoff timestamp.
3. Define delivery timestamp.
4. Measure both intervals independently.
5. Reconcile the total ETA.

Publishing transit alone as total delivery creates an optimistic promise whenever handling is nonzero.

Handling and transit remain accurate when they share one handoff boundary and cover the full delivery journey without overlap.

Holiday closures and peak-season schedules should update the operational calendars or temporary policy conditions that generate ServicePeriod, because weekday lists alone do not capture exceptional dates.

ServicePeriod does not encode a complete holiday database. The merchant needs an upstream calendar that adjusts handling and transit promises for Thanksgiving, Christmas, warehouse shutdowns, carrier embargoes, and regional holidays. Temporary changes must have start and end controls.

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.

• Use one operational holiday source.
• Segment merchant and carrier closures.
• Schedule temporary changes.
• Verify return to normal afterward.

When precise arrival cannot be defended, widen or remove the promise rather than publish false certainty.

Seasonal timing stays accurate when temporary calendars and ranges follow real operations and expire on schedule.

Common mistakes include reversed duration ranges, missing units, timezone-free cutoffs, using one business calendar for handling and transit, and publishing carrier time as total delivery.

Another defect is copying one ServicePeriod across regions or service levels with different behavior. Static policies can survive warehouse changes, carrier migrations, and holiday schedules. Syntax validation cannot prove that an order placed at a real cutoff receives the advertised date.

• 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. Extract each ServicePeriod and parent.
2. Trace its range, calendar, and cutoff.
3. Repair the authoritative service source.
4. Test boundary order times.
5. Recrawl the rendered policy.

A source-level repair prevents the same timing defect from affecting every product under the service.

ServicePeriod errors require operational timing reconciliation, not only valid property names.