# Takt Time

**URL:** https://kaizumi.com/dictionary/takt-time

**Description:** Takt time is available time divided by customer demand. 440 minutes against 440 units gives a 60-second beat. Build your stations to 51 seconds.

**Category:** lean-principles

**Tags:** flow, metrics, foundational

## Available time | Why one shift gives three takt times

Takt time tells you the pace needed to match customer demand. You calculate it by dividing your available working time by the number of units customers need. The division is simple, but teams often disagree on what actually counts as available time.

Suppose your shift runs for `480` minutes, and customers need `440` units during that shift. Three common rules count available time in three different ways, and each one gives you a different pace.

| Rule | What it counts as available time | Available minutes |
|---|---|---|
| A — the clock | The whole shift, start to end | `480` |
| B — planned stops out | The shift minus breaks, startup and handover, and one planned changeover | `440` |
| C — everything out | Also minus `30` minutes of average breakdowns and `10` minutes of rework | `400` |

```kz-tiles
lead: Rule B
tile: Rule A | 65.5 | s
tile: Rule B | 60.0 | s
tile: Rule C | 54.5 | s
```

The difference between `65.5` seconds and `54.5` seconds is eleven seconds on a sixty-second beat. Rule A gives a pace that is `1.20` times longer than Rule C, because `480 ÷ 400 = 1.20`.

If you use Rule A, you assume your process will run during every single minute of the shift, which is not realistic. If you use Rule C, you treat unplanned downtime as part of your normal plan, so you end up buying `10` percent more staffing or equipment than you actually need. Both mistakes cost real money.

The standard method is Rule B. You subtract the breaks and planned stops you scheduled in advance. You do not subtract equipment breakdowns, rework, or unplanned problems.

```kz-callout
tone: warn
title: Rule C pays for the same loss twice.
p: Subtract breakdowns and available time shrinks. Takt gets shorter. Every station's design target gets tighter. Then you lose the breakdowns again on the day, so you have charged one loss twice.
p: [OEE](/dictionary/oee) draws the line in the same place. Planned stops leave available time. Unplanned stops are what availability measures against it. Two metrics, one boundary.
```

## The formula | How to calculate takt time

To find takt time, divide your available working time by the customer demand over that exact same period. That is the whole formula. Available time is the only input teams argue about.

```kz-formula
expr: Takt =
expr: Available time ÷ Customer demand
var: Available time | **Time you plan to run the process**, after planned stops come out. Use seconds if you want takt in seconds.
var: Demand | **Units the customer needs in that same period.** Use average sellable demand. Not the forecast, and not the busiest day.
var: ÷ | **One period on both sides.** A shift's time over a shift's demand. Divide a day's minutes by a week's orders and the answer means nothing.
```

Make sure both numbers cover the same time window. If you use the working minutes in a single shift, use the customer demand for that single shift. If you divide a day of available time by a full week of orders, the result will not be useful.

### What to subtract from the shift

It helps to write down each deduction line by line. When your team can see which stops are planned and which are unplanned, it is much easier to agree on the available time.

| Line | Minutes | In or out |
|---|---|---|
| Scheduled shift | `480` | where you start |
| Breaks | `−20` | out — two `10`-minute breaks you decided not to run |
| Startup and handover | `−10` | out — planned |
| Planned changeover | `−10` | out — planned |
| Available time | `440` | `26,400` seconds |
| Breakdowns | `30` | stays in — this went wrong, you did not plan it |
| Rework and touch-up | `10` | stays in |
| Minor stops | unmeasured | stays in |

The basic rule is simple: **subtract time you deliberately scheduled not to work, but never subtract unplanned downtime or mistakes.**

Following these numbers, `26,400 ÷ 440 = 60.0` seconds. You need to complete one unit every 60 seconds, for every minute you plan to run.

Breakdowns, [minor stops](/dictionary/minor-stops), and rework stay inside available time. They reflect how your process actually performed compared to the plan, rather than the schedule itself. You track those through [OEE](/dictionary/oee) and the [six big losses](/dictionary/six-big-losses). You account for them once, when you set targets for individual workstations.

## Design pace | Planned cycle time vs takt time

No process runs continuously without stopping. Equipment stops, people step away, and small delays occur. If you design workstations to match takt time exactly, you will end the day short of your goal. To protect your output, you design workstations to run slightly faster than takt time.

Suppose your process runs `85` percent of the time. That figure is availability multiplied by performance, measured over the last quarter. Nothing on the line needs fixing. This is simply what an ordinary, realistic week looks like.

To find the pace each workstation needs to hold, multiply takt time by `0.85`.

Planned cycle time = takt × uptime = `60 × 0.85` = `51.0` seconds.

```kz-pass
title: Pass 1 — stations built to takt
step: Running time = 26,400 × 0.85 = **22,440** s
step: Units built = 22,440 ÷ 60 = **374**
out: Demand was **440**. You finish **66** short — the `15` percent of downtime you already knew about.
```

```kz-pass
title: Pass 2 — stations built to planned cycle time
step: Planned cycle time = 60 × 0.85 = **51.0** s
step: Units built = 22,440 ÷ 51 = **440**
out: Demand met. Same people, same shift, same downtime.
```

Pass 1 is not bad luck. If you design workstations to hit `60` seconds on a line that runs with `15` percent downtime, falling `66` units short is simple arithmetic. The shortfall was set before the shift started.

```kz-figure
id: three-lines
caption: Three lines, not two. Every station is at or under takt, and three of the four sit over planned cycle time. Amber is the work that will not fit once you count the stops.
wide: true
```

This adjusted pace goes by two different names. Some teams call it **planned cycle time**, while others call it **operable takt time**. Both terms describe the exact same number. It helps to ask your colleagues which term they use before discussing targets.

```kz-callout
tone: warn
title: Planned cycle time is not "work faster".
p: It is a design allowance, not a pace target. Nobody has to do `60` seconds of work in `51`. You put `51` seconds of work into the station so that the `60`-second beat survives the stops.
p: Read it as a speed target and you have built a speed-up out of a spreadsheet.
```

```kz-photo
src: /guides/toyota-assembly/hero-hall.webp
alt: A long assembly hall with partly built vehicles moving down a central line, workstations and parts racks on both sides, and overhead conveyors running the length of the roof.
caption: **One beat, the whole length of the hall.** Every station on this line is built to the same derived number, not to the raw takt.
width: 1920
height: 1072
```

## Parallel servers | Takt time in a clinic or office

Imagine a clinic that is open from 08:00 to 17:00, which is `540` minutes. After subtracting a `45`-minute lunch break and a `15`-minute morning huddle, `480` minutes of working time remain. The clinic has appointments for `32` patients that day.

Dividing `480 ÷ 32 = 15` minutes gives a takt time of 15 minutes. The clinic needs to finish one patient visit every quarter hour.

However, a single patient visit might take an hour. At first, a `15`-minute takt time seems impossible. You will often hear this objection in hospitals, service desks, claims offices, and repair centers.

The math works because several visits happen at the same time. Takt measures the rate at which completed work leaves the entire system, not the clock on any one server. Once you count the number of parallel rooms or staff members, the formula corrects itself.

```kz-formula
expr: Allowed cycle time per server =
expr: Takt × Number of parallel servers
var: Takt | **The beat of the whole process.** One finished unit every `15` minutes.
var: Servers | **How many units you can have in work at once** — exam rooms, checkout lanes, claim handlers, identical machines.
```

With `4` exam rooms, the allowed time per room is `15 × 4` = `60` minutes. An hour-long appointment now fits without an issue. Over the whole day, `4 × (480 ÷ 60)` = `32` patients are seen. You meet customer demand even though each appointment takes four times longer than the takt time.

```kz-figure
id: parallel-rooms
caption: One room holds a patient for four takts. Four rooms, started a takt apart, hand out a finished visit every 15 minutes.
wide: true
```

If one room closes for maintenance, you can see the impact immediately. With only three rooms handling `60`-minute visits, the clinic can only see `3 × (480 ÷ 60)` = `24` patients, which is `8` short of the schedule. To see all `32` patients across three rooms, each visit would need to take `45` minutes, because `3 × (480 ÷ 45)` = `32`.

Counting servers tells you which lever moved. Instead of a clinic that is generally behind, you know whether you lost a room or the work itself got longer. Those two problems require different fixes.

On a simple assembly line, work passes through one station at a time, so the server multiplier is one and the correction disappears. That is why manufacturing examples rarely mention parallel servers, and why people who read only those examples decide takt time does not apply to a clinic. It applies just as well in offices and healthcare.

## Demand changes | What to do when takt time moves

Takt time changes on purpose, when customer demand or scheduled working time changes. It should never change by accident. For example, if customer demand increases by `25` percent, rising from `440` units to `550`, you have two practical choices. Each choice costs you something, so pick the one you can pay for.

**Keep your current working hours and speed up the required cycle time.** If you keep `440` available minutes, your new takt time is `26,400 ÷ 550` = `48.0` seconds. Your planned cycle time becomes `48 × 0.85` = `40.8` seconds. Every workstation now has to shed `51.0 − 40.8` = `10.2` seconds of work.

To do this, you rebalance the line. You move tasks between workstations or use kaizen improvements to eliminate wasted effort. You do not ask people to rush.

**Keep your workstation cycle time and add working hours.** If you keep planned cycle time at `51` seconds, you will need `550 × 51` = `28,050` seconds of actual running time. With `85` percent uptime, that requires `28,050 ÷ 0.85` = `33,000` total scheduled seconds, or `550` available minutes.

Since your normal shift provides `440` minutes, you are `110` minutes short. If you find those minutes through overtime or an adjusted shift schedule, takt time returns to `33,000 ÷ 550` = `60.0` seconds. Buying time restores the original beat instead of changing it, which is why most teams try this option first.

| What you change | What it costs | What you must not touch |
|---|---|---|
| Available time | `110` extra minutes of shift — overtime, another crew, or a new shift pattern | The beat inside a shift. A takt that moves mid-shift is noise, not a signal |
| Work content | Kaizen at every station, and usually a new fixture or a new layout | The operator's pace. Pace is not a design variable — see [respect for people](/dictionary/respect-for-people) |
| Staffing pattern | Cost per unit rises until work content comes down to meet it | The operator count read as a layoff list. It is a design input |
| The demand you level to | A levelling window, and a finished-goods buffer to absorb the spikes | Takt reset to the last spike. Level demand first, then set takt to what you levelled to |

The common theme across all four rows is that your customer sets takt time, not you. So your two honest options are to change your process, or to change what you promise the customer.

If you recalculate takt time for every daily spike in orders, you introduce [mura](/dictionary/mura), which is unevenness you created yourself. That instability costs you more than the original spike did. Using [heijunka](/dictionary/heijunka), or production leveling, is what keeps one takt time believable for a whole shift.

## Using takt | What you do with takt time

Takt time is rarely something you post directly on a dashboard for daily monitoring. Instead, you use it as a foundation for other decisions, and each one turns the beat into a number somebody can actually watch.

### Pitch, the interval you can watch

It is difficult for a supervisor or team to track whether every single unit finishes within a `60`-second window. However, it is very easy to track completed containers. To create a practical tracking interval, multiply takt time by your standard container size.

If a container holds `20` units, then `60 × 20` = `1,200` seconds, which equals `20` minutes. This `20`-minute interval is called [pitch](/dictionary/pitch). During a `440`-minute shift, you will have `440 ÷ 20` = `22` pitch intervals and ship `440 ÷ 20` = `22` containers.

The two counts agree by design. You hand over one full container in every pitch interval. If your process falls behind, you will notice the issue within `20` minutes rather than discovering a shortage at the end of the shift.

```kz-photo
src: /guides/hour-by-hour-board/hero.webp
alt: A whiteboard ruled into time-block rows with columns for planned output, actual output and a reason for any gap, filled in by hand across a shift.
caption: **A board tracks pitch, not takt.** Plan against actual for each interval, and a written reason in the last column whenever the two differ.
width: 1376
height: 768
```

Teams often record this comparison on an [hourly production board](/dictionary/hourly-production-board). A related practice is [paced withdrawal](/dictionary/paced-withdrawal), where material is released one pitch of work at a time. That is what holds the beat in place, rather than assuming it will hold on its own.

### How many operators you need

To determine staffing, add up all the work time required across the entire process. Suppose your four workstations require `48`, `60`, `55`, and `52` seconds of work, giving a total work content of `215` seconds.

If you divide that total by takt time, `215 ÷ 60` = `3.58`, which rounds up to `4` operators. If you divide by planned cycle time to account for downtime, `215 ÷ 51` = `4.22`, which rounds up to `5` operators. Always round up, never down. You cannot staff a station with half a person.

While the basic calculation suggests `4` people, real lines run `5`. That extra person is not padding or slack. It is the same `15` percent of downtime, counted in the headcount instead of showing up as a shortfall at the end of the shift.

### Balancing a line against 51 seconds

If you plot station cycle times against both takt time and planned cycle time on the same chart, you get a much clearer picture of your line. A [yamazumi](/dictionary/yamazumi) chart drawn against a `60`-second takt line says the line is fine. Drawn against the `51`-second planned cycle time, three of the four stations sit over the line.

The second chart reflects what will actually happen during production. That is your real [line balancing](/dictionary/line-balancing) list, and it is why the comparison is worth drawing.

<!--TOOL:takt-->

### Levelling, maps and takt image

Calculating a single takt time for a shift assumes that customer demand is relatively steady. Production leveling, or [heijunka](/dictionary/heijunka), is the method used to smooth out demand so that assumption holds true. In practice, teams set takt time about once a month and watch pitch all day.

Takt time is also used beyond the line. It appears in the customer box on a [value stream map](/dictionary/value-stream-mapping). Experienced team members also develop what is called a [takt image](/dictionary/takt-image), which means they can sense when the pace of work is slipping before any board shows it.

You can watch this happen in the factory simulation. A green pulse appears at the shipping dock every `60` seconds, representing `440` bikes across `440` working minutes.

If you look at station S2, its eight work elements add up to exactly `60` seconds. S2 was built to match takt time instead of planned cycle time, so it runs over the beat about half the time and a queue builds up in front of it. This is Pass 1, happening in front of you.

<!--SIM:takt-time-->

## Common questions | Takt time questions people ask

```kz-qa
q: How do I calculate takt time?
a: Divide available time by customer demand for the same period. A shift with `440` available minutes — `26,400` seconds — against demand for `440` units gives a takt of `60.0` seconds per unit.
q: Does available time subtract breakdowns?
a: No. Subtract only what you planned not to run: breaks, startup and handover, planned changeovers, scheduled maintenance. Take out this shift's `30` minutes of breakdowns and `10` minutes of rework and takt drops from `60.0` to `54.5` seconds. You have now charged the same loss twice.
q: What is the difference between takt time and cycle time?
a: Takt time is the pace demand sets. Cycle time is what a station actually delivers. A third number sits between them: planned cycle time, which is takt multiplied by your uptime, or `60 × 0.85` = `51` seconds here. That is the number you build stations to. The [full comparison with lead time](/guides/cycle-time-vs-takt-time-vs-lead-time) works all three side by side.
q: Can takt time be used in a hospital or an office?
a: Yes. A clinic with `480` available minutes and `32` booked patients has a takt of `15` minutes. An hour-long visit still fits, because allowed cycle time per server is takt multiplied by the number of parallel servers: `15 × 4` rooms = `60` minutes.
q: What happens if we run faster than takt?
a: You overproduce. Output ahead of the beat turns into inventory, hides the problems that would otherwise stop the line, and is the first of the seven [wastes](/dictionary/muda). Takt is a ceiling as well as a floor.
q: How often should takt time be recalculated?
a: On a demand decision, not on a spike. Many teams review it monthly, or whenever the production plan changes. Reset takt inside a shift and the beat becomes unreadable to everyone working to it.
q: Where does the word takt come from?
a: From the German word **Takt**, a musical beat or bar. German aircraft makers used it in the 1930s to pace fuselage sections through fixed build positions. The idea reached Toyota after the war, where it became the pacing rule of the Toyota Production System.
```

Source: https://kaizumi.com/dictionary/takt-time
Licence: free to quote and cite with attribution to Kaizumi.