How to Calculate Contract Cycle Time

Definitions

Practical workflow

1. Write the metric contract

   Use one request_id per measured request and document the exact start event, completion event, included statuses, pause reasons, clock type, time zone, reporting period, and exclusion rules. For example, a request may start when complete intake is accepted and end when the contract is executed; a draft submission and an abandoned request are not silently treated as starts or completions.

2. Capture an append-only event log

   Record event_type, request_id, occurred_at, actor or system, stage, queue reason, pause reason, source, and time zone for every transition. Store timestamps as unambiguous ISO 8601 or RFC 3339 instants, and use a consistent half-open interval convention: [start_at, end_at), including the start boundary and excluding the end boundary.

3. Calculate total cycle time

   For a closed request, raw total seconds = completion_at - start_at. If valid pause intervals are excluded, active total seconds = raw total seconds - union_length(valid pause intervals). Union overlapping pauses before subtraction, reject unmatched or open pauses from closed-cycle reporting, and retain raw, pause, and active values so the adjustment is auditable. For an illustrative request that starts Monday at 09:00 and completes Wednesday at 13:00, raw elapsed time is 52 hours; an approved 8-hour pause leaves 44 active hours. Do not replace missing timestamps with zero.

4. Calculate stage, queue, and touch time

   For each stage interval i, stage_seconds = sum(end_i - start_i) after applying the same clock and pause rules. Queue_seconds is the sum of intervals whose declared state is waiting or queued; touch_seconds is the sum of explicit action intervals, with overlapping actions unioned when they represent one concurrent work period. If stages are mutually exclusive, reconcile active_total_seconds = stage_seconds + unassigned_seconds; report any residual instead of forcing it into touch time.

5. Choose calendar or business time

   Calendar seconds use elapsed instants across the full interval, then convert to days as seconds / 86,400; they do not mean counting date labels. Business seconds use the intersection of [start_at, end_at) with the responsible entity calendar in its local time zone, including configured working windows, weekends, holidays, closures, and daylight-saving transitions. Business days = business_seconds / scheduled_seconds_per_day, not a universal seven-day or five-day assumption.

6. Apply pause-clock rules

   Start a pause only on a pause_start event with an allowed reason code and stop it on the matching pause_end event. A pause interval is [pause_start, pause_end); it is subtracted only from the metric whose policy allows that reason. If a request changes stage while paused, keep the pause separate from stage state, close or reconcile it before completion, and flag an open, unmatched, or overlapping interval for review.

7. Handle reopened requests explicitly

   Never overwrite the first completion_at. For a continuing lifecycle, first_pass_seconds = first_completion_at - start_at and final_lifecycle_seconds = final_completion_at - start_at, each with the declared pause policy; reopen_seconds = final_lifecycle_seconds - first_pass_seconds. Report reopen_count and first-pass results separately. If reopening creates a new scope or new request_id, exclude the follow-up from the original cycle and link the records.

8. Summarize, segment, and quality-check

   Sort valid durations x1 <= ... <= xn and use the declared quantile rule. With linear interpolation and 1-indexed rank r = 1 + (n - 1)p, Qp = xk + (r - k)(xk+1 - xk), where k = floor(r); median = Q0.50 and p95 = Q0.95. Segment first by workflow, contract type, risk tier, business unit or entity, region, intake channel, playbook, and completion period; make each dimension and inclusion rule explicit. Publish n, median, selected percentiles, and open-request aging separately by cohort. Before release, check one start and one terminal event, start_at < completion_at, nonnegative intervals, complete state pairs, valid time zones, no impossible future or duplicate events, no overlapping exclusive stages, and total-to-component reconciliation.

Comparison

Limitations and exceptions

• Cycle time is only comparable when the start event, completion event, pause policy, clock type, time zone, and cohort rules are the same. Two teams can report different values correctly while measuring different work.
• Touch time is not recoverable from ordinary status history. Without explicit action intervals, an assignment, comment, or status change is evidence of activity but not a defensible duration.
• Business-time results depend on entity calendars, holidays, working windows, time zones, daylight-saving transitions, and exception schedules. A business day is not a universal fixed number of hours.
• Pauses can improve operational clarity or hide demand if reason codes are broad, optional, or applied inconsistently. Review pause rate, pause duration, and reason distribution alongside cycle time.
• Open requests are right-censored: their final completion time is unknown. Report current aging separately and do not mix open durations into completed-request medians or percentiles.
• Reopened work can represent correction, scope change, counterparty delay, or a genuinely new request. A single policy cannot explain all cases, so publish the reopen rule and counts with the metric.
• Examples in this guide illustrate calculation mechanics only. They are not universal benchmarks, service-level commitments, or evidence that one contract workflow should match another.

Primary sources

Methodology

This guide treats contract cycle time as an event-measurement problem. First define the unit of work and terminal outcome; then capture timestamped state, queue, action, pause, reopen, actor, calendar, and time-zone data; next compute intervals with one declared clock and explicit half-open boundaries; finally summarize only valid completed records by stable cohorts. Keep raw elapsed time, pause duration, active time, stage time, queue time, touch time, reopen time, and data-quality flags as separate fields. Use the median and declared quantiles for distribution summaries, include sample size and extraction period, and compare periods only after confirming that workflow definitions and calendars did not change. Do not turn illustrative results into universal benchmarks.

FAQs

Related CaseDocker capabilities

Related guides and resources

• Contract management
• Playbooks
• Legal operations software