The screen your operators actually use during their shift.
One touch-screen console for downtime, scrap, quality checks, andon calls, issues, and the hour-by-hour board — configured for the line or machine it sits on.
Continuous improvement starts with operator engagement, and engagement starts with an interface they don't dread. The Operator Console is the home screen for everything an operator does during their shift — built for thick fingers, gloves, glance-friendly status, and the rhythm of the line.
Five tabs, four clipboards, and a clerk typing it all in at 5 p.m.
Most operators don't refuse to enter data because they're lazy. They refuse because the system is hostile — a 200-item dropdown built for the whole plant, three different logins, a clipboard that gets typed into the system after the shift ends by someone who wasn't there.
By the time the data shows up in a report, it's wrong, late, and impossible to act on. Supervisors stop trusting it. Operators stop entering it. The MES rollout from two years ago is now a Friday morning Excel export.
The Operator Console exists to make data entry the path of least resistance — to put the right button under the right finger at the right moment, so the data is captured while the operator still remembers what happened.
One screen. Every action the operator needs during their shift.
The hour-by-hour board at the top. The current state of the line front-and-center. Big touch buttons for the actions that matter — downtime, scrap, quality, issues, andon. Configured for this specific line, not a generic plant.
Mockup, not a screenshot — actual console layouts are configured per line and per customer.
Eight things operators do without leaving the console.
Each of these used to be a different system, a different login, or a different piece of paper. On the console, they're a tap away.
Annotate downtime
When the line stops, the console knows. The operator picks the reason from a short list configured for that line — not a 200-item dropdown built for the whole plant.
Record scrap and rework
Big-button entry for the scrap codes that actually happen on this line. Counts roll directly into production reporting — no double entry, no end-of-shift catch-up.
Perform scheduled quality checks
The console prompts operators when a check is due, captures the result, and won't let them dismiss it without entering a value. Out-of-spec entries trigger holds automatically.
Raise issues to maintenance
A leaking hose, a worn fixture, a bad sensor — the operator raises it once from the console. It lands in the Issues Tracker, gets assigned, and the operator can see status without leaving their station.
Activate andon calls
One tap calls the supervisor, materials, maintenance, or quality. The call is timestamped, tied to the line, and resolved with a reason — so you actually know why you stopped, not just that you stopped.
View the live production board
Hour-by-hour actual vs. target, right at the station. Operators see how the shift is going without waiting for a 4 p.m. printout. The line behaves differently when the score is on the wall.
See real-time SPC charts
For lines running SPC, the latest measurements show on the console with control limits drawn in. Operators see drift before it becomes a failure.
View work instructions and schedule
The current product's work instructions, the upcoming changeover, the sequence of jobs for the shift — pulled in from your ERP or schedule, displayed without a separate login.
The console at the press isn't the same as the one at packout.
Generic interfaces are the reason operators stop using them. Every console is configured around the work that actually happens at that station — and you change it when the work changes.
One console, configured per station
A press operator doesn't need the same buttons as a packaging operator. Each console is configured for the line or machine it lives on — different downtime codes, different scrap categories, different scheduled checks. We configure it during deployment; you can change it later from the Configuration workbook without code changes.
Turn off the features that aren't relevant
Some lines do SPC; most don't. Some need a visual inspection screen; some don't. Sheets are visibility-controlled per deployment, so the console you put in front of an operator only shows the buttons and screens they actually use. No clutter, no "what does that one do?"
Runs on the screens you already have
Touch monitor mounted at the line, ruggedized tablet on a cart, a shared kiosk between two machines — the console runs on standard Windows PCs and works with industrial touch screens. No proprietary hardware, no per-seat license games.
- Downtime: Material, Die change, Sensor, Hydraulic, Operator
- Scrap: Mis-strike, Burr, Dim. out, Surface
- Quality: Weight every hour
- Andon: Maintenance, Materials
- Downtime: Label, Sealer, Carton, Conveyor, Changeover
- Scrap: Label, Seal, Damaged, Short-pack
- Quality: Seal test every 30 min · Visual every hour
- Andon: Supervisor, Materials, Quality
Every tap flows into the platform. Nothing has to be re-typed.
The console is where the operator works, but the data lives in the 10in6 platform. A downtime entry feeds OEE. A scrap entry rolls into scrap-by-component. An issue lands in the work-order queue. Same database, no integration step.
- Downtime reasons → Production Reporting & OEE
- Scrap counts → Scrap by Component & rolled OEE
- Andon calls → Real-time visibility boards
- Scheduled quality checks → Audit-ready history
- SPC entries → Control charts & alerts
- Visual inspection → Defect tracking by station
- Operator-raised issues → Maintenance work orders
- Equipment-level history → Reliability reports
- Maintenance checks → PM compliance
Need this configured around your real workflow?
Every 10in6 deployment includes our team — connecting your equipment, configuring your workflows, and supporting your operation long after go-live.
The console is the difference between a system that gets used and one that gets exported to Excel.
An MES is only as good as the data the operator gives it. The data is only as good as the interface the operator gives it through. Get the interface right, and the rest of the platform earns its keep.
Engagement is the lever, not the dashboard
Plants that have tried three different MES rollouts in the last decade almost always share the same story: the dashboards were beautiful and the operators ignored them. The console flips that — the operator is the one entering the data, so the data is theirs, and the score on the wall is theirs.
No more shift-end catch-up
Without a console, operators write downtime reasons on paper and a clerk types them in at 5 p.m. The reasons are vague, the times are wrong, and the data is unusable. A live console pushes entry to the moment it happens — when the operator still remembers why.
15+ years of operator console deployments
10in6 has been refining this interface since 2008. The button sizes, the flow, the way downtime gets coded — every detail is the result of a real operator on a real floor either tapping it or refusing to. Nothing in here is theoretical.
Touch-first, but works without
Designed for industrial touch screens, but mouse-and-keyboard friendly for engineering stations and supervisor desks. The same workbook runs on every form factor — no separate "mobile" version to maintain.
Operator consoles running in production today
Common questions
Is the Operator Console a separate product, or part of an existing module?
It's the operator-facing surface for the entire 10in6 platform. The same console is where operators enter downtime (MES), record scrap (MES), perform quality checks (DQS), and raise maintenance issues (CMMS). One screen, one login, one place for operators to live during their shift.
Do we need a touch screen?
It's designed for touch and that's how most customers deploy it. But it also runs perfectly well with a mouse and keyboard on a regular PC — useful for engineering stations and supervisor offices. Buttons are sized for finger taps; you don't lose anything if you click instead.
How do we configure which buttons appear on which line?
Everything is configured through the 10in6 Configuration workbook. Sheets, buttons, downtime codes, scrap codes, and which features are enabled are all controlled per line or per machine. Most customers make routine changes themselves; we handle the initial configuration during deployment.
Can the same console serve two machines?
Yes. A kiosk between two machines is a common pattern — the operator picks which line they're entering data for. We also support one console per machine, and consoles on shared carts that move between cells.
How does the operator log in?
Most deployments use a short PIN, badge scan, or RFID tap — whatever the customer already uses on the floor. The login ties downtime reasons, scrap entries, and issues back to the operator without making them type their full name every action.
Does this replace our ERP?
No. The console is a shop-floor execution interface. It pulls schedule and work instructions from your ERP when relevant, and pushes production counts back, but the ERP stays the ERP. Operators do shop-floor work on the console because the ERP wasn't built for that and trying to use it that way is part of why they stopped entering data.
What if the line stops and nobody codes the downtime?
The console treats uncoded downtime as a visible debt — the red "Annotate Downtime" button shows the minutes accumulating. Supervisors can see at a glance which stoppages haven't been coded. You can also configure rules — for example, after 5 minutes uncoded, the supervisor gets paged.
How does it handle changeover?
When the line changes products, the console picks up the new part number from the schedule, updates work instructions, swaps in the right downtime codes if they differ by product, and tracks changeover time as its own loss category. Operators don't have to remember to flip anything.
Can multiple operators share a console?
Yes. Several operators can be signed into a line simultaneously, and downtime / scrap / quality entries are attributed to whoever performed the action. Shift change is handled with a clean sign-out/sign-in flow.
How long does deployment take?
A focused first console — one line, the standard set of buttons, downtime and scrap codes already defined — typically goes live in two to four weeks. Multi-line rollouts and consoles tied into ERP for work instructions and scheduling take longer; the integration work is usually the long pole.
See it running on your line.
The fastest way to know whether this fits your floor is a 30-minute walkthrough on your operation. Tell us what your operators do today and we'll show you what the console would look like at your press, your packout, or your assembly cell.
- No prep needed — we'll come ready.
- Live product, not slides.
- 30 minutes, screen share, real workbook.