The Machine That Cries Wolf

The Company

Veldkamp Precision Parts runs three CNC machining lines out of a facility on the edge of Eindhoven. About 70 people, mostly on the floor. They make tight-tolerance components for automotive tier-2 suppliers, where a deviation of a few microns is the difference between shipping the order and eating a penalty. Their client contracts have zero-defect clauses written in, so scrap isn't just a quality problem, it's a financial one.

The Pain

Joost is the production manager. He runs shifts across all three lines and he's responsible for catching quality problems before they become customer problems. The way it works right now: operators log readings into the MES during the shift, but nobody's actually watching those numbers in real time. Joost finds out something went wrong at his end-of-shift review, or when an operator comes to find him, or — worst case — when a client calls. By then the job has run on for another hour or two, more scrap has come off the line, and he's reconstructing what happened from memory and partial logs. He spends the start of the next shift on the phone instead of on the floor.

The Move

You set up an agent that sits on top of the MES data and watches scrap rate and cycle time readings as they come in, shift by shift, job by job. Each job has its own tolerance thresholds — what's acceptable for one part number isn't the same as for another. When a reading breaches the limit for that specific job, the agent doesn't just flag it. It sends a structured message to Joost and to the operator on that machine: which order is affected, what the reading was, a plausible hypothesis for what caused it (tool wear, material feed rate, fixture drift — whatever fits the pattern), and a suggested first action to try. Not a dashboard that requires someone to go and look. A message that arrives the moment the breach happens.

You can build this today with Make or n8n pulling data from the MES via API or a scheduled read, an LLM call to generate the hypothesis and suggested action from the job parameters and the breach details, and a message pushed to WhatsApp or Teams. No developers needed. A few days of setup work, mostly configuration.

The blind spot

Everyone assumes the MES already does this. It logs the data, so it must be alerting on it. But most MES setups at this scale are configured to record, not to act. Nobody's gone in and set per-job thresholds with an outbound alert attached, because that's fiddly and it never felt urgent enough to prioritise. So the data is all there, sitting in the system, and Joost still finds out too late.

The pattern

The same move fits a lot of other situations:

• A logistics company where a transport coordinator only finds out a delivery is running late when the driver calls in, not when the delay actually starts.
• A clinic where a practice manager reviews no-show rates weekly, by which time the appointment slots are already gone.
• A wholesaler where someone checks stock levels each morning, but a fast-moving line runs out midday and nobody notices until the next day's pick.