Worker Cooperative Fabrication Lab Utilization and Queue Planner

Introduction: why queue planning matters in a worker-run fabrication lab

A cooperative fabrication lab usually lives in the space between community service and production discipline. Members want the shop to feel generous, accessible, and educational, but the machines still obey hard limits: every laser cutter, CNC router, printer, or mill only has so many usable hours in a week. When demand quietly rises, the first warning sign is often not a spreadsheet. It is a longer wait for members, more rushed setups, fewer maintenance windows, and operators who feel like every open shift is spent catching up. That is the planning problem this calculator is built to make visible.

The tool answers a practical introduction-level question before a team commits to new policies: can the lab complete its expected work inside the turnaround target it promises? Instead of treating capacity as a vague feeling, it translates your machine count, weekly open hours, typical job time, setup and cleanup effort, uptime, and trained operator pool into a set of planning metrics. Those metrics are not abstract. They connect directly to the conversations most co-ops already have: whether to extend supervised hours, whether to train more people, whether to limit intake during a rush season, and whether a grant proposal for another machine is justified.

The page is written to be transparent rather than mysterious. You can see what each input means, how the math works, and how the result should be interpreted. That transparency matters in cooperative governance. A result is much easier to trust in a member meeting when everyone can trace how it was produced, question a time assumption, and rerun the scenario with a different demand level or uptime estimate.

How the planner turns shop activity into a capacity forecast

At its core, the planner compares two weekly totals. The first is demand: how many machine-hours incoming work is likely to consume. The second is effective capacity: how many machine-hours the shop can realistically supply after uptime is applied. If demand stays comfortably below effective capacity, the lab has slack. If demand gets close to capacity, small disruptions become more important. If demand overtakes capacity, the backlog grows and the queue target becomes harder to honor.

The results section summarizes that comparison in plain language. You receive effective weekly capacity, weekly demand, utilization, an approximate queue projection, a recommended machine count to hit the queue goal, and an operator coverage message. Those outputs work together. A utilization number alone can look healthy while staffing coverage is fragile; a queue target can look achievable while uptime is unrealistically optimistic. Reading all of the outputs together gives a fuller picture of the lab's operational resilience.

• Effective weekly capacity shows how many usable machine-hours are available after downtime is recognized.
• Weekly demand converts intake volume into hours by including both fabrication time and setup or cleanup time.
• Utilization measures how much of that usable capacity is spoken for by the incoming work.
• Queue projection acts as a warning signal when utilization becomes tight and excess work has nowhere to go.
• Recommended machines and operator coverage help connect the math to actual decisions about equipment and training.

This is a planning model, not a minute-by-minute scheduling engine. It does not try to predict exactly which member's order will wait three days versus nine days. Instead, it helps you compare scenarios: a surge in jobs, a new machine purchase, a tighter queue promise, a training campaign that increases operator coverage, or a maintenance problem that lowers uptime. For a cooperative, that is usually the right level of detail for policy and budgeting.

Inputs and practical guidance for each field

Use consistent units across the form. Time inputs are in hours, demand is in jobs per week, uptime is a percentage, and the queue goal is in days. If your team thinks in minutes, convert before entering values. For example, 45 minutes becomes 0.75 hours. If your shop has several distinct machine families, it is often best to model them separately. A laser bay and a wood CNC bay may have very different demand patterns, changeover times, and staffing rules, so combining them into one average can hide a bottleneck.

Machines available (CNC, laser, etc.)

This is the number of machines that can actually serve the type of work you are modeling. Exclude units that are down, restricted, or unsuitable for the representative job mix in question.

Open hours per week

Use the hours when members can really produce work, not just when the room is unlocked. If some hours are unsupervised and machines cannot run under your safety policy, do not count them.

Average fabrication time per job

This is the machine runtime for a typical job. In a mixed shop, use an average grounded in recent records rather than a guess pulled from a single memorable project.

Average setup and cleanup per job

Include fixturing, material handling, tool changes, calibration, cleanup, and restart checks. Co-ops often underestimate this field, even though it is where congestion quietly accumulates.

Jobs requested per week

Think of this as weekly intake. If work is seasonal, run more than one scenario so the board can see both baseline and peak-month stress.

Machine uptime (%)

Uptime should reflect the share of open hours that are truly usable after planned maintenance, troubleshooting, breakdowns, and consumable replacement are considered.

Desired maximum queue length (days)

This is your service-level promise. A shorter target means less backlog is tolerated, so the planner will require more slack to stay credible.

Members cross-trained to operate machines

Count people who are genuinely qualified under your rules, not just interested. Cross-training matters because machine-hours on paper do not help if only a few members can safely run the equipment.

If you are unsure about a number, it is often better to run three versions of the plan instead of fighting over one perfect estimate. Try a conservative case, a realistic case, and a peak-demand case. That simple scenario range can reveal whether the shop is robust or whether a small shift in assumptions flips the result from comfortable to risky.

Model and formulas

The planner uses a deliberately simple time-based model. It starts by adding fabrication time and setup time to get the average time per job. Then it multiplies machines, weekly hours, and uptime to estimate usable capacity. Utilization is demand divided by capacity. The queue projection and machine recommendation then build on that comparison, with the queue goal influencing how much slack the recommendation should preserve.

In plain language, if average job time rises, demand rises. If uptime falls, effective capacity falls. If either change happens while intake stays the same, utilization moves upward. Once utilization gets high, the lab has less room for maintenance, training, rush requests, or a single difficult week. That is why the calculator also gives a recommendation for machine count rather than stopping at utilization alone.

The recommended machine count is not a magical prediction. It is a planning estimate that rounds up to whole machines after applying a slack target tied to your queue goal. A lab that promises a very short queue needs more buffer than a lab that can tolerate a longer wait. That extra slack is what makes the difference between a stable system and one that looks fine until one machine goes down.

Worked example using the default values

Suppose your co-op has 6 machines, is open 72 hours per week, and averages 3.5 hours of fabrication plus 0.8 hours of setup and cleanup per job. Intake is 38 jobs per week, uptime is 88%, the queue goal is 7 days, and 18 members are cross-trained to operate the relevant equipment.

The total time per job is 4.3 hours. Weekly demand is therefore 38 × 4.3 = 163.4 hours. Effective weekly capacity is 6 × 72 × 0.88 = 380.2 hours. Utilization comes out to roughly 43%. At that level, the lab usually has meaningful room for maintenance, collaborative learning, and unpredictable member requests without immediately threatening the turnaround promise.

Now imagine demand doubles to 76 jobs per week while all other assumptions stay the same. Demand rises to 326.8 hours and utilization climbs to about 86%. Nothing else changed. You did not lose a machine, and you did not reduce hours. Yet the operating mood of the shop becomes very different. Downtime matters more, changeovers matter more, and a missed shift matters more. That before-and-after comparison is exactly the reason to keep a simple model like this in cooperative planning.

How to interpret the results in real decisions

A low or moderate utilization result is not wasted capacity. In a member-run shop, slack is where maintenance, onboarding, experimentation, and resilience live. If the result shows 40% to 60% utilization, that can be healthy rather than inefficient, especially if the co-op values public workshops, safety mentorship, or flexible access for members with uneven schedules. The right question is not simply How full can we make the machines? The better question is What level of fullness still lets us honor our mission without creating fragile operations?

When utilization rises, there are only a few levers to pull. You can reduce time per job by improving setup procedures, templates, tooling, or batching. You can increase effective capacity by adding machines, extending open hours, or improving uptime through better maintenance. Or you can reduce intake pressure by pacing demand, changing submission rules, or setting a different service promise. The calculator helps you compare those levers on equal terms because it expresses them all in hours.

The operator coverage message deserves special attention. A shop can look fine on equipment capacity while still depending too heavily on a small trained core. If the result says coverage is just enough, that is often a sign to protect training time, update certifications, and document procedures. In a cooperative setting, resilience usually comes from spreading knowledge rather than simply running current experts harder.

Queue projection should also be read as a signal rather than a guarantee. If the projected queue exceeds your goal, the model is telling you that average demand is pressing above the buffer your policy allows. That does not mean every job will wait exactly that long. It means the system is vulnerable enough that delays are likely to become visible unless capacity, uptime, or intake changes.

Planning notes for cooperative governance

Numbers are most useful when they support democratic decisions rather than replace them. A utilization model gives members a common starting point for discussing priorities: whether rush mutual-aid work should be reserved capacity, whether open community days should happen in lower-demand periods, whether certain machine types deserve earmarked maintenance funds, and whether growth should come from more equipment or better training. Because the assumptions are plain, members can challenge them openly and propose alternatives without arguing about hidden formulas.

If you are building a broader operations toolkit, related calculators in this collection include the cooperative laundromat water and energy recovery calculator, the community mesh network uptime and backhaul planner, the mutual aid fund runway calculator, and the community EV carshare utilization reserve calculator. Together they frame the same cooperative challenge in different domains: matching shared infrastructure to real demand without overpromising service.

Limitations and assumptions

This calculator intentionally simplifies reality so that the result stays interpretable. It assumes an average job size rather than a full distribution of tiny, medium, and unusually large jobs. It also treats the counted machines as interchangeable for the type of work being modeled. If only two of six machines can perform the critical work, model those two machines rather than the whole room.

Uptime is compressed into one percentage even though real downtime comes in lumpy events. A single failed spindle on the wrong week can matter more than a smooth average suggests. Operator coverage is similarly simplified into a count, even though certifications, supervision rules, material restrictions, and two-person safety procedures may change what practical coverage looks like.

None of those limitations make the tool useless. They simply define what it is for: strategic planning, budgeting, training discussions, and stress testing. If you need exact production sequencing, member-specific due dates, or machine-level dispatching, use a dedicated scheduling system. If you need a shared planning language for the board, staff, and members, this calculator is the right level of detail.