Capacity-based production scheduling loads work against the hours each resource can actually deliver, demonstrated capacity, instead of assuming machines are infinite. When a week's load exceeds real capacity, the schedule moves work, adds hours, or renegotiates dates before release, not after the floor discovers the overload.

Most late orders were late the moment they were scheduled. Somebody loaded 130 hours of work into a 100-hour week, the system accepted it because its logic never checked, and the floor spent Friday choosing which promises to break. Capacity-based scheduling exists to catch that overload on the screen, where it is cheap to fix. This guide covers the difference between infinite and finite loading, which capacity number to trust, how the capacity checks stack across planning levels, and why scheduling to 100% is a trap. It builds on our capacity planning overview.

What is capacity-based scheduling?

Capacity-based scheduling is finite loading: work is placed into time buckets only until a resource's available hours run out, and the remainder is scheduled earlier, later, or elsewhere. The alternative, infinite loading, backschedules every order from its due date and stacks the resulting load on resources with no limit check, which is how classic MRP behaves. Infinite loading is not useless, it shows you where the load wants to be, but it routinely produces weeks where a work center is loaded at 140% and nobody decided that. Finite loading forces the decision. The mechanics and trade-offs of the two approaches are covered in finite vs infinite scheduling, and the algorithmic side in finite-capacity scheduling.

Infinite vs finite loading of the same workSame work, two loading rulesINFINITE LOADINGcapacity 100hw1w2w3w4rust = overload nobody approvedFINITE LOADINGw1w2w3w4load moved before release, not after failure
Infinite loading reveals where load wants to land; finite loading decides where it actually lands, while the decision is still cheap.

What capacity number should you schedule to?

Schedule to demonstrated capacity: what the resource has actually produced per period, averaged over recent history, with its real mix of downtime, changeovers, and losses. Every plant has three capacity numbers, and they can be dramatically far apart. Nameplate is what the equipment vendor promised. Effective capacity subtracts planned deductions like maintenance windows, breaks, and scheduled changeovers. Demonstrated is what the resource has actually delivered, which also absorbs the unplanned losses: breakdowns, short stops, slow running, scrap. Scheduling to nameplate is the single most common way plants manufacture their own lateness; the gap between the numbers is examined in nameplate capacity vs actual output, and tracking capacity utilization against the demonstrated figure keeps the schedule honest over time.

From nameplate to demonstrated capacityThe capacity waterfallnameplate 120hmaint + breakschangeoversunplanned lossesdemonstrated78hschedule to this
Each deduction is real. A schedule built on 120 hours that the resource has never delivered is late before it is published.

How do capacity checks stack across planning levels?

Each planning layer gets its own capacity check, coarser at the top, finer at the bottom. At the master schedule level, rough-cut capacity planning converts the draft MPS into hours on a handful of critical resources and catches gross overloads week by week; the grid it feeds is described in our MPS explainer. At the MRP level, capacity requirements planning computes load per work center per period from planned and released orders. At execution level, finite scheduling sequences jobs hour by hour against each resource's calendar. The layers are not redundant: RCCP prevents publishing an impossible month, CRP reveals which work centers carry the strain, and finite sequencing decides what runs at 6:00 tomorrow. Plants that skip the upper checks end up using the finite scheduler to discover overloads that should have been caught weeks earlier, when moving demand was still an option.

How do you build a capacity-based schedule?

A practical sequence for one planning cycle:

  1. Establish demonstrated capacity per resource. Recent actual output per period, by work center or line, from real records rather than standards nobody has audited.
  2. Find the constraint. One or two resources will run out of hours first; they set plant output, so identify them before loading anything.
  3. Load the constraint first. Fill its buckets to demonstrated capacity with the highest-priority work, then schedule the non-constraints to serve it, the logic of bottleneck scheduling.
  4. Level what can be leveled. Smooth the remaining load across buckets so no week starts overloaded, borrowing from load leveling practice.
  5. Resolve the overflow explicitly. Work that does not fit gets moved, subcontracted, staffed with overtime, or renegotiated, a named decision with an owner, not a silent overload.
  6. Publish and re-check with actuals. Compare produced hours to planned hours each week and feed the gap back into the demonstrated numbers.

Our free production schedule builder is a straightforward way to run steps three through five for a small number of lines before investing in scheduling software.

What do you do when demand exceeds capacity?

When the load genuinely will not fit, capacity-based scheduling forces one of four choices, and the value of the method is that the choice gets made by a person, early, instead of by the floor, late. The options, roughly in order of preference:

Move demand in time. Pull forward work from a slack week or push out orders with date flexibility, spending inventory or lead time instead of overtime. This is the cheapest lever when shelf life and customer dates allow it. Add short-term capacity. Overtime, an extra shift, a weekend crew, or routing work to a slower alternate machine. It costs money but keeps promises. Offload. Subcontract operations or move volume to a sister plant, which takes longer to arrange and adds logistics, so it works best for known peaks rather than surprises. Renegotiate the promise. Call the customer before the date fails, offer a split shipment or a new date, and protect the relationship with honesty rather than silence.

The wrong answer is the common one: accept the load, publish the schedule, and let expediting sort out which orders actually ship. That converts a planning decision into a nightly firefight and teaches sales that dates are fiction. A plant that resolves overloads explicitly, week after week, also builds the record that justifies the fifth option: permanent capacity investment, argued with data instead of anecdotes.

Does capacity-based scheduling apply to people as well as machines?

Yes, and in many plants labor, not equipment, is the binding constraint. A line with three certified operators is a three-operator resource no matter what the machinery could do, and a schedule that checks machine hours while assuming people are infinite fails exactly the way infinite loading fails on machines. Capacity-based scheduling treats staffed positions, skills, and certifications as finite calendars: available crew hours per shift, netted for absence, training, and the qualification matrix. The practical test is simple: if a call-out on Monday can invalidate the week's plan, labor belongs in the capacity model. This is also where scheduling meets workforce development, because cross-training is capacity expansion that costs less than machinery, widening the pool of people who can staff the constraint adds real schedulable hours.

Why not schedule to 100% of capacity?

Because queue time explodes as utilization approaches 100%. This is queueing mathematics, not opinion: when arrivals and process times vary, and they always do, waiting time grows nonlinearly with utilization, so a resource planned at 98% develops queues and lead times many times longer than one planned at 85%. The relationship is formalized in results like Kingman's formula, and every scheduler has lived it: the fully loaded week that one hiccup turns into a two-week recovery. Deliberate headroom is not waste, it is the shock absorber that keeps the whole schedule feasible when reality varies. How much headroom depends on variability: stable, repetitive lines can plan tighter; job shops with high mix need more slack. The demand-side lever matters too, and capacity vs demand planning covers how to keep the two matched over horizons longer than one schedule cycle.

What do the data say?

Useful reference points:

Where Harmony AI fits

Every step above depends on one input plants rarely have: current, trustworthy demonstrated-capacity numbers. Standards get set at startup, rates drift, and the spreadsheet that holds "line 3 runs 78 hours a week" was last updated by someone who left. Harmony AI is an AI-native MES, a real-time operational layer that connects machines, planning software, and floor paperwork into one live record with no rip-and-replace, so demonstrated output, downtime, and changeover time per resource are continuously measured facts instead of annual estimates. Harmony AI's agents compare planned load to demonstrated capacity as the week unfolds and flag the overload forming on Tuesday rather than the misses reported on Friday, which is the data foundation that dynamic scheduling needs anyway. Deployment is in person and white glove: Harmony AI's engineers walk the plant, meter what each resource really delivers, and connect the systems you already run. The CLS case study shows what that looks like in a working plant.