Cycle time
Cycle time is the elapsed time from when active work begins on a defined item until that item reaches an accepted completion state. In AI value measurement, it shows whether AI changes how quickly a workflow completes usable work.
Cycle time is more useful than a claim about time saved because it comes from workflow events. It still needs a stable start, finish, unit of work, and quality rule.
How is cycle time calculated?
The basic calculation is:
Cycle time = accepted completion timestamp - active-work start timestamp
Microsoft Azure DevOps defines cycle time as the elapsed time from when a work item first enters an in-progress state until it reaches a completed state (Microsoft cycle-time guidance). Other workflows can use the same structure with their own events.
A support workflow might start when an agent begins handling a case and finish when the case is resolved to the agreed standard. A contract workflow might start when review begins and finish at approved disposition. The start should exclude waiting before work is accepted unless that waiting time belongs to the decision.
Cycle time versus lead time
Lead time usually begins when work is requested or created. Cycle time begins when active work starts. The distinction helps separate queue delay from processing delay.
AI may reduce processing time while total lead time remains unchanged because intake, approvals, or downstream queues still dominate. Leaders should inspect both measures before claiming that the customer or business received a faster outcome.
The AI unit economics page connects cycle time with cost and accepted output. A shorter cycle is useful when quality holds and the organization converts the released capacity into more completed work, lower unit cost, or another defined outcome.
How should AI cycle time be measured?
Define the unit of work and record start and completion events in the source system. Use the same rules for the baseline and AI-enabled periods. Segment work by material differences such as case type, complexity, channel, or team so a shift toward easier work does not appear as an AI effect.
Track the distribution alongside the average. A faster median can hide a growing tail of stalled work. Report reopened items, escalations, correction rate, and quality failures alongside time. If an item returns to active work, decide in advance whether the cycle continues or restarts.
An AI readiness assessment should confirm that these workflow events and acceptance rules exist before a pilot begins. Without them, the team may rely on surveys or vendor activity logs that cannot reconstruct elapsed business time.
How does cycle time affect AI investment decisions?
Cycle time can support a business case when it connects to a financial or operational consequence. A shorter cycle might reduce backlog, meet a service target, avoid overtime, increase accepted throughput, or shorten time to revenue. The organization should measure that consequence rather than assume it.
For an AI payback period, cycle-time improvement is an input, not cash. Finance needs an explicit conversion from faster work to recurring financial benefit. If the capacity remains unused, report the operational gain without turning it into realized savings.
Common cycle-time mistakes
Common failures include starting the clock at different workflow states, counting generated outputs as completed work, excluding review or rework, comparing unlike work, and reporting one favorable average without sample size or distribution.
Another mistake is measuring only the AI step. A drafting task may become faster while approval or correction takes longer. End-to-end cycle time reveals whether the workflow improved or the delay moved elsewhere.