InstacartProduct Thinking6 min read

Deciding what happens when the item is gone

A whole product built around the one thing groceries cannot promise.

The surface: The substitution path: the preference set while adding an item, the shopper's in store message, the approval prompt, and the receipt afterwards.
What the user wants: I want groceries delivered, and I do not want to be handed something I will not eat because a stranger guessed.

Preferences set at add to cart

Adding an item lets the customer choose what should happen if it is unavailable, including picking a specific replacement, allowing the shopper's best match, or refunding.

Decide in advance, not under pressure

The moment of substitution arrives while the customer is at work and the shopper is standing in an aisle, which is the worst possible time for a considered choice. Capturing the preference while they are already thinking about that item costs nothing. It converts an interruption into a rule.

Real time messaging with the shopper

When something is out of stock, the shopper can send a message and photographs of alternatives, and the customer can reply from the order screen.

Human in the loop for ambiguous cases

No preference system covers every case, and the shopper has information the app does not, because they are looking at the shelf. A direct channel resolves the exception faster than any escalation path. It also turns an anonymous fulfilment worker into a person the customer is inclined to be reasonable with.

The approval prompt

Suggested replacements arrive as a notification with an approve or refuse choice and a photograph, defaulting to the shopper's pick if the customer does not respond in time.

Defaults as decisions

Most customers will not answer in time, so the default is the real decision for the majority of substitutions. Choosing a sensible default and stating it plainly is more honest than pretending the prompt is the mechanism. The photograph exists because product names alone do not tell a shopper whether the swap is acceptable.

Price handling on swaps

Replacements are charged at the replacement item's price, and the order total is finalised after shopping rather than at checkout, with the difference reflected on the receipt.

Truthful reconciliation

A grocery total genuinely cannot be known until the basket is picked, and pretending otherwise produces a worse surprise later. Showing the adjustment against the estimate keeps the customer oriented. The trust risk here is entirely about whether the adjustment is explained, not about its size.

Learning from refusals

Rejected and accepted substitutions feed back into future suggestions for the same customer and store.

Preference elicitation through behaviour

Customers will not maintain a preferences screen, but they will react to a concrete suggestion. Treating each approval as a small piece of training turns an unavoidable annoyance into an asset. Over enough orders the prompts get rarer, which is the correct direction for this feature to move.

The receipt

The completed order lists what was substituted and what was refunded, separate from the items delivered as ordered.

Closing the loop

The customer's real question after delivery is what did not arrive as expected, and an undifferentiated item list hides that. Separating the exceptions answers the question before they have to hunt for it. It also makes it obvious when the substitution logic has done badly, which is the feedback the team needs.

Handling the failure you cannot design away

Items run out. That is the category, not a bug, so the quality of the product is decided almost entirely in this square. Preferences captured in advance cover the common case; a live channel covers the one the preference did not anticipate.

What not to copy

Item prices in the app frequently sit above the in store shelf price, and the markup is disclosed in general terms rather than per item. Combined with service fees, delivery fees and a tipping prompt, the total assembles itself across several screens, which is drip pricing.
The tipping interface defaults to a suggested amount and has been the subject of repeated criticism and litigation across delivery platforms for how tips interact with worker pay. A default tip is not a neutral piece of UI when it substitutes for wages.
Substitution defaults favour completing the order over getting it right, because a refund looks like a failed order in platform metrics. The customer's interest and the platform's metric diverge exactly at the moment the default fires.
Shoppers are timed and rated on the same flow that asks them to wait for customer replies. Designing a human in the loop step while penalising the human for the loop is a contradiction the interface hides.

The takeaway

The exception path is the product. If your category has an unavoidable failure mode, the quality of the experience is decided entirely by how gracefully you handle it.

Finished the teardown? Bank it and the day counts toward your run.

Where the principles come from

Nudge: Improving Decisions About Health, Wealth, and Happiness, Richard H. Thaler and Cass R. Sunstein
The Design of Everyday Things, Don Norman
Error Message Guidelines, Nielsen Norman Group

Written from public behaviour of the product, not from inside it. Interfaces change often, so treat the flow described here as of the time of writing and check the live product before quoting it.