Hi, I’m Mahdi. When I look at a good food-ordering or retail experience, the useful part is rarely a complicated funnel diagram. It is the moment someone says, “You may need this with the item you already chose.” A drink with lunch. Batteries with a device. A compatible accessory, rather than another random bestseller.
That is the experience we will build in WooCommerce: one optional, relevant checkout offer, with a clear price and a way to carry on without it. I will use our Lumo Smart Funnel plugin, show the real settings, and explain what needs testing before the offer reaches customers. Adding more offers is easy. Keeping the checkout dependable is the real work.
Scope: a staging-site setup using Lumo Smart Funnel 1.94.0, WordPress 7.1.4, WooCommerce 10.9.4 and PHP 8.1.10, checked on 8 November 2026. Screenshots use synthetic products. The configuration was saved in the interface, selected backend paths were tested, and the classic-checkout offer was selected and removed in a real browser. A totals mismatch is documented below. This is not a live conversion experiment or certification of every checkout, tax setup or payment gateway. LumoWP makes the plugin discussed here.
First, see what the shopper actually gets
Here is the customer-facing result from our classic-checkout lab. The shopper already has a $20 lunch bowl in the cart. The drink offer appears before the Place order button, with its own photo, a crossed-out $4 price and a $3.60 offer price. The checkbox starts empty: seeing the recommendation does not add the drink automatically.
Customer view before selection. Graphic treatment based on an actual lab screenshot; product photo and products are demo assets. The interface text and unchecked state reflect the observed output.
After I selected the checkbox, the drink appeared in the order review and the control changed to Remove this offer. Unticking it removed the drink and returned the displayed total to $20. This makes the interaction understandable: accept the extra when it helps, or carry on without it.
Selected offer in the actual lab interface, graphically framed. This shows the selection state, not a completed payment or a validated order total.
What the browser test also caught: in this 1.94.0 test, the added drink line showed $3.60 but the refreshed subtotal and total showed $24.00. With the $20 bowl and no displayed tax or shipping, the expected sum was $23.60. I reproduced this when selecting the offer again. Treat that mismatch as a launch blocker: check the displayed total, stored order and payment amount after a fix. No order or payment was submitted in this test. The screenshots demonstrate the visible interaction; they are not evidence that checkout pricing passed.
Checkout type matters: these captures use WooCommerce’s classic [woocommerce_checkout] output in the permanent lab. The order-bump placement uses the classic checkout hook. Do not assume an identical placement in the Checkout block; test your actual checkout and theme before going live.
What can we learn from Uber Eats and Walmart?
Uber Eats documents adding eligible items around an existing order. Walmart describes using recommendations to help customers discover relevant products. The transferable idea is context: suggest something connected to the purchase already in progress. Neither company’s public explanation proves that installing a WooCommerce plugin reproduces its systems or results. See Uber’s add-items explanation and Walmart’s shopping-experience overview.
For a small store, start much narrower. A shopper buying a lunch bowl may appreciate a drink. A shopper buying a laptop may need a compatible sleeve. A shopper buying a digital course probably does not need a shipping-related offer. The offer should answer a plausible next need, not simply occupy an empty part of the checkout.
| Pattern | When it appears | Example | Main question |
|---|---|---|---|
| Related products | Before or around checkout | A compatible sleeve beside a laptop | Does it fit the item already selected? |
| Order bump | Before the initial payment | An optional drink added to lunch | Is the final total clear before payment? |
| Post-purchase upsell | After the initial order | An additional relevant product | How is the extra payment authorized and recorded? |
Step 1: define one offer before opening the plugin
Our demo uses a $20 lunch bowl and a $4 sparkling drink. The offer is 10% off the drink, so its expected price is $3.60 before applicable taxes. The expected merchandise total is $23.60 if the shopper accepts, or $20 if they decline. These are arithmetic expectations for this example, not measured revenue gains.
Write down the eligibility rule as a sentence: “Show the drink offer when the cart contains the lunch bowl.” Also decide whether the offer may stack with coupons, whether more than one drink is allowed, and what happens if stock runs out. Those decisions are part of the funnel, even though they do not make an impressive screenshot.
A useful starting constraint: one offer, one clearly related product, one testable discount. Avoid a countdown unless the offer genuinely expires. Do not make an optional item look compulsory or preselect it without a clear customer choice.
Step 2: install on staging and confirm the starting checkout
Back up the staging site and make one normal test purchase using your gateway’s sandbox before installing anything. Record the checkout type: the classic WooCommerce checkout, Checkout Block, or a theme/builder replacement. A working shortcode checkout does not prove that a block-based checkout behaves identically.
Download the current package from your Lumo account. In WordPress, open Plugins → Add Plugin → Upload Plugin, choose the ZIP, install it and activate it with WooCommerce active. If your package requires a license, activate the licensed staging domain through Lumo WP → Licenses. Then open Lumo WP → Smart Funnel. The test installation used for these screenshots is an isolated local lab; it is not a customer licensing example.
The panel separates Related Products, Order Bumps, Upsells and Settings. Start in Settings. Enable the feature you are actually testing; keep unrelated offer types out of the first experiment. For example, do not introduce a related-products grid and several post-purchase offers while trying to find out whether one checkout bump helps.
Step 3: create the checkout order bump
Open Lumo WP → Smart Funnel → Order Bumps → Create. Give the funnel an internal name you will recognize later. I used “Lunch companion — drink.” Choose the drink in Product to Offer, select Percentage, and enter 10 as Discount Value. This field is the discount percentage, not the final selling price.
Actual lab settings, cropped and framed. The example is active only in the isolated lab.
| Field | Demo value | Why it matters |
|---|---|---|
| Funnel Name | Lunch companion — drink | An internal name for finding the offer later |
| Product to Offer | Demo sparkling drink | The additional product, not the trigger product |
| Discount Type / Value | Percentage / 10 | 10% off $4 gives $3.60 before tax |
| Priority | 10 | The interface states that lower numbers have higher priority |
| Headline | Add a drink to your lunch | Explains the connection to the current purchase |
| Description | An optional sparkling drink. Add it only if you want it. | Makes the choice explicit |
Leave the funnel inactive until the conditions are ready. Use plain copy. “Add a drink to your lunch” is more helpful than “Unlock the ultimate exclusive deal.” If a product has variations, shipping costs or tax implications, verify those cases separately; this walkthrough deliberately uses simple virtual demo products to isolate the basic offer logic.
Step 4: target the cart containing the correct product
In Conditions, leave Show for everyone off. Add a group, select Cart Contains Product, choose contains, and enter the trigger product’s ID. Our lunch bowl is product 3014 in the lab. Your store will have a different ID: find it in Products → All Products by hovering over the product, or inspect its edit URL.
Use your own trigger product ID. The number shown belongs only to this demonstration.
The drink is the offered product; the bowl is the product that makes the cart eligible. Mixing those up is an easy mistake. With multiple conditions, check whether the group uses AND or OR. “Contains bowl AND shipping country matches” is narrower than “Contains bowl OR shipping country matches.” Keep the first version to a single condition so you can predict every result.
Save Order Bump, reopen it and confirm the saved product, discount and condition. I verified the saved demo card changed to Active in the lab. That confirms the configuration was saved; it does not confirm every customer-facing checkout path. Next, use Preview to review the wording, and then test the actual checkout separately.
Step 5: verify the totals, not just the offer preview
Open a fresh guest session and add only the bowl. Confirm that the offer appears where expected, that declining it leaves the original basket unchanged, and that accepting adds the correct product and price. Change quantity, refresh checkout and trigger a shipping or address update. The price must remain stable through recalculation.
| Test | Expected behavior |
|---|---|
| Unrelated product in the cart | The bowl-specific offer is not applicable |
| Accept once | One intended drink line is added at the agreed price |
| Double-click / retry / refresh | No accidental extra quantity or repeated discount |
| Apply a coupon | The outcome matches your stated coupon policy |
| Remove the drink | The bowl and any ordinary drink purchase remain correct |
| Disable the offer | The disabled campaign cannot continue changing the cart |
| Out-of-stock drink | The shopper is not sold unavailable inventory |
| Mobile, guest and logged-in checkout | The choice, price and checkout button remain usable |
Why this checklist is here: our source-level review of 1.94.0 found edge cases requiring follow-up around offer eligibility, discount validation, repeated requests and coupon handling. Do not treat the screenshots or a successful happy-path test as a production sign-off. Validate the current package against these cases before enabling the campaign on a live store.
For the example, compare both the visible total and the order line after a sandbox purchase. If taxes are inclusive, shipping changes, or another pricing plugin runs, $23.60 may no longer be the final amount paid. The important thing is that WooCommerce’s calculation and the explanation shown to the shopper agree.
Step 6: use Related Products when a grid is more appropriate
An order bump is a specific offer. A related-products grid gives the shopper a small selection. In Smart Funnel → Related Products, the interface offers Smart (Auto + Manual), Manual Only and Auto Only. Manual related products are configured in the product editor’s Product Data → Smart Funnel section.
The values shown are the inspected settings, not a universal recommendation for every store.
For a new store, manual choices are a sensible starting point: you already know that a particular sleeve fits a particular laptop. Smart mode prioritizes manual selections and fills remaining positions automatically. Keep the displayed selection small, hide out-of-stock items, and test the cart-toggle behavior so shoppers can recognize items they have already selected.
The source gives “Smart” a concrete meaning. In includes/Core/SmartRelated.php, products bought in the same order receive a pair weight of 2; a relationship to an earlier product bought by the same customer receives a weight of 1. The recommendation query ranks stored scores. This is a purchase-history scoring system, not an AI model generating product advice.
Same-order product pair: +2
Cross-order customer relationship: +1
Recommendation lookup: score >= minimum, ordered by score
These are source rules in v1.94.0, not conversion statistics.
There is an important boundary in the implementation: Smart Lookback filters the earlier customer purchases considered while new relationships are recorded. The recommendation lookup itself reads accumulated pair scores without a date condition. Reducing Lookback therefore should not be presented as an instant reset of every old recommendation. Review seasonal suggestions manually and do not assume that installing the plugin automatically imports all historical orders.
Step 7: add post-purchase offers only after checking payment behavior
The Upsells tab is a separate stage. Before using it, follow the extra purchase all the way from acceptance through payment, order records, stock and refund handling. “After purchase” describes timing; “one-click charge” describes a payment capability. They are not interchangeable.
In the inspected Lumo code path, accepting a paid upsell can lead to a checkout URL for a separate payment order. The added purchase is merged into the original order after an appropriate paid status. In our isolated backend tests, an unpaid child order was not merged, a paid one was merged, and repeating the merge did not duplicate it. These are useful checks, but they do not prove authorization, 3-D Secure behavior or refunds through a live gateway.
Before enabling an upsell: test successful payment, failed payment, cancellation, a repeated callback and a refund in the exact gateway’s sandbox. Also confirm that the customer can stop without losing the original order. Keep chained offers off until the single-offer path is dependable.
Measure profit per eligible checkout—not just a larger basket
Suppose 100 eligible checkouts previously produced 60 orders at $20: $1,200 in merchandise revenue. With an offer, 55 orders at an average of $22 would produce $1,210. AOV increased by 10%, but checkout completion fell and revenue rose only slightly. Ingredient costs, discounts, payment fees and support could easily remove that difference. This is an illustrative calculation, not a result from our plugin.
Compare similar traffic and track eligible checkout sessions, completed purchases, accepted offers, refunds and contribution margin. Keep the attribution window and currency consistent. Do not credit every purchase of the offered product to the campaign; some customers would have bought it anyway. A control group gives you a better chance of separating additional sales from existing demand.
If your checkout is multilingual or multi-currency, test the offer in each supported combination. Our guide to WooCommerce currency by language explains why the displayed currency needs deliberate configuration. A funnel should never make a converted price or an optional add-on harder to understand.
A sensible first release
Start with a pair of products that genuinely belong together, a modest offer and a short test checklist. Keep the normal checkout fast and obvious. Review the current Lumo Smart Funnel product and requirements, check the installed version, and validate the release you will actually deploy. The useful lesson from large retailers is relevance—not the number of popups you can fit between the customer and their order.
Originally published on LumoWP.
Top comments (0)