Reports
Margin-aware offers versus blanket discounting
Offer logic should stay inside merchant-approved rules. This brief does not promise margin lift.
Blanket sitewide codes train shoppers to wait. They also collapse merchandising work into a single percentage that finance may not have approved SKU by SKU. Margin-aware offer logic, when a merchant enables it, is a rules problem: which items may be incentivized, under what inventory, with which stacking limits, and with whose approval.
This brief does not promise that contribution margin will rise. It does not include a case study percentage. It explains how to evaluate offer logic as a controlled capability rather than as a growth slogan.
Why fashion is sensitive to offer logic
Apparel has seasonal markdowns, size curves that do not sell evenly, and hero styles you may not want in a bundle discount. A conversation that offers 20% on everything because the shopper hesitated is not merchandising. It is an ungoverned promotion. Visual commerce makes this worse: a look that mixes a full-price dress with a clearance accessory can silently teach shoppers that everything is negotiable.
Buyers already distinguish full-price stories from markdown stories. Conversation should inherit that distinction. If it cannot, silence about discounts is more honest than an unauthorized code.
What “margin-aware” has to mean operationally
- A documented list of SKUs or collections eligible for an offer.
- Inventory conditions, if you only want to incentivize surplus.
- A prohibition on stacking with codes finance has not approved.
- Language the assistant is allowed to use, stored in knowledge, not improvised.
- An owner who can turn the rule off when a drop sells through.
If you cannot produce that list, you do not have margin-aware logic. You have a hope that the assistant will be “smart about margin.” Hope is not a control.
Governance before go-live
Keep finance in the approval chain before any live offer rule ships. If a rule cannot be explained to a controller in one paragraph, it is not ready. Read Margin-Aware Offers and keep the public product page as the capability source, not a slide from a vendor meeting.
A one-paragraph controller test
“These collections may receive an assistant-presented offer when inventory is tracked and available. These hero SKUs are excluded. Codes from email and the assistant do not stack unless finance lists the exception. The assistant will not invent a percentage.” If your paragraph needs secret SKU math that is not in the portal, the rule is not operational yet.
What the assistant must not do
It must not invent a discount because a shopper sounds hesitant. It must not promise a price that is not in the catalog or an approved offer rule. It must not describe a markdown as a limited-time event unless operations has that event on a public page or knowledge entry. It must not use competitor price-matching language you have not approved.
How this differs from blanket discounting
Blanket discounting is easy to brief (“everything 15%”). It is also easy to regret when a new-season dress hits the same code as last season’s leftover. Margin-aware logic is slower to configure and easier to defend. It requires merchandising and finance to agree which SKUs are eligible. That agreement is the product. The conversation is only the delivery surface.
- List eligible collections and explicit exclusions.
- Confirm inventory conditions, if any.
- Write allowed assistant language in merchant knowledge.
- Test on a staging theme with a full-price SKU and a surplus SKU.
- Confirm the full-price SKU does not receive the surplus offer.
If you are not using offer logic yet
This brief still applies: do not ask a shopping assistant to invent discounts. Document in knowledge that promotional codes live on the channels you actually run (email, PDP badges, checkout) and that the assistant should not improvise. Silence is a valid merchandising decision.
Failure modes
- A founder tells the assistant to “be generous” without a SKU list.
- Offer language in knowledge contradicts the live promotion calendar.
- Complete-the-look pairs a discounted accessory in a way that implies the dress is also discounted.
- An agency brief claims margin improvement this page does not state.
Conversation is the delivery surface, not the policy
Shoppers will ask whether a code applies. The assistant should only speak offer language that knowledge and rules allow. If you run email codes, document stacking. If you do not use assistant-presented offers, document that silence. Ungoverned generosity in a chat instruction will leak onto the storefront.
Complete-the-look can accidentally teach that a discounted accessory discounts the dress. Keep pairing rules and offer eligibility aligned. Inventory conditions belong in the rule if you only want to incentivize surplus. Selling an unavailable discounted size is still a trust failure.
Related: Catalog-Only Recommendations so offers still resolve to inventory you sell, Merchant Knowledge for allowed language, and Plans, Usage and Billing if someone is conflating product offer rules with WardrobeIt plan prices—those are different documents.
A staging test pair
Choose a full-price hero SKU that must not receive a surplus offer, and a surplus SKU that may. Ask the assistant in both contexts. If the hero receives the surplus language, the rule is not ready. Keep finance in the room. Product page: Margin-Aware Offers.
If you are not enabling offer logic, write knowledge that the assistant must not invent codes. Silence is a merchandising decision. Plan prices are a different document: Pricing.
Stacking and pairing
- Email codes and assistant language do not stack unless finance lists an exception.
- A discounted accessory must not imply the dress is discounted.
- Do not incentivize unavailable variants.
- Do not brief a margin forecast from this page.
Allowed language lives in Merchant Knowledge. Catalog boundary: Catalog-Only Recommendations.
