Process Cycle Time vs Lead Time vs Touch Time: What Should You Measure?

Measure lead time when you need to know how long a requester waits from receipt to delivery. Measure cycle time when you need elapsed time from a defined in-process start to a defined finish. Measure touch time when you need the active work spent on the item. Waiting can remain inside cycle time; it is not automatically touch time.

The names alone are not enough. “That proposal took ninety minutes” can be true about the team’s effort and false about the customer’s wait. Before comparing numbers, agree on which events start and stop each clock.

Quick answer: cycle time vs lead time vs touch time

Choose the measure by the question you need answered. For the service-work examples in this article, the clocks mean:

Lead time and cycle time are elapsed durations under a stated calendar. Here, touch time is human effort in person-minutes, including checking, chasing and correction. Other systems may count machine processing or use different labels. Write the unit and boundary beside the name.

If your question is which measures belong in a wider baseline, start with How to Measure a Business Process. This comparison stays with the clocks, not the full measurement system.

Does cycle time include waiting?

Yes, under the start-to-finish elapsed-time convention used here. Once the item has started, a pause for review, missing information or a handoff remains inside its cycle time until the defined finish.

Kanban Guides’ The Kanban Guide (May 2025) defines cycle time as the elapsed time between a work item starting and finishing. Those points depend on the team’s explicit definition of its workflow. This is a knowledge-work convention, not a requirement that every business adopt Kanban.

That distinction matters when reading a software report. A ticket marked “In progress” for two days may have received only an hour of attention. The status interval measures elapsed time, not continuous work.

Some manufacturing contexts use cycle time for a repeated operation or output interval. A production machine’s cycle and a proposal’s start-to-delivery duration therefore need not mean the same thing. Keep the existing local term if it is useful, but add the actual definition before importing a formula or comparing another team’s result.

Lead time also depends on context. The NC State University Supply Chain Resource Cooperative entry Lead Times/Cycle Times, dated January 2011, describes logistics lead time from recognizing an order need to receiving goods. Its possible components include preparation, queues, processing, movement, receiving and inspection. That supports including more than hands-on work; it does not prescribe the receipt-to-delivery boundary for every service business.

For a proposal process, receipt of the customer’s request and delivery of a checked proposal might be appropriate. For an internal approval, the requester and accepted output are different. The event matters more than the label.

Which time measure should you choose?

Choose lead time for the requester’s elapsed experience, cycle time for time inside a specific process boundary, and touch time for active effort. Pair them when the decision requires both delay and workload; do not collect all three simply because a report can display them.

A complaint that “customers wait too long” calls for a receipt-to-delivery clock. A question about how long proposals spend inside preparation and review calls for cycle time. A question about the labor involved calls for touch effort. None of those alone tells you how many people to hire.

A time-boundary decision worksheet

Copy this worksheet for one real case. The middle column is a filled example, not a required company policy.

A process owner should settle an ambiguous boundary before the number becomes a target. If one person selects “ready for work” and another selects “first work begins,” they will exclude different amounts of waiting. Neither event is self-explanatory.

For customer-facing lead time, an incomplete request can still be a real request. Starting only when every input is ready may be useful for an internal service clock, but it excludes the earlier customer wait. Keep that excluded interval visible and name the narrower measure honestly.

“Done” needs the same care. A draft saved internally is not a delivered proposal. If customer acceptance is required by the process, the clock ends at that acceptance rather than at send. The worksheet should identify the evidence, not merely a status someone can click.

How do you calculate the three times for one case?

Subtract the selected timestamps for lead and cycle time, then separately sum the recorded human work intervals for touch time. Convert units consistently, and never treat a status duration as proof that somebody worked continuously.

Here is an illustrative proposal, not a SYSIPHANY client result or an industry benchmark. All events occur in one local timezone, with no holiday or clock change. Business hours are 09:00–17:00 on both days. The checked proposal is delivered at the moment the final touch ends.

The resulting measures are:

• Lead time: Monday 09:00 to Tuesday 15:00 = 30 calendar hours.
• Cycle time: Monday 11:00 to Tuesday 15:00 = 28 calendar hours.
• Human touch time: 30 + 45 + 15 = 90 person-minutes, or 1.5 person-hours.

The two-hour difference between lead and cycle time is the interval before preparation began. It is not all the waiting in the case. Waiting after Monday 11:00 remains inside the 28-hour cycle.

Under the separate business-hours calendar, lead time is eight hours on Monday plus six on Tuesday: 14 business hours. Cycle time is six hours on Monday plus six on Tuesday: 12 business hours. Touch effort stays at 90 person-minutes because all three work sessions fall inside those hours.

Both elapsed versions are accurate. They answer different questions. “Thirty hours after receipt” describes the full elapsed interval; “fourteen business hours” counts only the specified service window. A business-hour result should not be presented as the customer’s uninterrupted wait.

A useful summary is: “This proposal reached the customer 30 calendar hours after receipt. Preparation began two hours after receipt, and the team logged 90 person-minutes through delivery.” That is more informative than calling the process “a ninety-minute turnaround.”

Can you subtract touch time to find waiting time?

Only when the units, boundaries and activity coverage make that subtraction valid. Human person-time is not generally interchangeable with elapsed time, especially when people work in parallel or a machine runs unattended.

In the illustrative proposal, one person works at a time, all touches are logged, and nothing processes unattended. Every remaining interval is time when the case waits, including overnight. Under those explicit assumptions:

• Calendar time outside touches = 30 − 1.5 = 28.5 hours.
• Business time outside touches = 14 − 1.5 = 12.5 hours.

Those hours are not automatically removable waste. The calendar result includes closed hours. A required review may protect a legitimate control. The numbers do not establish why the case waited or whether removing a step would be safe.

Now change the situation. Two reviewers work on the same item simultaneously for twenty minutes. That consumes 40 person-minutes but occupies only 20 elapsed minutes. Subtracting forty from the twenty-minute interval would produce nonsense, not waiting time.

For an elapsed-time breakdown, overlapping activity intervals must be merged so each minute on the timeline is counted once. For workload, each person’s effort still counts. Both results are useful; they are different quantities.

Unattended activity creates another limit. A file conversion can run while nobody touches the case. That is processing, not human effort, and it may overlap other work. Without evidence separating human activity, machine processing and inactivity, call the residual time outside recorded human touches, not proven waiting time.

Locating a recurring constraint needs a different investigation. How to Identify Bottlenecks in a Business Process owns that task. A large residual is a reason to ask what happened, not a diagnosis by itself.

A shorter reported time can hide unchanged work

Before treating a lower number as improvement, check whether the clock changed. Moving the start from request receipt to “all information complete” excludes input chasing. Stopping at internal approval instead of customer delivery excludes dispatch delay. Pausing during review removes part of the experience you may have intended to measure.

Those narrower measures can be legitimate. What fails is comparing them with an earlier, wider measure as though the process became faster. Preserve the old definition, date the new one, and separate the results. If the original timestamps remain available, calculate both boundaries on the same cases to see the difference.

Touch time can also fall because work moved elsewhere. A preparation team that stops logging reviewer corrections has changed its accounting, even if its own work became easier. Keep included effort explicit before claiming relief for the whole process.

When the disputed interval sits between teams, improving team handoffs addresses the transfer itself. This worksheet only determines whether the clock includes it.

If nobody can agree on receipt, completion or the record that governs either event, Download the Operational Drag Diagnostic Kit. The immediate problem is operating ambiguity. Another timer will not settle it.

FAQ

Is touch time the same as value-added time?

No. Touch time can include correcting an error, chasing a missing detail or checking required controls. It records active effort under your definition. Whether an activity creates customer value is a separate judgment; necessary effort and value-added effort are not interchangeable labels.

Is cycle time always shorter than lead time?

Only when the cycle boundary sits entirely inside the lead-time boundary and both use the same clock. With the same finish and a later start, cycle time cannot be longer. Different calendars, case units or completion events break that comparison.

What happens if a case reopens?

Agree on whether the measure ends at first accepted completion or final accepted completion after rework. Preserve both events when they matter. For final-completion timing, restarting at the correction would hide the earlier elapsed interval. A genuinely new request should have its own linked case rather than silently extending the original one.

Can I calculate cycle time before a case finishes?

You can calculate its age since the defined start, but that is not completed cycle time. Label it as age at a specific observation time. Keep unfinished cases separate from finished durations rather than reporting their current age as their final result.

What if I have dates but no times?

Report only the precision the records support. A date-only system needs an explicit day-counting convention; it cannot establish an exact hour duration. Do not compare an inclusive count of calendar dates with timestamp subtraction without explaining the difference.

Put the question beside the clock

Take one completed case and fill the worksheet. Write receipt, in-process start and accepted finish beside the actual evidence. Add the human work intervals only if effort is part of the question. Then state the result with its units and limits.

If teams disagree about those boundaries across systems and cannot resolve who owns the definition, Book a SYSIPHANY discovery call. Start with the disputed operating events, before choosing another reporting tool.