Andon Escalation Rules: Call, Response and Timeout Tiers

Why escalation rules matter more than the call button

Escalation rules decide how quickly an exception is picked up, because pressing a button only turns a problem into a signal; what actually restores the line is someone arriving within the agreed time. When designing the rules, split the response chain into three clockable roles: the station that spots the problem first, the first-line support that handles it, and the management layer that controls resources. After a call is raised, the system advances it tier by tier, and each tier has an explicit waiting limit; if nobody accepts the call within the limit, the signal moves to the next tier automatically and keeps a complete record of acceptance, arrival, handling and closure.

What separates andon from an alarm dashboard is that it measures response, not values. A dashboard tells you the temperature is high; andon tells you whether anyone acted on the high temperature within the agreed limit. The rules therefore have to define two things at the same time: the type and severity of the exception, and who owns each tier and within what time they must respond. Once both are defined, the reports become meaningful and can answer which exception type times out most often.

Table: time limits and owners across a three-tier escalation chain (adjustable to crew size)

The column most often overlooked is the trigger. On many sites a call button carries only one meaning, so a material shortage, a blockage and a stalled machine all send the same signal; every exception then crowds into one channel and nobody can judge which to handle first. The starting point for escalation rules is therefore to let calls carry a type.

The four settings that decide whether the rules hold

No matter how complete the rules look on paper, if the four settings below are not settled, the plant drifts back to phoning around after go-live.

• Set the waiting limit per exception type: a line stop that affects takt and a routine material wait should not share one limit; mixing them drowns urgent calls in ordinary ones.
• Make escalation automatic, never a manual click: moving the call on at timeout is part of the rule itself, and if a line leader has to click to escalate, that rule is the first to be skipped when things get busy.
• Bind receiving roles to positions, not people: notifying a line leader or on-duty engineer as a position keeps the chain intact through shift rotation and leave.
• Record every acceptance, arrival and closure: only a traceable rule can be used for later review, and only then can it support crew response assessment.

The second setting is the one that most tests the early design. It requires the call signal not to be an isolated button box but to feed a software system that can trigger notifications. A common approach is to connect the call box through a PLC or fieldbus to an acquisition gateway, and let the upper-layer software push to crew messaging, the shop-floor board and the on-duty mobile according to the rules. Escalation is then executed by the software while operators simply accept and resolve the call, with no need to remember to escalate.

The call reason dictionary: turning escalation rules into analysable data

A single shared call reason dictionary is what keeps the chain effective over the long run. The dictionary sorts every plausible exception into a limited set of categories in advance, such as material shortage, equipment fault, quality issue, tooling problem or technical support needed, and each category carries its own escalation chain and time limit. A few lessons apply when maintaining it: keep the number of categories within what a crew can remember, usually a dozen or so is enough; give every category a clear judgement basis so the same event is not filed differently by different crews; and keep the dictionary maintainable so new lines or stations can be added with their own entries.

Once the dictionary is unified, call records can be counted and analysed. You can see by category which exception type escalates most often, by shift when escalations cluster, and by resolution time which stations escalate repeatedly without resolution. These statistics do not change the rules themselves, but they show where the rules need adjusting, for example a limit set too tight for one category, so that many calls that could have been resolved on site are escalated unnecessarily and management is pulled in without cause.

Andon records also have the advantage of running continuously across shifts. A call on the night shift and its acceptance and resolution on the day shift fall into one record, so the handover no longer depends on verbal repetition. For workshops running continuous multi-shift production, this matters more to whether exceptions are truly closed than the response speed of a single shift.

Go-live and acceptance: test the rules before handover

Before go-live, it is worth running the whole escalation chain through once under real or simulated conditions to confirm the rules match the shop floor.

• Call to notification: after pressing the station button, does the system notify the right position within the set limit.
• Timeout to escalation: if nobody accepts within the tier 1 limit, does the signal move to the next tier automatically and keep the tier 1 timeout record.
• Acceptance and closure: are acceptance, arrival, handling and closure recorded completely, with timestamps and owners.
• Traceable history: can past calls be queried by category, shift or station for later review.
• Board synchronisation: do the shop-floor board and crew messaging show the same call status, so the two do not diverge.

Once these checks pass, the escalation rules are genuinely delivered rather than just a button. Orpaon andon projects usually follow this order: confirm the call types and escalation chain, then settle the limit and receiving position for each tier, then complete signal connection and notification channel configuration, and finally run the acceptance list above in full. We have previously delivered an integrated LED andon and equipment connectivity system on a discrete manufacturing line (public reference: a Japanese-owned home appliance group, Shanghai plant), linking station calls, on-site display and network communication on one path, and can customise on that basis according to line conditions.

Where equipment brands are mixed and protocols are not standardised, the first step also requires an equipment and protocol inventory to confirm how call signals are acquired and how notifications are delivered. Once those prerequisites are clear, the design and validation of the rules go much faster.