Cycle time, lead time and waiting time

What are cycle time, lead time and waiting time?

They are four different clocks on the same piece of work, and most arguments about them come from people reading different clocks without noticing.

Lead time is the customer's clock. It starts when the customer asks for something (an order, a quote, a repair, a leave request) and stops when they have it. Every wait in between counts.

Cycle time is the working clock. It measures how long one item takes to get through one step, or through the whole process, depending on which school you follow. That dependence is the whole problem with the word, and the next section deals with it.

Waiting time, also called queue time, is the gap between two steps: the file sits in an inbox, the order waits for a planning slot, the invoice waits for a signature. In office processes it is nearly always the biggest share of lead time.

Touch time, also called processing time or service time, is the part where someone is actually working on the item. Lead time is touch time plus waiting time, and the two rarely look alike. A quote that takes five working days to reach a customer often carries about forty minutes of actual work: 40 hours on the customer's clock for 40 minutes of touch time, under two percent.

Two more words belong to the family. Throughput is a rate, items finished per day or per week, not a duration. Work in progress (WIP) is the count of items started but not finished. Little's law ties the three together, further down.

The throughput time entry explains how you read the full clock per case from an event log. This entry is about the family: which word means what, where they collide, and which number you attack first.

Three vocabularies, one mapping

The words are used inconsistently across lean, process mining and software delivery. Each field defined them for its own purpose and the definitions never got reconciled.

Lean comes from the factory floor. The Lean Enterprise Institute defines cycle time as the time required to produce a part or complete a process, as timed by actual measurement; in value stream mapping it is the time an operator takes to go through all of her work elements before repeating them. So in lean, cycle time is time per unit at one station. Lead time, in the same lexicon, is the time it takes one piece to move all the way through a process or a value stream from start to finish.

Process mining reads timestamps from systems. The full clock per case is usually called throughput time (Microsoft's Power Automate Process Mining defines it as the time between the first and last event of a case), or lead time and flow time in the academic literature. Waiting time is the time a case waits for a resource to become available; service time is the time worked on a case. When a process mining dashboard says cycle time, check what the vendor means, because it is often used for the full start-to-end clock, the opposite of the lean meaning.

Software teams measure work items. The Kanban Guide defines cycle time as the elapsed time between when a work item started and when it finished, and throughput as the number of work items finished per unit of time. DORA's four metrics use lead time for changes: the time from a commit landing in version control to that change running in production. Both start the clock when work starts, not when the customer asked.

Our house definitions, and how they map:

• Lead time: request to delivery, all waits included. Lean says lead time or production lead time. Process mining says throughput time, case duration or flow time. Software teams have no exact equivalent; DORA's lead time for changes covers only the tail from commit to production.

• Cycle time: the working clock on one item. We always say which scope we mean: one step (the lean meaning) or the whole process from started to finished (the Kanban meaning). If we do not say, assume one step.

• Waiting time: the gap between the end of one step and the start of the next. Lean counts it as waste, never as value-creating time. Process mining says waiting time. Software teams see it as the time an item sits in a To Do or Waiting column.

• Touch time: hands-on work on the item. Lean says processing time or value-creating time. Process mining says service time or activity duration.

• Throughput: items per period. Not to be confused with throughput time, which is a duration.

Before you compare a column in someone else's dashboard with your own, ask which of these five it means. Two departments comparing a lean cycle time with a Kanban cycle time will argue for an hour and both be right.

Lead time versus cycle time: whose clock is running

Lead time runs on the customer's clock. The customer does not care that the order sat in a queue for a week before anyone opened it; they asked on Monday and want to know when it arrives. Lead time therefore starts at the request, and it is the number that shows up in complaints, in service level agreements and in the reason a customer goes elsewhere.

Cycle time runs on the worker's clock. It starts when someone picks the item up. It tells you how fast your people or your machine handle the work once they get to it, which is the number you need for capacity planning and for spotting a step that has become slow.

A short lead time needs both: a low cycle time and short queues in front of every step. A team can handle every order in twenty minutes and still deliver in three weeks, because the twenty minutes happen at the end of a long wait. That is how an improvement project that only measures cycle time reports success while the customer notices nothing.

How you measure them from an event log

All four clocks come from the same raw material: timestamps per activity per case, the rows of an event log. What you can compute depends on how many timestamps each activity has.

With one timestamp per activity, which is what most ERP, CRM and ticketing systems give you, you know when each step happened but not how long it took. You can compute lead time (last timestamp minus first) and the time between consecutive activities. You cannot separate touch time from waiting time, because the gap between 'order entered' and 'order checked' contains both the wait and the check. Microsoft's process mining documentation makes the split explicit: an event log has one timestamp per event, an activity log has a start and an end timestamp per activity.

With a start and a complete timestamp per activity, you get the full picture. The XES event log standard has a lifecycle extension for exactly this, with transitions such as schedule, start, suspend, resume and complete. Complete minus start is touch time. Start of the next activity minus complete of the previous one is waiting time. Sum the waits and you have the queue picture per step, which is what bottleneck analysis feeds on.

With one timestamp only, the gap between two consecutive activities is still a usable proxy for waiting time whenever touch time is small compared to the gap, which in office processes is the normal situation. Forty minutes of work inside a nine-day gap does not change the ranking of your queues.

Worked example: order-to-invoice at a machine builder

A machine builder sells spare parts from stock to customers who own its machines. Order-to-invoice has five steps: order entry, technical check by engineering (right part for that machine version), price and credit approval by the sales manager, pick-pack-ship, and invoicing. The event log gives these numbers for a typical order, in working days of eight hours:

• Order entry: 30 minutes of work, then 4 days waiting for engineering.

• Technical check: 90 minutes of work, then 9 days waiting for the sales manager's approval.

• Approval: 30 minutes of work, then the warehouse picks it up within the day.

• Pick, pack and ship: 2 hours of work, then 7 days waiting for the monthly invoicing run.

• Invoicing: 90 minutes of work.

Lead time: 22 working days, or 176 hours. Touch time: 30 + 90 + 30 + 120 + 90 minutes, which is 6 hours. The three named queues add up to 20 days; the remaining 10 hours or so are small gaps between handovers. Touch time is about 3.4 percent of lead time. Nothing you do to the 6 hours will move the 22 days.

Which queue do you attack first? The 9-day approval queue sits before delivery, so every day cut there is a day the customer feels. The 7-day invoicing queue sits after delivery. The customer never notices it, but the company does: cash arrives a week later than it needs to, and the fix is a policy change (invoice on shipment instead of in a monthly run) that costs nothing. So: attack the 9-day queue first, because that is the customer's clock, and change the invoicing policy the same week because it is free. The 4-day engineering queue comes third, and a standing rule that known part numbers skip the technical check may empty it entirely.

Notice that the lean instinct, speeding up the 90-minute technical check, is the worst investment on the list. Halving it saves 45 minutes on a 22-day lead time.

Little's law on the same numbers

Little's law says that the average number of items in a system equals the arrival rate times the average time each item spends in it. John Little at MIT gave the first proof in 1961, and it holds regardless of whether the queue is served first-in-first-out, by priority or at random. In operations language: work in progress = throughput x lead time.

The machine builder finishes about 3 spare-parts orders per working day. With a 22-day lead time, that means 3 x 22 = 66 orders open at any moment. Cut the approval queue from 9 days to 1 and lead time drops to 14 days, so the open pile shrinks to 3 x 14 = 42 orders, with the same people doing the same work.

The law also runs backwards. Count 66 open orders on a Monday, know you close 3 a day, and average lead time is 66 / 3 = 22 days. A count and a rate give you the customer's clock before you have a single event log.

What AI agents change

An AI agent that reads the incoming order, looks up the machine version, drafts the technical check and proposes the price does the 6 hours of touch time in a couple of minutes. That sounds like the big win, until you put it on the timeline: touch time was 3.4 percent of lead time. If the queues stay, the customer sees 22 days become 21 days and 18 hours.

What agents really do is make the waiting visible. When the work takes seconds, nobody can claim the order was slow because the check was hard. The 9 days were always the approval queue, and now that is the only thing left on the chart.

Then the queue moves. The agent's draft still needs a person to release it, so the approval inbox becomes the new waiting time, and it can get worse: a manager who used to approve 3 orders a day now gets 30 drafts a day. Speeding up touch time without redesigning the approval step builds a bigger queue in front of the same person. The fix is the same as before agents existed: thresholds below which no approval is needed, batch approval with the exceptions flagged, and a second approver. Only now the numbers make the case for you.

What to measure first in an SME

You do not need a process mining platform to get started. You need one process and three timestamps.

1. Pick one process that customers complain about or that ties up cash: quotes, order-to-invoice, purchase approvals, repairs.

2. Timestamp three handovers. Received from the customer, first touched by your team, and delivered. If a status field already changes at those points, export the change history; if not, add a date column and have people fill it in for a month.

3. Compute the three numbers per case and take the median: lead time (delivered minus received), waiting time before first touch (first touched minus received), and the rest. For the first month, treat the time from first touch to delivery as a mix of touch and waiting; you can split it later with more timestamps.

4. Publish them weekly in the same place every time, next to throughput (cases closed that week) and WIP (cases open on Friday). Together they tell you whether an improvement is real: if lead time falls but WIP rises, you have moved a queue rather than removed it.

The first week's numbers will be rough. A median you measured beats an average everyone guesses, and once waiting time sits on a screen next to touch time, the Monday meeting changes on its own.