TL;DR
We gave merchants a way to accurately track inventory they physically had, but couldn't sell. In doing so, we closed a gap in Shopify's system of truth as much as we solved a merchant pain point.
When "not for sale" still needed to count.

"Change inventory back. We need Available to go negative."

Before this project, we changed a core part of inventory behavior to stop merchants from setting negative Available inventory. The assumption was that the behavior was accidental and the system needed to correct it.

We learned the opposite.

Merchants were doing it on purpose to handle a range of real business needs: damaged goods, stock held back for a drop, or extra inventory kept aside to prevent overselling.

The details varied. The need did not.

They had inventory that still existed, but wasn't for sale, and Shopify had no clean way to represent it.

Merchants were forced to hack inventory to solve a simple need.

At the time, the model only had three states: Available, Committed, and On hand.

So if inventory physically existed, but couldn't be sold, where was it supposed to go?

Hover a state to see the problem
Available
45
Available is inventory you can sell. If unsellable inventory stays here, it can still be purchased — which risks overselling.
Committed
12
Committed represents inventory already sold but not yet fulfilled. Putting unsellable inventory here breaks the meaning of the state and would require a much broader backend rework.
On hand
57
On hand reflects what physically exists. It stays true, but as the outcome of Available and Committed, it doesn't give merchants a way to track inventory that can't be sold.

Without a sensible place to put it, merchants created fake locations, used negative quantities, or tracked inventory outside Shopify altogether.

What looked like misuse was really a model gap.

Naming the space between available and sold.

Instead of modeling every possible reason inventory might be set aside, I focused on defining a single concept that could hold them all.

That concept needed to do real work. It had to make sense to merchants in the admin, but also hold up in APIs, reporting, and help content.

Unavailable ⭐
Neutral and descriptive Easy to understand at a glance Natural pairing with Available Scales well
Possibly too tied to "selling"
Reserved
Familiar industry term for inventory management
Implies inventory is tied to an order Overlaps with fulfillment concepts Doesn't work for reasons like damaged or inspection
Allocated
Suggests intentional assignment Familiar term in logistics
Implies inventory is going to a specific destination Skews toward fulfillment terminology Not as aligned to how merchants talked about the problem
Held or On hold
Neutral More natural term — not bogged down with fulfillment or order implications Scales well
Ambiguous at scale Passive and seems temporary Doesn't work for reasons like damaged
Set aside
More conversational Closely matched how merchants described the desired feature
Reads more as an action than a state Harder to translate into reporting and APIs without the "reasons"
Unsellable
Clear and explicit Easy to understand at a glance Scales well
Very transaction-forward Frames inventory by the outcome vs. the state

Unavailable emerged as the strongest option because it described a state, not an action, reason, or outcome.

By defining Unavailable as a concept, we were able to design a UI that matched how merchants already thought about their inventory and supported real workflows for power users.

Release into the wild.
85%
of merchants used Unavailable inventory within 3 months of launch
0
support requests after launch from merchants needing help understanding the concept

Merchants could move inventory cleanly between Available and Unavailable, add inventory directly into Unavailable if it arrived in an unsellable condition, and choose reasons we could track over time — to validate whether the model was comprehensive or needed to evolve.

Treating language and research as the foundation for the work made the problem legible and actionable. We could clearly defend the need, align the team around the concept, and get the roadmap revised to prioritize the feature.

Clear words didn't just explain the system. They created a better one.