An andon system for a small shop, without the light tower

Andon gets talked about like it belongs only in a Toyota plant: stack lights on every station, a cord along the line, a big board overhead counting faults in real time. That picture scares small shops off, because none of it is in the budget. But the andon idea is much simpler than the hardware it usually ships with. An andon is just a fast, visible way for an operator to say "I am stuck, I need help" — and a rule for who comes running. You can have that on a 12-person floor for the cost of the phones already in people's pockets.

This article covers what an andon is actually for, what to signal, how to escalate when you do not have a PLC wired to a light tower, and — the part most shops skip — how to make every andon call land in your downtime log so the signals turn into a ranked list of what to fix.

What an andon actually is

Strip away the lights and an andon does three jobs. It signals that a station needs attention. It escalates that signal to the right person fast, so the operator is not standing there waving. And it records that a call happened, so you can count and rank the calls later.

Most small shops already do the first job badly and skip the third entirely. The operator shouts across the floor, or walks off to find the supervisor, or just waits — and nobody writes any of it down. The machine was stopped for 25 minutes waiting on material, and by the end of the shift that time has vanished. No signal, no record, no Pareto. The andon's real payoff for a small manufacturer is not the dramatic "stop the line" moment; it is turning every one of those silent waits into a timed, categorized event you can act on.

You do not need a light tower

A physical andon board is worth it when stations are far apart, the line is loud, and seconds of reaction time matter on a high-volume line. On a small, high-mix floor, the economics are different. The calls are less frequent, the floor is small enough to cross in 20 seconds, and the thing you most lack is not reaction speed — it is a record of how often help was needed and why.

So start with what signals and records at the same time: a phone or tablet call. An operator taps a station, picks a reason, and the call is both sent and logged in one action. No wiring, no PLC integration, no stack light to mount. You can add a cheap light later if a specific machine genuinely needs a glance-able status, but the signal-and-record loop does not depend on it. This is the same shift covered in how to track machine downtime: the moment of logging and the moment of signaling should be the same tap, or one of them quietly stops happening.

What to signal

An andon with twenty call types is an andon nobody uses. Keep the list short and make every type map to a different responder. For most small shops, four or five cover almost everything:

These should line up with the reason codes you already use on the downtime log — if your andon call types and your downtime codes are different vocabularies, you will be translating between them forever. Build the andon list straight off your existing codes. For a starting taxonomy, see a practical machine downtime reason code list.

Material shortage — out of stock at the station, waiting on a kit or a refill. Responder: material handler or lead.
Machine fault — the machine stopped, jammed, or is throwing an alarm. Responder: maintenance.
Quality check — a first-article or in-process check is needed before the operator continues. Responder: quality or the supervisor.
Tooling / changeover help — a changeover is running long or a tool needs swapping. Responder: setup tech or lead.
Safety — anything unsafe. Responder: everyone, immediately.

How to escalate without a PLC

Escalation is the rule that answers "who comes, and what happens if nobody does?" On a wired line the light climbs from yellow to red and a buzzer sounds. On a small floor you reproduce the same intent with people and a timer:

The discipline that makes this stick is that raising a call must be easier than not raising one. If logging an andon means filling in a form, operators will skip it and go back to shouting. One tap, one reason, done.

Call goes to the named responder for that type. Material shortage pings the material handler, not the whole shop. A call that goes to "everyone" gets answered by no one.
If it is not acknowledged in N minutes, it escalates. Set a threshold per type — maybe five minutes for a machine fault, fifteen for a quality check — and if nobody has picked it up by then, it rolls up to the supervisor. A reminder or notification does this automatically so it does not depend on the operator chasing anyone.
The clock runs the whole time. The call is timestamped when it is raised and closed when the station is running again. The gap is the response-plus-resolution time, and it is the number that tells you whether your escalation rule is working.

Worked example: one week of andon calls on a small floor

Here is what a week looks like on a hypothetical 12-person shop running three CNC cells and a small assembly bench. Every andon call was raised from a tablet at the station, timestamped, and closed when the station resumed. At the end of the week you simply group the calls by type.

That is 613 minutes — just over 10 hours — of stations stopped and waiting in one week, on a floor where nobody would have said they had a 10-hour problem, because none of it was written down before.

Now read the table two ways, because frequency and duration point at different fixes:

Without the andon calls being logged, you would have felt "the machines are always down" and chased the wrong thing. With one week of timed calls you can see that material shortage was raised almost twice as often as machine faults, and that the single longest category to resolve is the one maintenance owns. That is the whole point of an andon on a small floor: it converts a vague sense of chaos into 32 timed rows you can rank.

By lost time, two types own the floor. Machine fault and material shortage together are 450 of 613 minutes — about 73% of the lost time from two of five call types. This is the usual Pareto shape, and it tells you where to spend improvement effort first. (For how to build this chart properly and read the vital few, see how to build a downtime Pareto analysis.)
By call type, the fixes are not the same. Machine fault is rare but long — 6 calls averaging 42 minutes from raise to running again. That is a maintenance problem: better PMs, faster parts access, maybe a spare on the shelf. Material shortage is frequent but shorter — 11 calls at 18 minutes each. That is a supply problem: a kanban refill point or a staged kit, not a wrench. Same Pareto, two completely different countermeasures.

Connect the andon to your downtime log

The mistake that wastes an andon is treating the signal as disposable — the call gets answered, the station runs again, and the event evaporates. If the call is only a notification, you are back to no record. The fix is to make the andon call be the downtime entry: raising it opens a timed event with a reason code, and closing it stamps the duration. One action, one logged row, feeding the same Pareto you would build from any downtime log.

This also kills double-entry. If the operator raises an andon and then someone is expected to separately write the stop into a downtime spreadsheet, the second step dies within a week. When the andon call and the downtime record are the same object, the log stays complete for free, because logging is a side effect of asking for help.

Where HelpFab fits

HelpFab turns the signal-escalate-record loop into one tap without any floor hardware. An operator raises the stop from a phone or tablet on the Log downtime page, choosing from your own configurable reason codes — the same codes that drive the rest of your downtime reporting. The call is timestamped when it is raised and when the station is running again, so the duration is captured automatically rather than guessed.

The escalation rule above is built in. Turn on andon for any timed reason code, name its responder, and set how many minutes a call can wait. The responder gets a push notification on their phone — HelpFab installs as an app, no app store needed — plus an email with a one-tap acknowledge link; if nobody acknowledges in time, the call escalates to your company admins. The Andon board lists every open call with its status — raised, acknowledged, or escalated — and how long it has been waiting, and a board mode turns a spare screen on the wall into the overhead display, without a PLC behind it.

And because every call is a logged downtime event, the week of calls above is already a report: the Downtime Pareto on the Downtime Reports page ranks your call types by lost time without anyone rebuilding a spreadsheet. Operators logging stops as they happen, right where the work is, is exactly the shop floor visibility a small team needs.

You do not need a light tower to get the benefit of andon. You need a signal that is easy to raise, a rule for who answers and when, and — the part that pays you back for years — a record of every call so you can rank what to fix. Start with the phones you already have, keep the call list short, and make every signal land in the downtime log. The lights can wait.

Latest articles

CMMS vs downtime tracking software — A CMMS manages assets and work orders; downtime tracking logs every production stop. Different jobs, not competitors — here is when a small shop needs each.
Track changeover time first, then SMED it down — Measure changeover time before you improve it - split internal from external work, see a worked die-change breakdown, and learn exactly what to log.
A production downtime report example, daily and weekly — A worked production downtime report for a CNC cell, the four numbers managers actually read, and a layout that turns lost minutes into action.
MTTR and MTBF: how to track them from your downtime log — Track MTTR and MTBF from your downtime and maintenance logs - the formulas, a worked quarter on one machine, and the mistakes that corrupt both numbers.
Maintenance log vs downtime log — Maintenance log vs downtime log - what each one captures, why a plant needs both, and how a single breakdown links them to give you MTTR and MTBF.
Choosing a downtime tracking app for a small manufacturer — What a small shop should look for in a downtime tracking app: phone logging, configurable reason codes, and reports you can read without an ERP.
How to reduce unplanned downtime in manufacturing — A track-first playbook to reduce unplanned downtime - log every stop, Pareto the causes, then attack the vital few with PM and root-cause fixes.
How to calculate the cost of unplanned downtime — A cost-per-hour formula for unplanned downtime, with a worked molding-cell example covering labor, scrap, lost margin, and overhead.
A free downtime tracking Excel template (and how to actually use it) — A free Excel downtime log template — the columns, a reason-code list, and the pivot that turns raw stops into a Pareto, plus when to move off it.
OEE availability: how to calculate it from your downtime data — Calculate OEE availability from your downtime log, with a worked CNC example — plus the reclassification tricks that quietly inflate the number.
How to build a downtime Pareto analysis — Build a downtime Pareto step by step with a worked stamping-line example that finds the few causes driving most of your lost minutes.
A practical machine downtime reason code list — A starter taxonomy of machine downtime reason codes — planned vs unplanned, with real fault-code examples and rules that keep operators logging honestly.
Downtime tracking spreadsheet vs software — When an Excel downtime tracker is enough and when it quietly breaks — a shift-by-shift comparison for small manufacturers, with a real cost example.
How to track machine downtime — Move from a paper downtime log to structured tracking: reason codes, who logs what, and the three reports that actually change decisions.