- Home
- Blog
- Shop Floor Execution
- Training Your Floor on the Kiosk in One Shift
A shop floor terminal training session that works is about twenty minutes long, teaches one loop rather than one screen, and spends its remaining time on the three habits that decide whether the data is worth collecting. Shop floor terminal training fails when it is treated as software training, because the software is not the hard part.
The terminal is deliberately small. It has no login, no account, and no plant-wide browsing; it is bound to one work center and one machine, and it shows that machine's queue. See why the kiosk has no login. Almost everything a supervisor needs to teach is about when to tap, not where.
Start With the Question They Are Actually Asking
Whatever you put on the agenda, the first real subject of the session is whether this is a stopwatch pointed at the operator. Raise it yourself in the opening minutes and the rest of the session goes differently.
There are two honest answers, and both are demonstrable on the screen.
Only run time, and rework, counts toward the job's production hours. Setup, pauses, and downtime are recorded separately and stay out of that figure, so an operator's day is not judged on a coolant leak or a long changeover. And every pause carries a reason from four categories, which means lost time is attributed to its actual cause rather than to whoever was standing there when it happened.
Show them the handoff summary, which splits the shift into setup, run, and down hours with recent pauses listed underneath. A floor that can see those three kept apart accepts the terminal far more readily than one told to trust a single number. See reading a shift handoff summary.
Teach the Loop, Not the Screen
Walk one complete job before explaining any panel.
Type a name in the Operator box. Tap Start Setup on the job the screen offers. Advance through the setup phases, one tap each, as the changeover really goes. On the last phase the advance button reads Start Run: tap it, and the run begins. Count good pieces as they come off. Pause with a reason when something stops. Complete the operation when it is done.
That is the whole loop, and it covers the overwhelming majority of what an operator will ever do. See how the kiosk captures a production punch for what each tap writes.
Two details are worth pointing out while their hands are on the screen. The Start Setup button does not move between releases, deliberately, so muscle memory is respected and the loop they learn today is the loop they use next year. And the setup ribbon's advance button always names the next phase, so nobody has to remember the sequence.
The Order That Works
| Block | Minutes | Teach | Skip for now |
|---|---|---|---|
| The concern | 5 | Run versus setup versus down; every pause has a reason | Anything about reports |
| The loop | 8 | One full job, hands on the screen, start to complete | Header utilities, edge cases |
| Counting | 3 | Good taps, scrap with a reason, the undo window, edit counts | Rate and piece conversion arithmetic |
| Pausing | 2 | The four categories, resume, leaving it paused overnight | The full reason catalog |
| The two banners and prompts | 2 | Acknowledge the routing-changed warning and tell the planner; what the prior-steps prompt is asking | Why the prompt exists |
| Utilities | 3 | Manual entry, handoff, switch work center | History drawer detail |
| The boundary | 2 | The terminal reports, it does not re-plan | How the scheduler works |
Twenty-five minutes, and the last row matters as much as the first. Operators need to know that a queue which looks wrong is something to report rather than something to fix, because the terminal cannot re-sequence work. See when the kiosk queue and the floor disagree.
The Three Habits That Decide Data Quality
Everything above is mechanics. These three are what separate a floor whose punch data can be used from one whose data is decorative.
Count as pieces come off, not at shift end. A running count survives interruptions and shift changes. A remembered count does not, and it arrives rounded. Teach the undo control in the same breath, because the reason people batch counts is fear of tapping wrong: after each piece tap an undo appears for about ten seconds and takes the last count back, and the undo itself is logged. See the ten-second piece undo at the kiosk.
Pick the honest pause reason. The four categories are the basis of every downtime analysis the plant will do. A broken spindle filed under waiting sends maintenance nowhere, and it does so invisibly. If your reason catalog has work center specific codes, show the ones that apply to this machine rather than the whole list. See building a reason code catalog for your work centers.
Do not skip the setup phases. Six taps per changeover is the entire cost, and phase times are the one thing typed totals can never reconstruct. An operator who advances through all six phases in one go at the end has produced a record that says nothing about where the changeover time went.
Each of these is a habit, not a skill. They form in the first week or they do not form, which is why a supervisor's presence on the floor during the first few shifts is worth more than a longer classroom session.
What to Let Them Get Wrong
Trainees who are afraid of making a mistake stop reporting, which is the only outcome that genuinely costs you. So say out loud which mistakes are free.
A double tap on the good counter is free: undo it, or replace the totals through edit counts. A wrong pause reason is free: change it, or let a supervisor fix it later. A day that never got punched at all is recoverable through manual entry, which opens the same day grid a planner uses. And a punch left running past the end of work is a supervisor correction, not a disaster.
What is not free is silence. A shift with no data at all leaves the plan believing work is still waiting, and the next scheduling run re-plans operations the shop already finished. An imperfect punch is always better than no punch, and telling operators that explicitly is one of the highest-value sentences in the session.
Then tell them where corrections live, so they know escalation is cheap: see who may correct a kiosk entry and when to escalate.
The One Gotcha Worth Pre-Empting
Every shop reports the same first-week question, and thirty seconds of training removes it entirely.
Pieces only count during a run. If the current punch is a setup phase or a pause, the counters will not increment, and to a new operator that reads as a broken screen. They tap the good counter, nothing happens, they tap harder, still nothing, and the conclusion they draw is that the terminal cannot be trusted.
Say it before it happens: if the counter is not moving, you are not in the run. Resume, or finish advancing through the setup ribbon, and it will move. Pair it with the reason the rule exists, which is that piece counts are production output and production output belongs to run time, the same separation that keeps setup and downtime out of the job's production hours.
The related habit follows naturally. Tap Resume promptly after a pause, because a run that is not running is a run that is not counting.
The Two Prompts Worth Explaining Properly
Most of the terminal needs no explanation. Two things do, because guessing at them causes real damage.
The routing-changed warning appears when the job's routing was edited after the job was planned, and it lists what changed. The instruction is short and both halves matter: tell the planner if it looks wrong, then acknowledge it. Acknowledging without telling anyone is how a stale routing runs all week. See the BOR drift banner at the kiosk.
The prior work centers prompt appears when earlier steps of the job have no actuals logged. Accepting it fills those steps in from the plan, tagged so a planner can review them; canceling it stops so the earlier work can be reported properly. Teach the default as cancel-and-mention, because accepting is a decision to let a guess stand and it should be a conscious one.
Checking It Stuck
A week later, three checks tell you everything without asking anybody a question.
Are piece counts spread through the shift or bunched at the end? Bunched means tap-as-you-go did not take.
Do pauses show varied reasons, or does one category dominate implausibly? A floor tapping the nearest tile produces a Pareto chart that points at nothing.
Are setup phase durations plausible, or are six phases suspiciously identical? Identical phases mean the ribbon was advanced in one burst.
Each of those is a coaching conversation with a specific operator about a specific habit, which is a far easier conversation than a general one about compliance. And each is visible in the punch history without anybody being watched in person.
The takeaway
Train the loop first, name the fear in the first five minutes, and spend the rest of the effort on three habits: count as you go, pick the honest pause reason, and tap all six setup phases. Make it explicit that mistakes are cheap and silence is not, then check the habits a week later in the punch data rather than in a meeting. Explore the platform at EDGEBIC, see the upgrade path in RMDB to EDGEBIC, and read on in what an operator sees at the kiosk and the daily rhythm of a kiosk-run shop.
Expert Q&A: Deep Dive
Q: Our operators are skeptical that this is not a stopwatch pointed at them. How do we handle that honestly?
A: Address it directly in the first five minutes, because it will be the real subject of the session whether you raise it or not. The honest answer has two parts. Only run and rework time counts as production hours, so setup, pauses, and downtime are recorded separately and nobody's numbers are judged on a coolant leak. And every pause carries a reason from four categories, which means lost time gets attributed to its actual cause rather than to the person standing there. Show them the handoff screen with its setup, run, and down split. Operators trust a system that separates those three far faster than one that reports a single number.
Q: How do we know a week later whether the training stuck?
A: Look at three things, none of which require asking anybody. Check whether piece counts arrive through the shift or arrive in one block at the end, because a single end-of-shift entry means tap-as-you-go did not take. Check whether pauses carry varied reasons or whether one category dominates suspiciously, since a floor tapping the first tile it sees produces a Pareto that points nowhere. And check the setup phase times for plausibility, because six identical phase durations mean somebody advanced through the ribbon in one go. Each of those is a coaching conversation, not a discipline one.
Frequently Asked Questions
Ready to Transform Your Production Scheduling?
User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.

User Solutions Team
Manufacturing Software Experts
User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.
Share this article
Related Articles
The Schedule Reconciliation Report in EDGEBIC, Explained
Eight parameter checks over two exception grids. See how EDGEBIC reconciles the plan against the plant and shows only the rows that disagree.
Why a Dependent-Parallel Child Is Exempt From the Over-Booked Check
Three synchronized drills book 24 hours on an 8 hour day. That is real plant behavior, not a capacity breach, and flagging it would make the whole check useless.
Confirming a Sub-Assembly Versus the End Product in EDGEBIC
One dialog, two mechanisms. See why confirming an end product reduces the build directly while confirming a sub-assembly works through ordinary stock netting.
