Say a competitor's site goes down on a Thursday night, mid-holiday-weekend, in the middle of their biggest push of the quarter. Social picks up the chatter within the hour. By Friday morning, the traffic dashboard tells the story: the outage is pushing shoppers toward alternatives, and you carry most of the same catalog. The opportunity lasts until their site comes back up, and nobody knows when that will be.

The promotion almost writes itself: a tiered discount on the categories that overlap most with theirs, stacked with free shipping over a threshold, live before weekend traffic peaks. Ten minutes on a whiteboard. On many platforms, though, an idea like that means filing a ticket. Whether it can go live inside a 48-hour window comes down to one question: can a merchandiser configure the tiers, the free-shipping threshold, the stacking rules, and the start and end times without a code change?

What a flash sale promotion requires

Nobody's flash sale is really "10% off everything." The ones that work have structure. At minimum:

• Tiered discounts by spend or quantity, say 15% off at $75, 20% at $150, and 25% at $250
• A free-shipping threshold
• An optional bundle or free-gift qualifier to lift average order value
• Stacking rules, so a customer cannot double-dip and a five-item order is not treated like a one-item order
• A start and end time, so the sale shuts off on its own

The worst version of a flash sale is the one still live on Monday because nobody remembered to turn it off (not to mention whether it’s turned off both online and at the in-store POS system). None of this is unusual. It's how a real promotion is put together. But at most companies, it has to be described to an engineer first. The engineer turns it into hardcoded logic. QA confirms the tiers didn't break checkout. Then it waits for a deploy slot. By the time all of that clears, the moment that made the promotion worth running has passed.

Why ticket-based workflows miss the window

Platforms built this way don't treat promotions as something a merchandiser configures. They treat them as feature requests. Each tier, stacking rule, and free-gift qualifier has to be specified in a ticket and interpreted by someone who won't be the one explaining the results on Monday. Two sprints count as a fast turnaround, which is no help when the opportunity lasts a weekend.

This isn't specific to one vendor. Most commerce platforms are built for developers to extend rather than for the merchandiser to operate directly. Read why most promotion strategies keep failing for the broader version of this argument. The narrow version is the scenario above: when the opportunity lasts 48 hours, a platform that needs a sprint cannot deliver in time.

The question worth asking about any promotion isn't only "how good is this idea" but "how fast can it go live, and will that still be inside the window that makes it worth running?" If the answer to the second question is "next sprint," the idea doesn't matter, because the moment will have passed. If the platform lets a merchandiser configure the offer directly and get it through approval the same day, the only question left is whether the idea itself is any good.

What a late promotion costs

The friction is annoying, but it isn't the expensive part. A time-boxed opportunity has a shelf life, and a promotion that ships after the moment has passed is worth close to nothing. A tiered discount configured three weeks too late doesn't get partial credit for effort. It gets measured against a flat baseline because the moment it was built for never happened while it was live.

How the same promotion gets configured directly

On Broadleaf, the same promotion is an afternoon of work. The Offer Admin ships templates for this kind of campaign: tiered percent-off by spend or quantity, a free-shipping threshold, a free-gift qualifier. Each one is a form a merchandiser fills in. Tiers, start time, and end time are fields on the same offer record, so the sale shuts itself off Monday morning without anyone having to remember it. Stacking and combinability, whether free shipping can sit on top of the tiered discount without letting someone double it up, are set as rules in the admin (see how stacking gets handled when it's built in from the start).

Not every flash sale is a percentage off a category. Broadleaf also supports quantity-limited flash sale pricing, where a sale price on a price list is capped at a starting quantity and stops applying once that quantity sells through. The merchandiser sets the starting quantity, and the available quantity draws down in real time as orders come in. That is a pricing rule rather than an offer, so it fits the case where the goal is to move a fixed amount of inventory instead of discounting a whole category.

The interface matters less than what surrounds it. The change still goes through a preview and approval step before it goes live, because nobody wants an admin tool where anyone can push a live discount to production unreviewed. The difference is that approval can happen the same afternoon, from someone on the merchandising team who understands the offer, instead of from a queue.

That is the difference between a sale that goes live Friday afternoon, while the competitor is still down, and one that clears engineering the following Thursday, days after the competitor is back up and the shoppers who would have converted that weekend have bought elsewhere.

If your team gets asked for a campaign on a Friday and you aren't sure your platform can deliver it, it's worth looking at how the Merchandising Suite handles promotion configuration. Tiers, BOGO, free gift, free shipping, and quantity-limited flash sale pricing are all configured by the merchandiser