Multichannel andon with SLA — if the owner isn't watching the screen, the alert dies.

The problem

The classic andon does exactly what it was built for — but today's plant isn't entirely inside the plant.

The andon (the coloured stack light, the screen with indicators) was designed for a building where the owner is also present. They see it, acknowledge it, resolve it. The problem isn't the andon — it's that the owner is less and less often in front of the screen. They're on a site visit, in a customer meeting, supervising a second plant, or on a technical visit to a supplier.

That turns the andon into a thermometer in the dark: it logs the incident, but the clock keeps running until somebody sees it. In plants with short shifts and lean headcount, the difference between the alert reaching the decision-maker at minute zero or at minute twelve can be the difference between a five-minute stoppage and a forty-minute one.

The usual workaround — a WhatsApp group where the shift leader posts photos of the andon, or an automatic email with the subject «LINE 3 ALERT» — works 90% of the time. The other 10% is what wrecks the month's OEE. And nobody has a clean MTTR curve per shift, because nobody fills in a spreadsheet at three in the morning.

How it fits the IRIS system

iLEAN doesn't replace your andon — it escalates what the andon already triggers to the channel where the owner actually is.

The andon is capture: it records that something is wrong. What's missing between capture and action is reliable transport to the right person. That's the sealant iLEAN brings — it seals the crack between the stack light on the floor and the owner who is busy elsewhere, without asking you to change your andon system or the SCADA that feeds it.

The andon triggers. Connect transports to each profile's channel. The agent respects the SLA and escalates by level if there's no acknowledgement. The person signs off — the clock stops when they acknowledge, not when they read.

The three iLEAN pieces applied to multichannel andon with SLA:

• Connect — listens to your andon (via SCADA, IoT, direct integration with the stack light, or reading the spreadsheet/MES that logs it) and sends on each profile's channel. Slack for the maintenance team that's already there; WhatsApp for the shift leader who almost always has the phone on them; Teams for the plant director; a transcribed phone call if nobody acknowledges within X minutes. Bidirectional: the owner replies "on my way in 2 min" and the agent logs it.
• Agent — lives in Central 24/7 and applies the SLA matrix your team defined (which incident, which threshold, which escalation level). It doesn't improvise: it follows the rule exactly. If nobody acknowledges the alert, it escalates to the next level — not "remind the manager" with another WhatsApp, but escalate to the director.
• Writer — generates the incident record on closure: when it fired, on which channel it was acknowledged, what was done, how long it lasted. It does so for a human to review — the data stays clean, with nobody filling anything in after the fact.

See the full IRIS architecture →

Before and after

Classic andon vs. multichannel andon with SLA

Aspect	Classic andon (screen + stack light)	With iLEAN Connect + Agent + Writer
Reaching the owner	Whenever they look at the screen	WhatsApp/Teams/Slack at second zero, per profile
Escalation without acknowledgement	Ad-hoc WhatsApp group	Automatic SLA cascade to the next level
MTTR clock	Estimated from SCADA logs	Real: from the alert to the owner's "acknowledged"
Traceability per incident	Spreadsheet filled in by the shift leader	Automatic record: channel, person, timings
Owner's language	One (the plant's)	Whichever each profile uses — foreign-language shifts included
Channel saturation	Risk of "everything is urgent"	SLA per incident type — only what warrants it

Impact estimate

Impact estimate for your plant — to be validated with your numbers.

The block below is an estimate to be validated with your plant's concrete data. We lay it out so the committee has an order of magnitude; we refine it during the diagnostic.

• Multi-line plant (typically 3–6 lines) with a classic andon already installed and a % of alerts that get "dropped" because the owner is absent.
• Connect + Agent pilot on one line or shift: integration with the existing andon, an SLA matrix agreed with operations, escalation to WhatsApp + Teams. First value expected within a few weeks.
• Estimated MTTR reduction of ≥ 30% on today's "orphan" alerts — the real figure depends on the baseline. Indicative payback between 4 and 9 months.
• The hard lever: every minute of line stoppage avoided has a cost per minute the plant team already knows. Multiplied by the MTTR reduction on orphan alerts, it pays back the pilot fast.

And the honest objection from operations

"If I put WhatsApp into the andon, I'll saturate everyone and people will end up muting the group." That's precisely the antipattern to avoid: over-validation that kills the system. That's why the SLA matrix is the first thing defined with operations — which incident, which threshold, which level. The agent respects the threshold and only escalates what it should. Noise is what kills the andon on the screen; noise would kill the multichannel andon too if it weren't calibrated. That's why it gets calibrated.

And for the CAIO's question: hallucination is a problem of free generation, not of anchored tasks. Deciding whether an alert crosses the SLA threshold and to whom it should be escalated is the most anchored task there is — the best models brought the error rate below 1.5% ^[1]. And even so, the incident acknowledgement is signed off by a person, not by the agent.

^[1] OpenAI paper "Why Language Models Hallucinate", 2025 — on the reliability of AI in anchored tasks.