| Takeaway | Detail |
|---|---|
| First robot deployment targets the provably binding constraint among throughput, error rate, or dock dwell | Measured in units/hour, errors per 1,000 picks, and dwell minutes per trailer (thesis). |
| Run a 2-week station-by-station cycle-time and dwell audit before buying any robot | Reader rule requires a 2-week audit of every station before funding. |
| Fund the robot only for the station with the lowest effective capacity | Effective capacity = cycle time ÷ parallel units ÷ uptime (reader rule). |
| Compare bottleneck relief options including overtime, second shift, new/used machine, SMED setup reduction, and outside-shop offload | Jobs Done Labs Sheet 4 lists these options with one-time cost, ongoing cost, and throughput (grounding). |
This guide helps freight-hub operators decide whether throughput, error rate, or dock dwell should receive the first robot deployment.
It pairs a two-week station audit with capacity and relief-option checks before any purchase.

How Hub Robots Move the Constraint
A freight hub can be modeled as a multi-step line with up to eight stations, using the same structure Perimattic's free throughput calculator applies to manufacturing lines: each station gets a cycle time in seconds, a count of parallel units (human or robot), and an uptime percentage. For hub work, that means splitting receiving scan, sortation, staging, and dock load into measurable stations instead of treating the building as one average flow.
Effective station capacity equals (3,600 ÷ cycle time) × parallel units × uptime%, with uptime entered as a decimal. The station with the lowest result is the bottleneck, and it caps the hub's pallets per hour even if every other zone runs faster. Perimattic's calculator frames this directly: in a multi-step line, throughput is constrained by the slowest station.
That is how a robot moves, or fails to move, the constraint. A robot added to a station that is not the lowest-effective-capacity station does not raise the hub's throughput cap, because the slowest station still sets the pace. A robot added to the bottleneck can raise that station's effective capacity; once it does, the next-lowest station becomes the new constraint, as CliffsNotes' throughput-costing note describes when it says remedying one bottleneck leads to identifying the next.
Applied to hub zones, the same rule keeps the decision tied to measured capacity rather than to the zone that looks busiest. Receiving scan, sortation, staging, and dock load each need its own cycle time, parallel-unit count, and uptime; the lowest effective capacity among them is the station whose relief can change hub throughput. If dock load is lowest, robots there are the capacity play; if receiving scan is lowest, robots at dock load leave the cap unchanged.
The practical check is to calculate every station before funding and recalculate after any change. Because the bottleneck can move after relief, a robot purchase should be justified by the station's current lowest effective capacity, not by a one-time snapshot of a different zone. Perimattic's model supports up to eight stations, which is enough to keep receiving, sortation, staging, and dock load as separate measurements rather than one blended average.

The Evidence: What Sources Converge
Across independent sources, the only convergence to state here is that the constraint is defined as the slowest effective-capacity step, and no source publishes robot-specific hub benchmarks. Perimattic's throughput calculator (deep read) confirms bottleneck detection, utilization analysis, and what-if "add a machine at the bottleneck" scenarios as the standard modeling method for up to 8 stations. That structure is directly transferable to hub zones for the purpose of comparison, but the calculator itself does not provide hub robot figures, so it must be used as a method check rather than a hub price list.
That same definition is independently echoed by Bottleneckcalculators.org's AI analyst, which frames the rule as "its slowest step" deciding how fast any process runs, whether the line is described in plain English or punched in with figures. This parallel framing is important because it shows the test is not tied to one software vendor. The check for any hub operator is to force every candidate station through that same question: which step is slowest by effective capacity, not which step draws the most attention on the floor?
For comparing relief paths, Jobs Done Labs offers a Bottleneck Relief ROI Calc with a sheet layout that lists option description, one-time cost, ongoing cost, and throughput impact for choices such as overtime, second shift, new/used machine, setup reduction via SMED, or offload work to outside shop. PlanetTogether adds that improving bottleneck throughput takes realistic capacity-based plans and better sequencing, while FasterCapital and CliffsNotes describe throughput accounting's focus on the most constraining bottleneck and the need to address the next one after relief. None of these items supply robot-specific hub benchmarks, but all of them expect a side-by-side comparison of relief options against the identified bottleneck.
With that in mind, the practical discipline for 2026 is to treat the slowest effective-capacity step as the only definition that all of these sources share. Since no published source bridges that definition to robot-specific hub benchmarks, the convergence is the method, not the robot data. That method must be run first, because without it, any robot purchase risks being applied to a step that is not the one the shared modeling would point to.

Throughput vs Errors vs Dock Dwell
The three candidates are throughput in units per hour, error rate in errors per 1,000 picks, and dock dwell in minutes per trailer. Measure all three by station before choosing a robot, because the winner is not the metric with the biggest complaint volume; it is the one that is both the binding constraint and the cheapest to relieve. Keep the units consistent across the audit so a busy station is not mistaken for the constrained one.
A throughput fix wins when the audit shows one station below roughly 70 percent of the next-slowest station's capacity. In that case, a robot belongs at that bottleneck station, and its relief ROI can be compared against a second shift or SMED using a Jobs Done Labs-style option table. The ~70 percent test is a screen, not a diagnosis, so confirm the gap persists across shifts before funding.
An error fix wins when errors per 1,000 picks are high but no single station is capacity-bound. The mechanism is rework: bad picks create loops that inflate effective cycle time at several stations at once, so robotic pick and scan verification can remove hidden capacity loss even where no station looks overloaded. Count rework time separately so that hidden inflation is visible in the audit.
A dock dwell fix wins when trailer dwell minutes are high and the delay is in staging-to-dock movement rather than in processing. AMRs for staging-to-dock transfer address that handoff; if dwell is high but staging moves are already fast, the constraint is elsewhere and AMRs will not buy capacity. Measure queue time before and after the staging handoff to separate movement delay from processing delay.
| Candidate | Binding test | Cheapest relief to compare |
|---|---|---|
| Throughput | One station below about 70% of the next-slowest station's capacity | Robot at bottleneck vs second shift vs SMED |
| Error rate | High errors per 1,000 picks with no capacity-bound station | Robotic pick/scan verification vs manual rework reduction |
| Dock dwell | High minutes per trailer with slow staging-to-dock movement | AMRs for staging-to-dock transfer vs other staging changes |
Apply the winner rule in two passes: first identify the metric that is actually binding, then fund the relief option with the lowest cost among the candidates that pass. If two metrics pass, choose the cheaper relief; if none pass, repeat the audit before buying any robot, and do not fund a robot for a metric that only looks bad in one shift.

Costs and Numbers That Matter
The cost audit starts with one row per relief option—robot, second shift, setup or process reduction, and offload to a 3PL—using the same cost columns as the Jobs Done Labs Bottleneck Relief ROI Calculator: one-time cost, ongoing cost, and throughput gain. Recording all three for every option keeps a robot quote from being compared against an incomplete “do nothing” baseline. No cited source publishes robot-specific hub prices, so every cell must come from itemized vendor quotes and internal labor or 3PL rates gathered during the audit; if a value cannot be verified, mark that option unranked rather than filling it with an estimate.
Throughput gain becomes money through the Perimattic schedule inputs: hours per shift × shifts per day × operating days per month × revenue per unit. First convert “X more pallets per hour” into monthly units by multiplying the hourly gain by hours per shift, then by shifts per day, then by operating days per month; then multiply by revenue per unit to get monthly revenue potential. As a worked illustration using the article's own audit figures: if relieving the receiving bottleneck (285 units per hour) adds 15 pallets per hour, that is 15 × 8 hours × 2 shifts × 20 days = 4,800 incremental pallets per month before revenue per unit is applied. That figure is the numerator for the robot business case, while the denominator is the one-time plus ongoing cost recorded in the audit.
Vendor pricing should be treated as an input to verify, not a fact to inherit. Ask for itemized quotes that separate hardware, software, integration, training, service, and any recurring fees; confirm whether the price is list, discounted, or bundled; and record warranty and service terms beside the cost. If a vendor will not provide an itemized number, the option stays in the table but cannot be ranked.
Compare options on cost per incremental unit over one common horizon, not on sticker price. A second shift or a 3PL offload can win on that measure even when a robot looks cheaper in capital terms, because its ongoing cost and throughput gain are visible in the same columns. The audit’s job is to make that comparison explicit before any purchase order is signed.
Keep the audit tied to the measured constraint: only the station with the lowest effective capacity earns relief spending, so every throughput gain in the table should be traceable to that station’s cycle time, parallel units, and uptime.

Worked Audit, Checklist, and Limits
METHOD — illustrative figures: a hub with receiving at 12 seconds per unit on 1 dock at 95% uptime produces 285 units per hour (3,600 ÷ 12 × 1 × 0.95); sortation at 20 seconds on 2 lines at 90% produces 324 per hour (3,600 ÷ 20 × 2 × 0.90); staging at 15 seconds with 2 teams at 92% produces 442 per hour (3,600 ÷ 15 × 2 × 0.92). Sortation is not the bottleneck once parallelism is counted; receiving at 285 per hour caps the hub. Checkpoint 1: verify cycle times by stopwatch over 3 shifts. Checkpoint 2: recompute with real uptime logs. Checkpoint 3: confirm queues physically pile at the predicted station.
Copy-usable 2-week hub audit worksheet: create one row per station and record station name, zone, cycle time in seconds, parallel units, uptime percentage, effective units per hour, queue length or wait minutes, errors per 1,000 picks, dwell minutes per trailer, and owner; collect the same fields for every shift for 10 operating days, then compare the day-14 summary with the day-1 baseline before any purchase request.
| Checkpoint or edge case | What to verify | Pass/fail or response |
|---|---|---|
| Checkpoint 1 (days 1-3) | Stopwatch cycle times across 3 shifts | Use the median, not the best observed time |
| Checkpoint 2 (days 4-7) | Recompute with real uptime logs | Replace assumed uptime with logs |
| Checkpoint 3 (days 8-10) | Physical queues at predicted station | If queues disagree, trust the queues |
| Edge case: demand below capacity | Orders or trailers versus station capacity | Do not fund a throughput robot; revisit error or dwell |
| Edge case: error-driven rework | Errors per 1,000 picks and rework minutes | Fund error reduction before throughput |
| Edge case: dock dwell not cycle time | Dwell minutes per trailer by appointment | Fund yard or dock process before station automation |
| Edge case: non-interchangeable parallels | SKU or flow split by unit | Count only eligible units in capacity |
Run the audit in four short gates: days 1-3 establish stopwatch cycle times; days 4-7 replace assumed uptime with machine, labor, and dock logs; days 8-10 walk the floor to see whether queues actually pile at the station with the lowest effective capacity; days 11-14 apply the funding rule and require queue evidence plus a clean edge-case review.
Limits: the worksheet names a candidate station, not a business case. It contains no robot-specific hub benchmark, price, or payback figure, because the cited sources do not publish them; it also assumes the 2-week window is representative, so repeat it before capital approval if seasonality, promotions, or carrier mix change volume.
What to do next
| Step | Action | Why it matters |
|---|---|---|
| 1 | Run the 2-week station-by-station cycle-time and dwell audit, recording throughput in units/hour, errors per 1,000 picks, and dwell minutes per trailer for every station. | Establishes the baseline before any robot purchase. |
| 2 | Calculate effective capacity for each station as cycle time ÷ parallel units ÷ uptime, then rank stations from lowest to highest. | Identifies the numerically binding constraint. |
| 3 | Confirm the lowest-capacity station is the last point where flow queues, not merely a slow isolated station. | Prevents funding a robot for a non-binding bottleneck. |
| 4 | Compare relief options on Jobs Done Labs Sheet 4—overtime, second shift, new/used machine, SMED setup reduction, and outside-shop offload—using their one-time cost, ongoing cost, and throughput. | Tests cheaper bottleneck relief before capital spend. |
| 5 | Fund the robot only for the station that is both lowest in effective capacity and the demonstrable queue point; otherwise choose the lower-cost relief option. | Keeps first deployment tied to the provably binding constraint. |
| 6 | Re-run the same 2-week audit after the chosen change and repeat the ranking before expanding robots to another station. | Verifies the constraint moved and avoids over-deployment. |
Frequently Asked Questions
Which three metrics determine whether throughput, error rate, or dock dwell is the binding constraint?
The first robot deployment targets the provably binding constraint among throughput, error rate, or dock dwell, measured in units per hour, errors per 1,000 picks, and dwell minutes per trailer.
What audit must be completed before any robot funding is approved?
A reader rule requires a 2-week audit of every station before funding.
How is a station's effective capacity calculated?
Effective capacity equals cycle time divided by parallel units divided by uptime.
Which station should receive the funded robot?
Fund the robot only for the station with the lowest effective capacity.
What bottleneck relief options should be compared before buying a robot?
Compare bottleneck relief options including overtime, second shift, new or used machine, SMED setup reduction, and outside-shop offload.
How many stations can the freight-hub model include?
A freight hub can be modeled as a multi-step line with up to eight stations.
Quick answers
| What should determine the first robot deployment target? | The first robot deployment targets the provably binding constraint among throughput, error rate, or dock dwell. |
| What must be done before buying any robot? | A 2-week station-by-station cycle-time and dwell audit must be run before buying any robot. |
| For which station should a robot be funded? | The robot should only be funded for the station with the lowest effective capacity. |
| How is effective capacity calculated? | Effective capacity = cycle time ÷ parallel units ÷ uptime. |
| What bottleneck relief options are listed besides robots? | Jobs Done Labs Sheet 4 lists overtime, second shift, new/used machine, SMED setup reduction, and outside-shop offload as options. |