Turn In becomes available when you own the items the active request asks for. Keep them in accessible inventory rather than locked inside a crate, check the exact item type and quantity, and make sure the request timer has not ended. You do not need to put everything on the counter simply to make the button work.
The most useful first check is the request wording. Having many objects that look like medicine, food or supplies does not prove that you own the specific requested kind. Compare the exact names before buying more stock or assuming the marketplace is broken.
Read the whole active request
Open the request on the television and identify the requested item, amount and remaining time. The button belongs to that request, so a different order you could satisfy does not make this one ready.
Keep the deadline visible in your decision. A request pays when the goods arrive before its timer ends. Gathering the right stock after the request has expired is not the same as fulfilling the original order in time.
For a concrete example, Toilet Paper for Georgio asks for four Rolls of Toilet Paper, pays 200 Credits and gives seven days. That item-specific wording is more useful than counting every household object in storage.
Read the exact requested item and amount before counting stock.
Requests can also differ in purpose. Daily requests can repeat, while story requests appear once. Revolution requests can use code words explained by Mentor's Notes. Do not assume that a coded phrase is asking for the item that first comes to mind.
A grey button is therefore a signal to compare conditions rather than a reason to change random settings. Identify the first requirement you cannot confirm, then solve that requirement before checking the next one.
Match exact item kinds, not a broad category
If a request asks for three of an item, it needs the specified kind. A large collection in a related category does not necessarily satisfy it. This is why a player can see a request for something medicine-related, own many medicines, and still have no eligible turn-in.
Read the inventory tooltip and compare the name with the request. Check whether it refers to a supply item, an individual finished product, or another distinct object. Similar names and icons are a reason to inspect more carefully, not a reason to substitute them automatically.
A useful comparison order is:
- Read the exact item name on the request.
- Inspect the names of the items you believe match it.
- Count only the matching items you own.
- Check whether any matching stock is still inaccessible inside locked storage.
- Return to the active request and inspect Turn In again.
Do not spend Credits replacing an entire category of stock before doing this comparison. If the wrong item type was counted, buying more copies of that same wrong type does not help.
Keep the items owned and accessible
The delivery rule counts items you own of the requested kind. Items locked inside a crate do not count. That restriction can explain why a valuable inventory appears sufficient while the request remains unavailable.
A sealed supply crate is not equivalent to having each possible item from its contents in accessible inventory. Until it is opened and the relevant item is available, you should not count a hoped-for crate result as ready stock.
| Inventory situation | What to check |
|---|---|
| Correct item loose in owned inventory | Count it toward the active request |
| Similar item with a different name | Do not assume it qualifies |
| Possible item in a sealed crate | Open and inspect rather than counting an expectation |
| Required item locked inside a crate | Make it accessible before checking delivery |
| Item still offered by a customer | Complete ownership before treating it as your stock |
Items locked inside a crate do not count as accessible request stock.
The request does not require placing every matching object on the counter. Avoid emptying storage onto exposed work surfaces just because the button is grey. First solve the ownership and access conditions, which are the relevant delivery checks.
Check the quantity after separating similar items
Count the qualifying items after identifying their exact type. Do not count an unopened container as several usable items merely because its description suggests contents. Inspect what is actually available to deliver.
For stackable stock, look at the number of matching units rather than the number of inventory spaces. For distinct items, compare each name and condition as needed. The goal is to establish the quantity the request can use, not simply the number of objects that look related.
Remember any units already committed to another activity. A machine input or a sale you are about to complete can change what remains in your possession. Recheck the request after finishing those transactions rather than relying on an earlier stock count.
Do not assume you must buy extra beyond the stated amount. First determine why the visible quantity is not qualifying. The problem may be access, the wrong item kind or an expired request rather than an actual shortage.
Decode Revolution wording before substituting goods
Some Revolution requests name items in code. The Mentor's Notes explain those words. When a request uses this language, the correct next step is interpreting the code through the provided notes, not choosing an object because the phrase sounds similar.
A request can be active without being understandable from the ordinary item categories alone. Keep this separate from the locked-storage issue: one concerns knowing what is asked, while the other concerns making the correct goods available.
If you have not confirmed the code's meaning, do not buy a large speculative batch. Read the relevant note first, then inspect the resulting item match. That protects both the deadline and your cash from a guess that may not satisfy the request.
The Marketplace Requests upgrade and Revolution request access also have their own conditions. A request you can already see should be diagnosed from its wording and inventory requirements rather than from an assumption that every faction uses the same schedule.
Review the timer before committing scarce stock
Daily and story requests have time limits. A nearly expired request may still be worth completing if the correct goods are ready, but it is a poor reason to begin an uncertain multi-stage production chain without checking the remaining time.
Compare the task with the stock already available. If an ingredient needs overnight processing, consider whether the active deadline allows that stage. Do not count a future output as a current deliverable merely because the machine is configured.
Keep this page focused on the button's state: the request needs qualifying goods while it is active. A correct production plan that finishes too late does not meet the same condition.
If a request disappears, inspect the active list and timing before assuming the goods were lost. A timed order ending and an inventory problem can look similar when the only thing you notice is that the previous action is no longer available.
Inspect condition before delivery even when an item qualifies
Items of the requested kind can count in any condition, but qualification is not the same as a consequence-free delivery. A mislabeled item is still a mislabeled item, and the game can record the resulting customer discovery in the night log.
A qualifying item can still cause consequences if mislabeled.
If the item's condition is worse than its label claims, delivery can cause reputation loss and count as Fraud. A bad injector or toxic product can instead create Endangerment. Black Market and Revolution requesters do not report those offenses, but that does not change the actual goods you handed over.
Stolen items delivered through requests count as fencing. The marketplace is therefore not a universal way to erase stolen status or sell every risky object without consequences. Read the item's status before choosing it for delivery.
This is why forcing the button to become clickable is only part of the task. The useful outcome is completing the request with goods you intentionally chose, while understanding their labels and status.
Keep the reward separate from the eligibility check
Requests pay Credits and can also change reputation. Different request types have different rewards and timers, so use the active request's displayed terms when deciding whether to fulfill it.
A high payment does not make a wrong item count, and a desired reputation gain does not remove a deadline. Verify eligibility first, then compare the reward with the stock you will give up.
For example, an ordinary request that uses items you already own can be straightforward. A request that would consume the last ingredient in a production line needs another decision. The button does not make that business choice for you; it only tells you whether the turn-in conditions are currently met.
Avoid inventing a fixed profit for fulfilling a category of requests. Your purchase cost, the condition of the goods and the actual offer determine what the transaction contributes to the shop.
Use a short reset of the inventory assumptions
When the button stays grey, do not repeatedly move all your stock between the counter and storage. Rebuild the eligibility check from the request itself: exact kind, required amount, ownership, access and timer.
If you find the correct items inside locked storage, make those items accessible. If the names do not match, obtain the right kind. If the quantity is short, add only the missing amount. If the deadline has ended, a previous request cannot be completed by continuing to rearrange the same goods.
When all visible conditions appear satisfied, keep the active request and candidate items identifiable so you can compare them directly. Do not explain the mismatch with an invented hidden prerequisite. A factual item-by-item comparison is more useful than a guess about what the game might want.
The supported workflow is to read the active request, own the named goods, keep them accessible, and deliver before the timer ends. Once Turn In is available, check condition and stolen status before pressing it. That completes the request deliberately instead of treating the marketplace as a place where every item in a broad category should automatically qualify.