A grocery-delivery product in the mould of Instacart wants to replace "we will message you if an item is out of stock" with "we substitute automatically and you are never charged more". The product manager calls it a copy change. What has the business bought and what has it just agreed to pay for?

What is gained

The promise removes a synchronous human step from the middle of fulfilment. Today a picker who finds an empty shelf waits for a customer reply, and that wait is dead time inside a delivery slot. Waiting for a reply while the van loads is the single most expensive minute in the operation, and every unanswered message becomes a refund, a short order, or a missed slot. Automatic substitution converts a blocking question into a decision the system can make immediately.

What is paid

The copy change is a commitment to build four things that do not exist:

• Price authority in the fulfilment path. "Never charged more" means the basket is re-priced at pick time, with a rule that the customer pays the lower of the original and the substitute. The checkout total is therefore provisional, which changes payment capture (authorise, then capture the final amount), receipts, and every downstream report that assumed the order total was final.
• A per-line ceiling and a kill switch. Without a cap, an unavailable £2 item can be substituted with a £9 one and the difference is yours. The cap is a business rule, needs an owner, and will be tuned.
• An adjustment ledger. Every substitution creates a money movement that has to reconcile with the payment processor, the retailer settlement and the accounting system. This is where the cost actually lands, and it is invisible in the product spec.
• A quality signal. Acceptance and return rates per substitution rule, or the rules degrade silently and nobody knows which category is producing complaints.

When the bill arrives

Not at launch. It arrives in the first month-end close, when the adjustment ledger and the settlement file disagree, and in the first margin review.

The margin arithmetic is worth doing before committing, with the assumptions stated. Assume a 25-line basket, 12% of lines substituted and an average substitute price 8% higher on a £4 item: that is 3 lines × £0.32 ≈ £1 per order absorbed, roughly 1% of a £100 basket and a large share of a thin grocery margin. These are illustrative assumptions and not measurements, which is the point: the promise is only affordable inside a range of substitution rate and price delta, so measure both before you print it.

How to keep the option to reverse

Ship the promise behind a per-category rule with a cap and a flag, and start with categories where substitutes are close and cheap. Keep the old ask-the-customer path warm rather than deleting it, because it is the fallback when the rule engine is wrong and the honest answer during an incident. A promise printed in the app is hard to withdraw; a rule behind it is easy to narrow.

When not to make the promise

• When the substitution rate is low. At 2% of lines, the automation saves little and the ledger costs the same to build. Ask the customer and spend the money elsewhere.
• When baskets are large and considered. A £400 monthly shop with specific brands has customers who want to be asked, and a wrong substitute costs more in trust than the delay does in logistics.
• When the real problem is upstream. If 20% of lines are unavailable because stock data is six hours stale, no promise fixes it: you are automating apologies. Fix the inventory feed first — and say so plainly, because this is the case where no architecture helps and the constraint is operational.