Post-purchase upsell: the offer after the money

Every upsell before the payment competes with the purchase. A bundle module on the product page, a cross-sell in the cart drawer, an add-on step at checkout — each of them adds a decision at a moment when the buyer was already deciding something, and the honest version of the test measures whether the extra revenue exceeds the orders the distraction cost you. That test is rarely run properly, which is why upsell case studies are so much more enthusiastic than upsell data.

The post-purchase offer sidesteps the problem entirely. Shopify documents it as appearing after the order is confirmed and before the thank-you page: the money for the original basket is taken, the order exists, and the offer is a second, separate decision. Declining it costs nothing. Accepting it charges the card already on file rather than sending the buyer back through checkout, which is the reason take-up on these is higher than on an equivalent offer sent by email an hour later.

That is a genuinely good mechanism, and it is worth saying plainly because the rest of this post is about why it might still not be worth building on your store.

This takes an afternoon with an order export and it is the difference between a sound decision and an app subscription.

Take ninety days of orders. Filter to the online store channel, then to orders with a shipping address, then to orders paid by credit card — checking your gateway against the documented exclusions rather than assuming — then to single-currency orders if you sell in several. What survives is your eligible order share. On a store where most buyers reach for a wallet or an installment provider, that number surprises people; on a store selling higher-value goods to card-paying customers it can be the large majority. Either way it is your number and nobody else's.

Then multiply: eligible orders × take rate × contribution per accepted offer. You do not have a take rate yet, and the ones quoted in app marketing are not evidence — they are unattributed, self-reported by the party selling the software, and drawn from whichever merchants make the best case. Use a range you would be comfortable defending to your finance team as pessimistic, and see whether the project still clears the cost of the app plus the build plus the operational work below. If it only works at the optimistic end of the range, it does not work.

An accepted offer changes an order that already existed. That is the part which lands outside marketing and it is where these projects actually go wrong.

Your warehouse system, 3PL or ERP may already have received the original order — by webhook, by scheduled export, by integration — before the second item was added. Whether that integration handles the amended order, the additional line, and the second charge depends entirely on how it was built, and the honest way to find out is to place a test order, accept the offer, and watch what each downstream system ends up holding. Do that before launch, not during a promotion.

Then there is picking and shipping. If the accepted item ships separately you have paid for a second delivery against a margin that assumed one, and the customer receives two parcels for one order — which generates a "where is the rest of my order" contact even when both arrive. If it ships together, whoever picks has to see the change in time. Neither is difficult. Both are work that belongs in the business case rather than being discovered in week two.

The buyer has already decided, already paid, and is about to leave. You have their attention for a few seconds and no appetite for a second shopping trip. That constrains the offer more than most merchandising discussions allow.

What works is an offer with no decision in it: one product, one price, one button. The refill, the consumable, the obvious accessory, the size up on a subscription, a second unit of exactly what was just bought. Anything that requires choosing a variant, comparing options, or understanding a bundle is asking the buyer to start again, and they will not.

What does not work is anything that complicates the order they just placed. An offer that changes the delivery date, splits the shipment awkwardly, or introduces a made-to-order item with a lead time buys a small amount of revenue and a large amount of support. And a steep discount here is worth thinking about twice: the buyer has just seen your prices and paid them, so a heavy markdown thirty seconds later teaches them what to wait for next time.

The gross revenue an offer generates is not what it earned you. Some of those refills and accessories would have been bought anyway, later, at full price — that is substituted revenue, not incremental revenue, and the app dashboard cannot tell the difference. The only way to find out is to hold a share of eligible orders out of the offer and compare total spend over a following period long enough to catch the repeat purchase you may have pulled forward. Most stores will not do that. It is still the difference between a real number and a flattering one.

And if your eligible share turns out to be a minority of orders, the honest recommendation is to skip the post-purchase slot and put the effort into the first post-purchase email and the reorder reminder. Those reach every buyer regardless of payment method, currency, channel or order value, cost nothing per order, and can be built by the people you already have. That is a worse mechanism reaching a larger audience, and quite often it wins.

None of this is an argument against post-purchase offers. It is an argument for doing the eligibility sum first, because it is a twenty-minute calculation that decides a several-month project, and it is the one step every version of this discussion skips.

• Conversion rate optimisation
• Upsell and cross-sell without slowing the page
• Checkout extensions that are worth the milliseconds