Goods-to-person (G2P) workstation design is often reduced to a simple arithmetic question: how many orders can one operator pick per hour? In practice, a workstation is a small dynamic system in which robot delivery logic, tote buffering, operator movement, scanner confirmation, exception handling, and downstream packing interact continuously. Capacity planning and bottleneck analysis are therefore exercises in observing the whole flow, not just the operator’s hands. This article explains how to define workstation capacity in a defensible way, how to collect evidence when throughput falls short, and how to avoid the common misinterpretations that lead to unnecessary equipment purchases or unrealistic performance targets.
Operating Context of a Goods-to-Person Workstation #
A G2P workstation sits between automated storage and manual order consolidation. Typically, an automated system delivers a tote or tray containing one or several stock-keeping units (SKUs) to a fixed position in front of an operator. The operator removes the required quantity, places it into an order container or onto a takeaway conveyor, confirms the pick, and then releases the tote. The tote returns to storage or moves to a replenishment area. Some workstations are designed for single-line picking, where each tote represents one order line; others use multi-line picking, where the operator scans an order and then picks from multiple presented totes before releasing them.
The workstation is not an isolated island. Its performance is constrained by upstream delivery frequency, downstream packing or induction capacity, software order-release logic, and the physical layout of the conveyor or robotic interface. A workstation capacity plan that ignores these boundaries will produce a number that is neither achievable nor useful for system design.
Component Interactions That Define Capacity #
To analyse capacity, the planner must first identify the interacting components and the direction of influence between them. The main components are:
- Storage and retrieval system: delivers totes to the workstation buffer and removes completed totes. Its transaction time directly determines how quickly the next tote can be presented.
- Workstation buffer: a queue of totes waiting to be processed. Buffer depth absorbs variability in delivery and operator pace, but excessive depth can mask upstream delays and inflate apparent workstation utilisation.
- Operator: performs picking, confirmation scanning, exception handling, packing into shipment cartons, and housekeeping tasks. Operator time is a finite resource and the most variable component.
- Order container: carton, tote, or polybag that accumulates picked items. Container capacity and changeover frequency affect how often the operator must pause picking.
- Downstream induction: a conveyor, chute, or robotic arm that receives completed orders. If this component stalls, workstations upstream will back up even when the operator is fast.
- Control software: decides which totes to deliver, when to release them, and how to sequence work. Software logic can create artificial bottlenecks if it prioritises order completion over workstation balance.
Capacity planning must treat these components as a connected network. For example, a workstation with a two-tote buffer can tolerate brief delivery delays without losing operator pace, but a workstation with a single-tote buffer will starve whenever the retrieval system is busy elsewhere. Conversely, adding buffer capacity without improving retrieval speed only moves the waiting time from the workstation to the storage system’s queue.
Capacity Planning Fundamentals #
Capacity is not a single number. It is a relationship between throughput, utilisation, and time. In G2P workstation planning, the fundamental equation is:
Effective workstation throughput = operator pick rate x operator productive time × (1 – loss factor)
Where the loss factor includes waiting for totes, waiting for order containers, exception handling, ergonomic pauses, and system faults. The planner should define throughput in a consistent unit—picks per hour, lines per hour, or order lines per shift—and state the assumptions about order size and SKU distribution.
Three time horizons matter. First, the design peak: the maximum sustained throughput the workstation must support for a defined period, typically 15 to 30 minutes. Second, the shift average: the throughput required over a full working shift, which includes breaks, shift start and end procedures, and fatigue effects. Third, the daily average: the throughput required to meet order volume, which may be lower than shift average if demand is seasonal or if multiple shifts operate.
A common planning error is to set workstation capacity equal to the peak 15-minute pick rate observed in a time study, then multiply by 7.5 hours to obtain a shift rate. This ignores fatigue, variability in tote arrival, and the fact that picking pace naturally slows over long periods. The safer approach is to separate the observed peak pace from a sustainable working pace and to model the difference explicitly.
Workstation Time Components #
Every G2P workstation cycle can be broken into measurable time components. The sum of these components, multiplied by the number of cycles, determines the workload. The principal components are:
- Tote delivery time: from the moment the previous tote is released until the next tote is positioned in the picking zone. This is controlled by the storage and retrieval system and the buffer design.
- Scan and identification time: the operator scans the tote label, order label, or both. Some systems use automatic barcode scanning, which shifts this time from the operator to the controls system.
- Reach and pick time: the physical motion to remove the required quantity from the tote and place it into the order container. This varies with SKU size, weight, quantity, and container location.
- Confirmation time: pressing a foot pedal, scanning an item, or touching a screen to confirm the pick. The confirm step is often the most overlooked time component because it appears trivial in isolation but is repeated hundreds of times per shift.
- Order container handling: time to tape a carton, apply a label, push a full container away, or retrieve an empty one. The frequency of this activity depends on container capacity and order size.
- Exception handling: time to resolve short picks, damaged items, missing labels, or system error messages. Exceptions are unpredictable and typically consume 5% to 15% of operator time in real operations.
- Tote release time: the operator signals completion and the tote is taken away. If the operator must physically push the tote or wait for conveyor acknowledgement, this time is significant.
When analysing bottleneck causes, the planner should break the observed cycle into these components and measure each one separately. A stopwatch time study of the whole cycle tells the operator’s speed but not where the time goes. A component-level study tells the planner whether the bottleneck is the operator, the retrieval system, or the order container supply.
A Practical Diagnostic Table #
The table below is a starting point for diagnosing why a G2P workstation is not achieving planned capacity. It is intentionally qualitative; every site must calibrate the thresholds from its own historical data.
| Observed Symptom | Likely Cause Area | Evidence to Collect | Initial Interpretation Direction |
|---|---|---|---|
| Operator idle, tote buffer empty | Upstream delivery starvation | Tote arrival timestamps from robotics or conveyor sensors; retrieval system queue length | Retrieval capacity or software release logic is limiting, not the operator |
| Operator idle, tote buffer full of unprocessed totes | Operator pace or order container supply | Operator cycle time components; frequency of empty order containers | Operator workload or container supply is the constraint |
| Conveyor downstream blocked | Downstream packing or induction jam | Conveyor status logs; packing station throughput; fault codes | Workstation is not the bottleneck; downstream is throttling flow |
| Long confirmation time relative to pick time | Control software or scanner configuration | Confirm scan interval; software response time logs; scanner position | A controls or ergonomics issue can be solved without adding capacity |
| Frequent short picks or mispicks | SKU presentation or labelling quality | Exception records; photos of tote presentation; bar code read rates | Process quality, not workstation speed, is degrading throughput |
| Periodic 5–10 minute gaps every hour | Shift routines, breaks, or scheduled system cycles | Operator activity log; system downtime records | Planned pauses may be appropriate but should be modelled as losses |
| Throughput high for 20 minutes, then sharply lower | Ergonomic fatigue or container changeover clustering | Minute-by-minute throughput trace; container fill level per order | Sustainable pace is lower than morning peak; replan with a realistic loss factor |
Use the table as a triage tool, not as a final diagnosis. The evidence collected in the “Evidence to Collect” column is the starting point for a proper data-gathering session. In all cases, site procedures, lockout requirements, OEM documentation, and competent engineering judgment take priority over any suggested diagnostic step.
Bottleneck Analysis Method #
A structured bottleneck analysis for a G2P workstation follows five steps. The goal is to identify the single constraint that limits throughput, then quantify the impact of relieving it.
Step 1: Define the boundary and the unit of work. State whether the analysis covers one workstation, a zone of four workstations, or an entire picking module. Define the unit of work as order lines, physical picks, or items, and be consistent throughout the analysis. Physical picks are usually preferred because they correspond to operator motion, but order lines are more relevant when software release logic is under investigation.
Step 2: Collect time-stamped data over a representative period. At minimum, record the arrival time of each tote at the buffer, the start and end time of each operator cycle, the release time of each tote, and the departure time of each completed order container. Modern controls systems log most of these events automatically. If logs are unavailable, a manual time study with a stopwatch and a written form can substitute for one shift, but the results should be treated as a sample, not as a stable measurement.
Step 3: Calculate utilisation and waiting time. Operator utilisation is the fraction of available time spent on active picking and directly related activities. A utilisation above 90% indicates the operator is the constraint. Waiting time is the fraction of time the operator is idle because no tote is present, no order container is available, or the conveyor is blocked. Waiting time above 10% of the shift suggests an upstream or downstream constraint. Tote buffer occupancy should be measured separately: a continuously empty buffer means starvation, while a continuously full buffer means the retrieval system is producing faster than the operator can consume.
Step 4: Construct a simple capacity model. Build a spreadsheet or a mental model with the average cycle time per pick and the loss factors observed in the data. For example, if the average observed pick cycle is 12 seconds and the operator loses 10% of the shift to waiting and 5% to exceptions, the sustainable throughput is approximately 3,600 seconds per hour divided by 12 seconds, multiplied by 0.85, giving roughly 255 picks per hour. Comparing this to the design target shows the size of the gap and whether the gap is within the range that can be closed by operational changes.
Step 5: Change one variable at a time. The most rigorous way to confirm a bottleneck is to simulate or pilot a single change. If the hypothesis is that retrieval speed is the constraint, increase the buffer depth or change the software release rule and observe whether operator waiting time falls. If waiting time does not fall, the hypothesis is wrong. If waiting time falls but total throughput does not rise, the next constraint downstream is now exposed. Repeating this one-change-at-a-time method avoids the common mistake of changing multiple parameters simultaneously and then crediting the wrong fix.
Common Interpretation Errors #
Several recurring errors undermine workstation capacity analysis. The first is averaging across heterogeneous tasks. If a workstation handles both single-item eaches and multi-item variable quantity picks, the average cycle time is nearly meaningless. The planner must segment the data by task type before drawing conclusions. A 20-second average may hide a situation where 80% of picks take 10 seconds and 20% take 60 seconds, which has completely different bottleneck implications than a uniform 20-second cycle.
The second error is confusing operator speed with system capacity. A fast operator can make a poorly configured retrieval system look adequate because the buffer masks upstream delays. When the operator slows down or takes a break, the buffer fills and the retrieval system’s limitations become visible. The analysis should therefore be performed during both peak and average demand periods.
The third error is ignoring the order container side. Many G2P systems have ample tote delivery but a poorly designed carton supply: the operator must walk several steps to fetch an empty carton, or the takeaway conveyor is too short and forces frequent pushing. These delays are attributed to workstation design when they are actually material handling design problems. The time-motion study will reveal them if the planner records the operator’s full motion, not just the picking motion.
The fourth error is treating exceptions as random noise. In a well-run G2P workstation, exceptions are information about upstream process quality. A high rate of short picks suggests that inventory records in the warehouse management system are inaccurate, which no amount of workstation automation will solve. The planner should track exception types and root causes, not just the total time lost.
The fifth error is using the theoretical cycle time from a controls specification as the planning baseline. The theoretical tote delivery time, which assumes the retrieval system is always ready and never waits for conveyor clearance, is almost always shorter than the real observed time. The planner should base the model on the 85th or 90th percentile of observed delivery time, not the minimum, because the workstation must operate through variability, not at the theoretical ideal.
Maintenance Implications #
Workstation capacity is directly affected by the condition of mechanical and electrical components. A conveyor that accumulates dust on photoeyes will generate false blockages, which the controls system interprets as a downstream jam. The workstation operator then waits while the software attempts to clear a non-existent jam. Similarly, a barcode scanner with a scratched window or misaligned illumination will produce read failures that force manual entry, adding several seconds to every affected cycle. These failures are often intermittent and therefore difficult to attribute to capacity loss, but their cumulative impact is real.
Regular preventive maintenance should include verification of scanner read rates, photoeye cleanliness, conveyor belt tension, tote positioning accuracy, and the condition of ergonomic equipment such as lift tables or foot pedals. The maintenance plan should also include a periodic functional test of the workstation’s safety systems, including light curtains, emergency stops, and interlocked guards. Site procedures, lockout requirements, OEM documentation, and competent engineering judgment take priority in all maintenance activities.
From a maintenance perspective, the planner should establish a baseline of normal cycle times and compare them after any maintenance intervention. If a workstation’s average cycle time degrades by more than a defined threshold, this is an early indicator of component wear long before the operator reports a problem. The controls system can often provide the necessary data automatically through timestamped events, avoiding the need for manual observation.
Decision Boundaries #
Capacity analysis produces a recommendation, and the recommendation must respect the boundaries of what the data supports. A bottleneck analysis that shows the operator has 15% idle time does not automatically justify adding a second workstation. The correct decision depends on whether the idle time is caused by tote starvation, which a second workstation would worsen, or by order container supply, which might be fixed by reorganising the carton area. Adding capacity to a workstation that is already constrained by upstream delivery simply moves the queue, not the throughput.
A second decision boundary is the difference between a capacity improvement and a quality improvement. If the bottleneck is caused by mispicking and short picks, the remedy is inventory accuracy and SKU presentation, not a faster scanner or a second operator. The planner should therefore classify each observed loss into one of three categories: controllable within the workstation, controllable only upstream, and controllable only downstream. Workstation layout changes affect only the first category.
A third boundary is the time horizon. Some improvements, such as rebalancing the order release logic or repositioning the scanner, can be implemented in days. Others, such as installing a second conveyor lane or expanding the tote buffer, require capital expenditure and downtime. The planner must state the expected throughput gain for each option and the confidence level in the estimate. If the data set is small or the operation has not reached steady state, the recommendation should be to collect more data rather than to make a significant investment.
Finally, the planner must recognise when workstation analysis is no longer the appropriate tool. If multiple workstations in the same zone show identical bottleneck patterns, the constraint is almost certainly systemic, such as an undersized retrieval system or a software order release rule. The corrective action belongs to the system level, not the workstation level. In that situation, the capacity plan should shift from workstation-centric analysis to a system-wide flow model, and the work of diagnosing individual station issues should be suspended until the systemic constraint is relieved.
Key Takeaways #
- Define workstation capacity as a sustainable rate over a defined time horizon, not as the peak pick rate observed in a short trial.
- Decompose the operator cycle into delivery, scan, reach, pick, confirm, container handling, exception, and release components; measure each separately.
- Use time-stamped system logs and buffer occupancy data to distinguish operator-limited from retrieval-limited or downstream-limited performance.
- Apply the one-variable-at-a-time method when testing bottleneck hypotheses; a full buffer does not prove the retrieval system is performing well.
- Segment analysis by task type and SKU characteristics; averages conceal the variability that causes real bottlenecks.
- Treat maintenance as a contributor to capacity: scanner read rates, photoeye cleanliness, conveyor condition, and ergonomic equipment directly affect cycle time.
- Respect decision boundaries: adding workstation capacity is wasteful when the true constraint is upstream delivery, downstream induction, or inventory accuracy.
- Always defer to site procedures, lockout requirements, OEM documentation, and competent engineering judgment before making any operational or maintenance change.
