Most CNC shops build one dashboard and expect it to serve everyone. It doesn't work: an operator needs a next-action prompt in the next 10 seconds, a planner needs a 15-minute view of the whole cell, and a manager needs a 30-day trend they can defend in a budget meeting. Building the same screen for all three produces a dashboard nobody trusts — too dense for the floor, too shallow for planning, too noisy for leadership. This guide shows exactly what each role needs to see, at what refresh rate, and how to lay it out, plus the minimal technical backbone required to feed all three from one data source.
TL;DR:
Design three separate views from one data pipeline: a wallboard for managers (3–5 big numbers, 30–60 min trend), a planner view (order sequencing and buffer risk, 5–15 min aggregates), and an operator view (current job and one-tap runbooks, sub-60-second refresh).
Each role fails differently when given the wrong view: managers ignore a screen that's too granular, planners can't plan on top of raw alarms, and operators ignore anything that isn't the next 20 minutes.
Pilot one cell for 30 days: build the operator view first (it drives daily adoption), then the planner view, then the manager wallboard once both are trusted.
A single screen trying to serve a machinist, a scheduler, and a plant manager ends up serving none of them well. Each role has a different decision cycle: operators decide in seconds ("do I stop and call maintenance?"), planners decide in minutes to hours ("which job absorbs the delay?"), and managers decide in days to weeks ("do we need another shift or another machine?"). A dashboard designed around one decision cycle is noise for the other two.
Managers need a small number of numbers they can defend in a meeting, not a live feed of machine states. Limit the wallboard to 3–5 large indicators:
Shift OEE (or plant/cell OEE), with a 30–60 minute rolling trend line.
Current late orders — a short list, not a full order book.
Top blocked machines right now — a simple status grid, red/yellow/green.
Refresh cadence should sit at 30–60 minutes for the trend, not real time — a manager checking OEE every 5 minutes is optimizing the wrong loop. For a full walkthrough of translating OEE into a management-ready story, see the guide on proving OEE ROI in 90 days.
The most frequent failure on a wallboard is cramming in a dense table "just in case someone needs it." Wallboards read from roughly 10 meters away during a daily huddle — a dense table is unreadable at that distance and gets ignored within a week. If a number needs a footnote to explain it, it doesn't belong on the wallboard; it belongs in the planner view.
Planners need enough context to reassign work, not just status. The planner view should combine live machine state with order context so the core planning question is answerable at a glance: "which late job can absorb 30 more minutes?" Include:
Order sequencing — current queue per machine, with due dates and remaining quantity.
Run-time variance — actual vs. standard cycle time per job, to catch drift before it cascades into a missed date.
Finite capacity view — machine-level buffers and late-part risk, not just a single utilization percentage.
Use 5–15 minute aggregates here rather than sub-minute machine states — planners rebalance work in windows of minutes, not seconds. For a deeper reference on structuring WIP and order context for this view, see the shop-floor management and WIP tracking guide.
Planner views frequently show raw program-estimated cycle times pulled straight from CAM output, without reconciling them against measured runs. A planner who reassigns work based on an optimistic G-code estimate routinely under-schedules jobs by 10–15%. See the detailed reconciliation method in the guide to extracting accurate cycle times from CNC programs and the companion G-code cycle time workflow.
See planner-ready cycle times without spreadsheets
JITbase learns standard times automatically from your CNC programs and reconciles them against live machine data — no manual timing studies.
Operators make decisions in seconds, on the floor, often with their hands full. The operator view should be a single job card, not a dashboard:
Current job instructions and target cycle time for the part in the machine right now.
Reject reasons list — a short, tappable set of categories, not a free-text field.
One-button runbook triggers — a documented next step for the most common alert types (short stop, long stop, cycle drift), not a phone call to a supervisor for every stoppage.
Machine states, spindle on/off, and alarms should refresh in real time or within a sub-60-second window on this view — anything slower and the operator has already moved on to the next problem by the time the screen updates.
A frequent design error is shrinking the manager wallboard down to fit a tablet and calling it the operator view. The result is a screen full of numbers with no action attached. Every element on the operator screen should map to something the operator does next — if it doesn't drive an action, it belongs on a different view.
All three views should read from the same underlying pipeline — controller telemetry, barcode/RFID scans, and ERP order data routed into one system of record — rather than three separate exports that drift out of sync. Store both program-estimated and measured cycle times so each view can reconcile against the same ground truth. For the full technical breakdown of ingestion methods (machine agents, MTConnect/OPC-UA, PLC/IO taps, barcode/RFID) and ERP/MES integration patterns, see the complete guides on building a real-time shop-floor KPI dashboard and integrating shop-floor data with ERP for real-time labor tracking.
Design guidance on reducing cognitive load applies across all three views, even though the load itself differs by role: read Grafana's dashboard best practices for general layout principles, and align KPI definitions to ISO 22400 so Availability, Performance, and Quality mean the same thing on every screen.
One data source, three role-based views
JITbase connects to your CNCs and ERP once, then powers wallboard, planner, and operator screens from the same validated feed — no separate exports to keep in sync.
Build the operator view first for one pilot cell — it drives daily adoption and surfaces data-quality issues fastest.
Validate cycle times against 20 sample runs before trusting the planner view's variance numbers.
Add the planner view once operator data is stable; confirm order context maps correctly to ERP job IDs.
Add the manager wallboard last, once both other views have run cleanly for at least two weeks.
Run a 10-day validation window on all three views and adjust refresh cadence and alert thresholds based on what each role actually acts on.
For the detailed operator-adoption checklist behind step 1, see the 7-step checklist to automate operator workload tracking. For the OEE-specific version of steps 2–4, see the complete guide to OEE.
Calculate the ROI before you scale past the pilot cell
Model expected throughput and labor gains from role-based dashboards before committing budget to a shop-wide rollout.
A dashboard designed around one generic "shop floor view" ends up serving no one well. Splitting the same underlying data into a manager wallboard, a planner view, and an operator job card — each with its own refresh rate and level of detail — is what makes a production tracking system get used every day instead of ignored after the first week.
Each role has a different decision cycle. Operators act in seconds, planners in minutes to hours, and managers in days to weeks. A screen tuned for one decision cycle is either too dense or too shallow for the other two, which is why shops that deploy a single generic dashboard often see it ignored within weeks by at least one of the three groups.
Start with the operator view. It drives daily adoption on the floor and surfaces data-quality problems (missing events, mismatched job IDs) fastest, which makes the planner and manager views more trustworthy once they're built on top of validated data.
No. All three should read from a single validated data source that combines machine telemetry, barcode or RFID scans, and ERP order data. Separate exports for each view tend to drift out of sync and produce numbers that don't match between screens.
Operator views need sub-60-second or real-time refresh since machine state changes drive immediate action. Planner views work well on 5-15 minute aggregates. Manager wallboards should use 30-60 minute rolling trends rather than real-time feeds, since daily huddles and budget decisions don't need minute-level granularity.