Calculator
Example data table
| Order | Received | Processed | Shipped | Delivered |
|---|---|---|---|---|
| WO-1207 | 2026-02-21 09:05 | 2026-02-21 14:30 | 2026-02-22 10:20 | 2026-02-23 16:10 |
| WO-1208 | 2026-02-22 11:15 | 2026-02-22 16:40 | 2026-02-23 09:10 | 2026-02-24 13:55 |
| WO-1209 | 2026-02-24 08:50 | 2026-02-24 12:25 | 2026-02-24 15:05 | 2026-02-25 10:40 |
Formula used
Order Cycle Time measures elapsed time from receipt to delivery:
Optional business-time calculation counts only time within the workday window and can exclude weekends. This helps compare performance against staffed capacity.
How to use this calculator
- Choose Timestamps for milestone-based measurement.
- Enter Received and Delivered times (required).
- Add optional milestones to see stage breakdown automatically.
- Set workday window and weekend rule for business-time reporting.
- Optionally fill the batch table to compute average, median, and P90.
- Press Calculate to view results above the form.
Cycle time as an engineering lead indicator
Order cycle time measures elapsed time from intake to confirmed delivery. In engineered supply chains, stable programs often run 24–96 hours wall clock, while expedited lanes target 8–24 hours. Track median and P90 together: a 36‑hour median with 110‑hour P90 usually means queues and exceptions dominate outcomes. Pair the metric with WIP and throughput; if cycle time rises while throughput is flat, backlog accumulates.
Stage contributions and bottleneck fingerprinting
Typical contribution ranges are 10–25% processing, 5–15% pick/pack, and 60–80% transit. If processing rises above 35% for several cycles, check approvals, batching rules, and capacity limits. When buffers exceed 20% of total time, treat the issue as scheduling and prioritization, not pure labor.
Business-time versus wall-clock reporting
Business-time normalizes results to staffed hours. With a 09:00–17:00 window, a calendar day contributes 8 business hours. A 72‑hour wall-clock cycle can compress to roughly 24 business hours depending on weekend policy. Use business-time for internal productivity and wall-clock for customer promise dates. Report both when staffing models change, so improvements are not confused with calendar effects.
SLA design using percentiles
Avoid setting SLAs on averages because a few long orders distort planning. A practical approach is to set targets near P90 and monitor P95 for stability. Example: if weekly P90 is 84 hours and P95 is 120 hours, a 96‑hour SLA may be reachable with better exception handling, while 72 hours may require routing redesign. Segment by lane: stocked items and custom builds should not share one threshold.
Batch analysis for continuous improvement
Batch rows quantify shifts after process changes. A median drop from 44 to 38 hours is only a win if P90 also falls. Watch dispersion: the interquartile range should shrink as handoffs stabilize. Always interpret cycle time with volume; improvements during low intake may not persist under peak load.
Operational actions tied to observed data
When transit dominates, adjust carrier selection, consolidation thresholds, and daily cutoff times. When processing dominates, automate validations and reduce approval tiers. If excluding weekends shows major business-time gains, consider staggered shifts or weekend dispatch. Recalculate weekly and document milestone definitions to prevent measurement drift across teams. Log exception codes alongside timestamps to separate systemic delays from customer-driven holds.
FAQs
1) What is order cycle time in engineering operations?
It is the elapsed time from order receipt to confirmed delivery. It includes processing, handoffs, waiting, and transit, helping teams quantify responsiveness and variability.
2) Should I report wall-clock or business-time?
Use wall-clock for customer commitments and promise dates. Use business-time to compare internal performance across weeks, shifts, and staffing levels using a consistent workday window.
3) Why does the batch table override single inputs?
Batch mode is designed for portfolio metrics like average, median, and P90. If any batch row is filled, the calculator assumes you want multi-order analysis.
4) What milestones should be standardized?
Standardize “Received,” “Processed,” “Shipped,” and “Delivered” definitions. Align them to system events, such as timestamped status changes, to avoid subjective entry and drift.
5) How is P90 computed in batch mode?
The calculator sorts total cycle times and selects the value at the 90th percentile position. P90 highlights slower experiences and guides SLA setting better than averages.
6) What if delivered time is earlier than received time?
That indicates invalid input or timezone mismatch. Correct the timestamps to reflect the same time basis, then recalculate to ensure stage breakdown and SLA evaluation are meaningful.