We’re fine-tuning our volume discount logic for stores using product option apps (like custom placement fees, DTF print sizing, inside neck labels, etc.), and we’d love to get your thoughts.
Quick scenario: Imagine a base T-shirt costs $8.90, and a customer adds extra print locations (+$2.00 add-ons), bringing the subtotal for that item to $10.90.
If you offer a 10% Volume Discount, how would you prefer the app to calculate it?
Option A: Discount on Base Price Only
Discount applies to $8.90 $ => Discounted Base = $8.01 + $2.00 add-ons = $10.01 final price. (Protects margin on fixed add-on production costs).
Option B: Discount on Total Price (Base + Add-ons)
Discount applies to $10.90 => 10% off total = $9.81 final price. (Simpler for customers to understand at cart checkout).
Questions for you:
Which approach do you currently use (or prefer) for your POD setup, and why?
If you sell custom/personalized items, do add-on options usually carry tight margins that shouldn’t be discounted?
Would love to hear how you handle this in your stores!
I’d lean toward A for POD, mainly because the add-ons often aren’t really part of the “volume” economics. If the base shirt gets cheaper to produce at higher quantities, discounting that makes sense. But an extra print location, neck label, embroidery, etc. can still cost basically the same amount to produce regardless of whether the customer orders 2 or 200 pieces.
I’d probably make that distinction explicit in the pricing rather than applying one blanket percentage to the whole line item. Otherwise a customer adding several customization options can end up getting a surprisingly large discount on the part of the order where you have the least room to discount.
The only reason I’d choose B is simplicity. If customers are accustomed to seeing “10% off everything,” having certain components excluded could create confusion unless the cart makes it very obvious. For us, though, protecting the margin on the fixed-cost add-ons would matter more than making the discount calculation slightly simpler.
On a $2.00 add-on at 10%, the gap between A and B is twenty cents a unit. That adds up at volume, but it’s small enough that I’d let support load decide it rather than margin, because one “why didn’t my discount apply properly” email costs you more than a good number of those twenty cents.
The bigger thing to check first is how your add-ons actually exist in the cart, because that determines whether A is even available to you.
If the option app writes them as line item properties with a price adjustment on the same variant, there’s no separate line for a discount to skip and you can’t split it natively at all. If it adds them as their own hidden products or variants, you can, and A becomes straightforward.
Worth confirming which one you’re dealing with before designing the logic, since it may already be decided for you.
I’d choose A or B with two guardrails: protect the add-on margin, but make the customer’s final price easy to explain.
If the option app stores the add-on as a line-item property, the discount may not be separable even if the business rule says it should be. In that case, show the base price, add-on price and actual discount in the cart rather than letting a shopper discover the difference only at checkout.
Measure discount application questions, cart edits, checkout completion and contribution margin per order. A small margin gain is not a win if price ambiguity creates support load or abandoned carts.
Hi there @Nova192
For POD, I’d vote for Option A. Many add ons correspond to specific production costs, so limiting the volume discount to the base product results in more predictable margins. It also becomes simpler to manage the discount logic when certain print locations, or personalization options, cost more/less.
Having said that, Option B can also be a good choice if the add ons are primarily high margin upgrades. The trick is to be consistent and make the pricing obvious before they check out.
Spot on! You hit the nail on the head regarding the production economics here: fixed costs like embroidery or extra prints just don’t scale down in cost the way blank shirts do.
I really like your point about making that distinction explicit in the cart. If a merchant goes with Option A, keeping the breakdown super clear right in the cart drawer (so shoppers see Base Discount separate from Add-ons) seems like the best way to protect margins without leaving customers confused at checkout.
That $0.20 reality check is a solid point. It puts things in perspective when a single customer support email can easily eat up the margin saved on a small price difference.
Also, good call on the backend data structure. Whether add-ons exist as line-item properties vs. child variants completely changes what’s technically feasible without heavy scripting.
We’re actually building feature for this right now, setting Option A as the default behavior. To address the potential support and checkout friction, we’re displaying a clear visual breakdown in the cart drawer that separates base discounts from add-ons. We’re also making sure it auto-integrates with common option apps to handle those underlying cart structures seamlessly.
If anyone here has time to test the app and suggest features you’d like to see, I’d really appreciate it. I’m always happy to help optimize things for your store’s setup!
Thanks to everyone for the input here, it really helps validate the approach!
