Production Schedule

The core business question: given finite machines, people and hours, in what order should every operation run so that every part leaves on time?

A part takes two to three months to make, and machining is less than half of that. The rest is material, inspection, outside processing at a vendor the shop can’t see into, assembly and shipping — each with a hard must-leave-by date. One late arrival cascades through everything behind it.

What failure actually looks like

It doesn’t look like an error. A promise slips by a few days, nobody is told, and a week later a customer calls.

The legacy schedule was genuinely powerful, but only one person per shop had learned to drive it. That made the most important screen in the product a single point of failure.

When I sorted everything I’d heard, it came down to four things a schedule has to get right: what a job needs, when a machine can actually run, how work gets placed, and whether each person can see it at the level they work at. I call them Resources, Time, Method and Visibility, and I’ve organized the rest of this case study around them — every finding and every screen below belongs to exactly one.

“The schedule is a lie.”

Not one shop’s bad day — the same sentence, from different shops, in NPS comments about the module they depend on most.

The same gap, in numbers

The usage data tells the story the quotes tell.

Support tickets from the same weeks say it a third way — work orders silently missing from the schedule, maintenance utilities reporting “success” with no diagnostics. Heavy dependence, fragile trust. These are the baselines every post-beta result gets measured against.

Two numbers didn’t add up: 65.6% of accounts opened the schedule, and 7.5% of those users ever edited it. Nobody could tell me why — it could have been permissions, training, trust or the interface.

I only had budget to answer questions that would change what we built, so I kept the ones with a fork in them: two plausible answers that lead to two different products. Three passed that test.

Four sources, each covering the last one’s blind spot

Interviewing only power users would have given me a faster version of the same tool. The people who’d given up on the schedule are the ones who explain the 1.7 editors, so I paired each source with one that would catch what it missed.

Eight findings, two per failure

Each card is one thing I heard often enough to trust; the sketch under it is the shape of the answer it implies — the principle, not the feature. The four design chapters each pick up their pair.

Nobody handed me a rebuild. The brief was six feature PRDs on the existing skeleton, and nobody had asked whether the skeleton could carry them. I task-tested the legacy workflows to find out: the six would have shipped as plug-ins, with every frustration underneath them intact.

So I made the case for a different question. With the PM I ran a short prototype sprint to show how far the current model sat from what we wanted next, then brought the VP two costed paths — face-lift now and overhaul later, or foundation first. She chose foundation. Engineering re-estimated alongside us and found that replicating legacy saved nothing; its component patterns were reusable either way.

Scoping the V1

Once the scope opened, the risk flipped to doing too much. I gave every candidate one test: which pillar does this strengthen, and is that pillar ready to carry it?

I ran the sort with the PM and the roadmap owners — Usability Fixes, NextGen, Not Right Now — and eight workstreams made V1. Target-vs-actual time didn’t: it depends on Machine Monitoring, and I wasn’t going to put a dependency on the critical path.

My first deliverables weren’t screens. For a system this entangled the rules every screen hangs off are the design, so I wrote those first.

I gave the team one sentence to argue with: the schedule should express what a shop actually has, actually does and actually decides — and the interface should follow from that. The four chapters below are that sentence, one per pillar. Each runs the same way: what I heard, the model I chose, and what it produced.

Shops told me two things. They already think in departments and machine families, and most of what decides whether a job can run — people, material, outside processing — had no place on the schedule at all. One model answers both: a tree of everything the shop has, with every constraint a job needs shown on the block itself.

The resource hierarchy

One tree feeds four places: the Gantt’s left panel, capacity roll-ups, group-level assignment, and navigation across every view. The group layer is optional — SME review taught me that a six-machine shop shouldn’t have to look at structure it doesn’t need. The tree is defined here and does its real work in Visibility, where its rows become the canvas.

Everything that can stop a job, on the block

One shop sends 90% of its work out for outside processing. Another had operators who weren’t qualified for a setup. Material that hasn’t arrived stalls everyone. Legacy had no field for any of it, which is exactly why the whiteboards and spreadsheets existed. Each becomes a mark on the operation block — readiness symbols, the production-planning check, an owner — so “can this run?” is answered where the block is, not in a meeting.

People as a schedulable resource

I treated people the way the schedule already treated machines. One board where an admin sets every assignment, syncing to the Gantt and to Kanban with per-operation setup and run states — the whiteboard photo from the onsite visit, turned into a screen. The SMEs’ first reaction was that this alone would close a lot of tickets.

Availability was where schedulers spent most of their effort, and it drifted quietly; and nobody could see, let alone sell, the capacity that was open. They’re the same defect from two sides — time was declared by subtraction and never checked against anything. I made working time a positive object the solver plans against, so a start date, a finish date and an open gap all derive from the same fact.

Positive availability

A shift template states a working day. Holidays and downtime are blocks laid on top of it, not carve-outs from it. Templates apply across the shop in one pass instead of one Master Week per cell — and downtime as a block matters again in Method, where “hold this time open” finally gets an honest home.

Capacity you can see — and sell

Because availability is positive, open capacity becomes a number the system computes: hours open per machine, rolled up to group and department, and a next-available time on every row. That’s what CNC Swiss meant by selling the gap — quoting a delivery from real open machine time instead of a guess — and it’s why the capacity bars and the utilization figures can be believed: they come from the same declared time the schedule is placed against.

Op sequence was enforced by hand and concurrency was modeled wrong, and behind both sits the complaint the NPS comments make most often: the board can’t be trusted, because it’s full of decisions nobody can explain. Schedulers were doing the solver’s job by hand, and every legacy control existed to help them do it.

So I drew one line: store facts and commitments, derive everything else. A hard start date was neither — it was a stored answer, which is why it went stale.

The solver is opt-in

Legacy ran one global rule on top of per-cell settings; when they disagreed, jobs silently failed to schedule.

ProShop’s own help docs told customers to leave deburr, assembly and inspection off the schedule — a product admitting it had the wrong model. Now each cell declares whether placement is a question at all: an Optimized cell lets the solver place just-in-time; a Manual / FIFO cell is a queue the scheduler owns, and the solver never touches it.

What was retired

Freezing a job at a clock position is what fought the optimizer. Appending new work to the tail was the other change, and the trade is honest: an appended job can land past its date, and a wrong answer you can see beats a right answer you can’t.

Engineering solves sequencing with CP-SAT from Google’s OR-Tools, which set my constraint as a designer: every rule I wrote had to be something the solver could satisfy, or report as infeasible.

Concurrency, modeled truthfully

Stacked full-length blocks give every concurrent job the wrong end time, and the on-time-delivery number downstream inherits the error. The rebuild computes a block’s length phase by phase, so a bar’s width is what actually happens on the machine.

I built it as a standalone tool first — V1 round-robin, V2 per-job batch quantities after shop feedback. Getting the math right on its own is why the Gantt bars could be trusted later.

You saw one machine at a time, and there was no overview and no way down. Both are one missing idea: altitude. Everything above — the hierarchy, the availability, the placement rules — is drawn on a single decision about what a schedule looks like, then read at three zoom levels: the shop, the canvas, the block.

A canvas, not a grid

Whether the schedule is a grid of machine cards or one continuous canvas decides how every work cell is shown, so I settled it first. I rejected the card grid on evidence, not taste: finding open capacity was a scavenger hunt, and the grid is what made it one. I built the side-by-side prototype so the argument could be tried rather than described.

Altitude 1 — the shop, the view from above

Shop owners’ complaint was that every statistic lived at the deepest level. The KPI page is the missing altitude — utilization, on-time delivery, what’s at risk and where the bottleneck is — and the Kanban is the whole-shop view for people who need to see rather than edit.

Altitude 2 — the canvas, and the tree as its rows

The tree from Resources becomes the rows of the canvas. Collapse a department and you get a summary strip, so a closed row never hides that it’s busy; expand it and the machines appear on the same time axis. One rule governs the whole workspace, short enough to hold in your head: orientation left, action center, depth right, attention on top.

Altitude 3 — the block, one glance, three questions

A block has to answer three questions without being opened, and each answer has its own visual channel so two states can never contradict each other. Fill carries on-time risk. The left rail carries the scheduling rule as a position, so it survives any fill. Opacity carries readiness. And three fixed symbol slots answer can I run this?, how does it move? and whose is it? — one from each pillar.

I kept the legacy color vocabulary on purpose. Color is the schedule’s language, and the research said users love it and distrust it in equal measure; replacing it would have cost the love and kept the distrust. So color is confined to the one slot where it means something — readiness — and structure is drawn in neutral ink.

Two loops, and they catch different things. Internal domain experts attacked the model on paper before it was built; customers used the real thing while it was still being built. The useful output of a review is what it changed, so both columns are here — including the one where I was wrong.

Loop 1 — SME pilot review

January 2026, with colleagues who have run shops. The framework was the thing under review, not the screens, which is the only reason a model error could still be cheap to fix.

Loop 2 — the Client Advisory Board

A standing call where early-access features are shown on a live product instance, not a prototype. Shops react differently to software they can picture using on Monday: a click-through gets opinions, a working instance gets objections.

The same shops see the module every few weeks, so a change lands in front of the people who asked for it while their reasoning is still fresh. The interview cohort became this room — which is also why the beta pipeline was warm before beta existed.

Everything above is the foundation; this is what it was shaped to carry. The AI scheduling layer is fully designed and planned as a premium capability after GA. Rather than ship half of it, I’d rather show that the AI vision came first, and its requirements are visibly wired into the foundation.

The three levels came out of clustering the AI sprint’s raw idea list.

Four things are in the live product only because the AI layer was already on the table: Scheduling Mode, the per-cell contract for where automation may act; a solver that fires on placement and on request, never continuously; an audit trail that is both the compliance story and the training signal; and reserved slots in the block badges, side panel and attention banner. All four were cheaper to decide before the build than to retrofit after a complaint.

Beta begins September 2026. Every number here is a legacy baseline or a target — the results column stays empty until real schedulers have run real shops on it.

At beta scale, percentages are noise. With roughly eight accounts the results column will use counts and cohorts — “six of eight beta shops had three or more roles active weekly, against 1.7 editors on legacy” is honest at small n. Behavioral evidence carries the beta story: a shop retiring its whiteboard or its Excel monitor. Full metrics land at GA.