Find the first handoff that is waiting
Watch one complete run from crop to customer before opening an upgrade menu. Name the first stage that prevents the next one from doing useful work: a crop waiting to be collected, ingredients unable to reach the kitchen, ingredients waiting to become dishes, or finished dishes waiting for service. That stage is the current S priority.
Do not assign S to every category at once. A faster harvest cannot improve a full buffer, and a faster clerk cannot sell a dish that the kitchen has not made. Clearing one queue is useful precisely because it exposes the next constraint.
Match the visible signal to one upgrade category
What to watch: You leave the kitchen or counter to collect ready crops, or a known dish cannot start because its ingredient is not arriving.
What to test: Test the harvest worker or the part of its route that is visibly idle. Do not add more harvest capacity when a full store already waits for cooking.
Move on when: Ingredients arrive often enough that the kitchen, rather than collection, becomes the next visible wait.
What to watch: Harvested ingredients wait with nowhere useful to go, or the kitchen repeatedly runs dry while stock is stranded elsewhere.
What to test: Check the handoff before buying more workers: create enough usable buffer for the current loop, then watch whether the kitchen receives it.
Move on when: A short reserve survives a normal cycle without hiding a larger cooking or service delay.
What to watch: Ingredients are ready but dishes appear slowly, or the kitchen has constant work while other stages wait.
What to test: Test a cooking worker, speed, or capacity only while the kitchen stays busy. Keep one repeatable dish running so recipe experiments do not distort the comparison.
Move on when: Dishes leave the kitchen steadily; if they begin waiting finished, move attention to service.
What to watch: Completed dishes wait at the table or counter while customers remain unserved.
What to test: Test service capacity or its route after confirming dishes are actually reaching the handoff. A service change cannot fix an empty kitchen.
Move on when: Finished dishes clear without a growing queue; a new wait upstream identifies the next priority.
What to watch: The stable line is moving, and the current goal is a new ingredient, recipe, plot, or mutation rather than clearing a wait.
What to test: Reserve a separate input or plot for the test. Change one variable and retain the stable line as a baseline.
Move on when: You learn from the test without stopping the restaurant that funds the next attempt.
Use S, A, and B as a decision filter
S: the line cannot complete normal cycles
Choose S when the same visible wait directly stops dishes from reaching customers or prevents the restaurant from earning through its normal loop. Spend or test only the category tied to that wait, then observe again before taking a second upgrade.
A: the queue returns after the first fix
Choose A when the initial bottleneck is no longer permanent but repeatedly becomes the limiting stage across several normal cycles. It is a candidate for a measured capacity increase, not proof that an item has a universal rank.
B: improve convenience without hiding the constraint
Choose B for extra room, a smoother route, a new plot, or a discovery test once the normal line stays stable. B work is valuable, but it should not consume the materials or attention needed to repair an active S queue.
Run one controlled upgrade test
- Keep one known dish and its normal input route running as a baseline.
- Change one worker, capacity, speed, buffer, or route decision that corresponds to the observed queue.
- Watch several complete cycles and record whether the original wait shrank, moved, or did not change.
- Stop investing in that category when another stage becomes the first visible wait.
This method keeps a temporary improvement from looking permanent. It also protects recipe and mutation experiments: a new ingredient result is not evidence that a harvest, cooking, or service upgrade solved the production line.
What this page does not claim
Public sources support the broad loop of harvesting, cooking, serving, drones, and restaurant growth. Community runs make the queue-based method useful to apply, but they do not establish fixed costs, breakpoints, formulas, item effects, or a universal purchase order. Those values remain Needs verification unless a source supports them.
For role-specific choices, use the drone upgrades guide. For a wider session plan that includes recipes and experiments, use the progression guide. The Restaurant Profit Planner accepts your own observed values when you want to compare a line without inventing game data.
Does this list rank specific items?
No. It ranks observable behaviors only, so it does not claim a universal item, cost, or official upgrade sequence.
How should I choose between two upgrades?
Watch several complete cycles. Buy or test the option attached to the stage that stays busy while the next stage waits. Keep the rest of the line stable so the result has a clear cause.
When does an S priority become A or B?
Move it down when its visible queue no longer prevents normal cycles. It remains A when the wait returns repeatedly, and becomes B when it is only a convenience or expansion choice.
Can exploration ever be S tier?
Only when a repeated, visible production constraint makes that exploration the direct next test. Without that evidence, protect the working line and treat exploration as B.