“How fast should we respond to an andon call” sounds like it should have a single answer. It doesn’t, because there isn’t one call to respond to, there are two, and they’re not the same problem. An operator pushing a button is asking two separate questions in sequence: is anyone coming, and then, once someone’s there, how long until this is actually fixed. Plants that set one target for “response time” and call it done are usually measuring only the first question, and the second, often where the real cost sits, goes unmeasured.
Two clocks, not one
Call to acknowledge is the first clock. It starts the moment the button gets pushed and ends the moment somebody takes ownership of the call, on their way. Acknowledge to fix is the second clock, and it starts right where the first one ends. These behave completely differently and need different targets, because one is mostly about coverage and urgency, and the other is mostly about the actual difficulty of the problem.
Conflating the two is how a plant ends up gaming the wrong metric. Tapping “acknowledged” from a desk without walking over keeps the first clock looking fast while doing nothing for the second, and an andon program that only tracks one blended number can’t tell the difference between a floor that responds fast and one that’s just good at pressing a button quickly.
What a reasonable target for call to acknowledge looks like
Call to acknowledge is mostly a coverage and staffing question, not a difficulty question, which is what makes it realistic to set a hard target for. A line-down call, the whole cell stopped, waiting, is worth treating differently from a material request that can wait a few minutes without costing anything. Most shops that get this right set targets by severity instead of one blanket number: something in the one to two minute range for a call that’s actually stopping production, and a looser window, five to fifteen minutes, for a request that’s real but not urgent, a material top-off, a quality question that doesn’t halt the line.
What actually happens in practice tends to land close to whatever the staffing model supports. A cell with a floating tech assigned to exactly that area hits sub-two-minute acknowledges consistently, because someone’s already close and watching for the light. A cell where the same tech covers four areas at once will structurally run slower. Nobody’s careless. One person cannot be four places at once, no matter how good they are. Setting a target that ignores that reality just produces a number everyone learns to distrust.
What a reasonable target for acknowledge to fix looks like
This clock resists a single target far more than the first one does, because the time to actually fix something depends on what’s broken, and what’s broken varies by orders of magnitude. A sensor that needs recalibrating is a five minute fix. A bearing that needs sourcing from a supplier three states away is not fixable in an afternoon no matter how motivated the tech is, and setting a universal fifteen minute target for “fix time” just produces a number that’s meaningless for half the repairs it’s supposed to measure.
The more workable approach most shops land on is tracking mean time to repair per failure type or per asset, not one plant-wide target, alongside how often repairs blow past whatever reasonable window that specific kind of failure usually takes. MTTR and MTBF for a Plant Floor covers how to build that number so it’s trustworthy instead of noise. A fast acknowledge paired with a slow, unpredictable fix time is still a real gap worth managing. It’s a parts-and-planning gap instead of a people-showing-up gap, and the fix looks completely different: stocking a critical spare, or pre-staging a common repair kit, instead of adding staff to the floor.
Setting a target that survives a busy floor
A target set once in a conference room and never revisited tends to drift out of touch with reality within a quarter. The floor gets busier, staffing changes, a line gets added, and the target that made sense in January has gone unrealistic by June without anyone flagging it, at which point people either stop trying to hit it or start gaming it, tapping acknowledge from across the plant just to stop the clock.
The fix is treating the target as a living number, reviewed against what’s actually being achieved every month or so, not a rule carved in at kickoff. If a severity tier is missing its target consistently, ask whether the target was wrong or the coverage was wrong before assuming the team isn’t trying. A target missed by everyone, every week, for months, usually means the target needs adjusting or the staffing model needs a second look, not that the whole andon program has failed.
Watch the spread, beyond the average
An average acknowledge time can look fine while hiding a real problem, the same way an average changeover time can. A cell averaging ninety seconds to acknowledge, with almost every call answered in under a minute and a rare outlier taking twelve minutes because the one covering tech was on break, looks identical on a monthly average to a cell that answers every single call in exactly ninety seconds. Those are two very different floors to work on, and only one of them has a coverage gap worth fixing.
Looking at the worst cases in a window, beyond the mean, is what surfaces that difference. A handful of calls that sat far longer than the target, even if they’re rare, point at exactly when coverage breaks down: a specific shift, a specific break window, a specific area where the assigned tech is stretched across too much ground. Fixing that specific gap usually does more for the floor’s actual reliability than shaving a few more seconds off an average that was already fine.
An escalation path, used sparingly
A per-severity time threshold that pages someone else, or re-notifies the assigned group, once a call has aged past its target without action, catches the case that actually matters most: a call sitting with nobody coming at all. That’s different from chasing every call that ran a little long. An escalation exists to catch a coverage gap while a machine is still down and something can still be done about it, not to flag a person as slow on one specific repair after the fact, when it’s too late to matter.
Quick recap
- Call to acknowledge and acknowledge to fix are two different clocks. Blending them into one number hides which half is actually the problem.
- Set acknowledge targets by severity: under a couple minutes for a line-down call, a looser window for something that isn’t stopping production.
- Fix time resists a single universal target. Track it per failure type or per asset instead of forcing one number onto every repair.
- A target set once and never revisited drifts out of touch with the floor within a few months. Review it against reality regularly.
- Use escalation to catch a call with nobody coming, not to chase every repair that ran a little long.