Here is the failure mode that defines a bad Black Friday on PrestaShop: it's 6 AM on the Friday, the sale was supposed to flip live at midnight, and someone is logged into the back office frantically ticking "Enabled" on forty cart rules while the first surge of traffic is already hitting. Or worse — it's the Tuesday after Cyber Monday and the prices never came back down, because reverting forty cart rules by hand is exactly the kind of job that gets forgotten. Both problems have the same root cause: discounts that depend on a human being awake and remembering. This guide is about the opposite — wiring your Black Friday promotions so they start, stack-control, and stop themselves, with nobody touching the back office during the busiest weekend of the year.
This is specifically the automation piece. The wider Black Friday operation — server load, payment-gateway fallbacks, the marketing calendar — is its own checklist, and we cover it in Black Friday preparation: the technical and marketing checklist and the dated Black Friday 2026 preparation checklist. Here we stay on the discount engine.
The two discount mechanisms PrestaShop gives you — and when each one fits
Before you automate anything, you have to know which tool you're automating. PrestaShop has two completely separate discount systems, and merchants who blur them together are the ones who end up debugging stacking disasters on the busiest day of the year.
| Catalog price rules / per-product specific prices | Cart Rules (vouchers) | |
|---|---|---|
| Where it lives | Catalog price rules generate specific-price reductions by condition (under Discounts → Catalog price rules), while a per-product specific price is set directly on the product's Prices tab | Discounts → Cart Rules (shown as Catalog/Sell → Discounts → Cart Rules, depending on version) |
| Where the customer sees it | On the product page and listings — the price is already lowered, often with a strike-through "was" price | In the cart / at checkout, after the customer qualifies or enters a code |
| Best for | "Everything in this category is 20% off" — a visible, browsable sale | "Spend €150, get 15% off", free shipping, coupon codes, gift-with-purchase |
| Conditions it supports | Date range, currency, country, customer group, quantity | Date range, minimum cart total, specific products/categories, carrier, customer, per-customer usage limits, priority |
| Automation lever | "From / To" date fields | "Valid from / to" date-time fields + priority + group |
The practical rule: use specific prices when you want the discount visible while the customer browses — the Black Friday price tag itself. Use cart rules when the discount depends on what's in the cart (a spend threshold, free shipping, a code from your email). For the full mechanics of running a sale with both, including the strike-through "original price" behaviour, see running a sale in PrestaShop: cart rules, specific prices and discount strategies. The reason this matters for Black Friday specifically is that both systems carry date fields — which means both can be set in October and left to fire on their own.
Automating the start and stop: the native date fields
Every cart rule has a Valid — From / To pair on its Information tab, with both a date and a time. Every catalog price rule and per-product specific price has the same "From / To" range. This is the single most underused feature in the PrestaShop discount engine, and it's the whole foundation of an automated Black Friday.
The workflow that removes the human from the loop:
- Build every promotion in advance, disabled or future-dated. Create your Black Friday cart rules in early November. Set "Valid from" to the exact minute the sale opens —
2026-11-27 00:00:00— and "Valid to" to the minute it closes,2026-12-01 23:59:59. A rule with a future "from" date is dormant; it simply doesn't apply until its window opens. - Let the dates do the toggling. You do not need to enable the rule at midnight. As long as "Status" is enabled and the date window has opened, PrestaShop applies it. When the "to" date passes, it stops applying — and any specific price you set with a "to" date reverts the product to its normal price automatically. No one has to remember to put prices back.
- Stage your reveal vs. your activation. The catch most merchants hit: a specific price with a future "from" date doesn't lower the price yet, but it also won't show a "Black Friday" badge early. If you want the page to announce the sale before it's live (a teaser), that's a banner job, not a price job — keep them separate.
One important honesty check on the native fields: PrestaShop's date windows are real and reliable, but the display side has a catch. A product's strike-through price and a cart rule's availability update on the next page render after the window opens — there's no push. For a sale that starts at a precise midnight, that's fine; customers arriving after 00:00 see live prices. It only bites you if you expect a page already open in a customer's browser to update itself.
Where native scheduling runs out of road
The date fields handle "turn on Friday, turn off Monday" perfectly. They start to creak the moment your Black Friday plan involves movement within the event:
- Rotating hourly deals. A different category on deal every few hours across the weekend means dozens of rules each with a two-hour window — buildable, but a spreadsheet to manage and a nightmare to audit.
- Progressive discounting. "10% on Thursday, deepening to 25% by Cyber Monday" on the same products means stacking several specific prices with adjoining date windows and praying the seams line up.
- Price restoration you can actually trust. Native "to" dates do revert specific prices — but if you built the discount as a permanent price edit (typing a new number into the product) rather than a dated specific price, nothing reverts it. That's the classic "we sold at the sale price until mid-December" leak.
- Recurring seasonal calendars. Next year you rebuild it all from scratch, because native rules don't template or repeat.
This is the exact gap our Smart Dynamic & Scheduled Discounts module exists to fill. So what does that actually do for your Black Friday? You pre-configure the entire rotation — every flash window, every progressive step, every restore time — weeks ahead, and each deal activates and deactivates at its scheduled minute on its own. Prices restore themselves the moment a window closes, which kills the "forgot to put prices back" leak outright. And because the schedule is data, not a pile of hand-edited rules, you can duplicate or adapt a saved campaign/schedule for the next season if your scheduling module supports it, instead of rebuilding everything by hand. The dedicated walk-through of this approach is in scheduled discounts: promotions that start and stop automatically; if your Black Friday plan leans on short, sharp deals specifically, the flash-sale mechanics are in flash sales in PrestaShop and our purpose-built Sales Revolution automated flash deals module.
Structuring the discounts themselves: the cart-rule patterns that work
Automation is worthless if the underlying rules are built wrong. Three structures cover the vast majority of Black Friday plans, and each maps to specific back-office settings.
Tiered "spend more, save more"
The pattern that lifts average order value without training customers to expect a flat sitewide cut. Create three cart rules:
- Spend €75+ → 10% off
- Spend €150+ → 15% off
- Spend €250+ → 20% off
Under each rule's Conditions tab set the relevant Minimum amount. Under Actions choose a Percent discount. The mechanism that makes this behave: set cart-rule priorities deliberately (in core PrestaShop, lower priority values are processed first, so test the resulting basket rather than assuming "higher number wins"), and use the cart rules' compatibility/exclusion controls so only the intended tier applies. Without that, a €260 cart can pick up all three. The cleanest way to enforce "only one of these applies" is covered in the stacking section below.
Category sale via specific prices
For "everything in Electronics is 20% off during Black Friday," a cart rule is the wrong tool — the customer wouldn't see the discount until checkout. Use a catalog price rule (Discounts → Catalog price rules) scoped to the category, with the Black Friday date range. Now every product in that category shows its reduced price and strike-through "before" price while customers browse, which is the visible-sale effect Black Friday shoppers are hunting for.
Free-shipping threshold
Free shipping is consistently one of the strongest conversion levers, and it's a cart rule with Free shipping ticked under Actions and a Minimum amount under Conditions. Surface the threshold in your theme — "Free shipping over €50" — because shoppers genuinely add items to clear it. This pairs naturally with the tiered rules above.
The part that actually loses money: stacking control
The single most expensive Black Friday mistake on PrestaShop isn't a slow server — it's discounts that combine when you didn't intend them to. A product on a category specific price (-20%), plus a tiered cart rule (-15%), plus free shipping, can quietly sell below cost. PrestaShop gives you the controls; the job is knowing which one does what.
| Control | Where | What it does |
|---|---|---|
| "Apply a discount to the cheapest product" / discount targeting | Cart rule → Actions | Scopes a percent/amount discount instead of applying it to everything |
| Exclude already-discounted products | Cart rule → Actions (when "Percent discount" is selected) | Stops a voucher from stacking on top of a specific price — the key Black Friday safety net |
| Cart-rule priority + single-use logic | Cart rule → Information (Priority) | Controls which rule wins when several qualify — essential for tiered structures |
| Total available / per user | Cart rule → Information | Caps how many times a code is used overall and per customer — stops a leaked code draining margin |
Two operational habits prevent most disasters. First, before the event, disable every non-Black-Friday cart rule — old loyalty vouchers and standing codes are exactly what stack unexpectedly. Second, in a staging copy of the store, complete a real order for each foreseeable combination: a category-sale product plus a tiered voucher plus the free-shipping threshold, and read the final line. If the number is below your floor, fix the rule, not the order.
Protecting the products that must never go on sale
Some SKUs should be invisible to your whole promotion engine: new arrivals, sub-15%-margin items, contractually price-protected brands, already-clearance stock. Doing this with native exclusion lists means editing every single cart rule and price rule to skip those products — fragile, and one missed rule sells the protected item at a loss.
This is a focused enough problem that it has its own treatment — see discount exclusion: why some products should never go on sale — and its own tool. Our Discount Exclusion Manager lets you flag protected products once and have that exclusion override every cart rule globally, instead of maintaining a blocklist inside each rule. The benefit in plain terms: you set the protection in one place, and no Black Friday promotion — present or future, yours or a colleague's — can accidentally discount those items.
Automating the announcement, not just the price
A discount that's live but invisible converts nobody. The other half of "automating promotions" is making the sale show the moment it opens — banners, badges, countdowns — without you publishing them by hand at midnight. The non-designer path to scheduled promotional banners is covered in Banner Revolution: eye-catching promotions without a designer. Keep the visual layer scheduled on the same timeline as your discount windows so the page that lowers its prices at 00:00 also dresses itself for the sale at 00:00.
Beyond percentages: bundles, gift cards and the wider calendar
Not every Black Friday lever is a discount. Two adjacent tactics automate cleanly and protect margin better than deep cuts:
- Bundles instead of markdowns. Grouping a hero product with accessories at a modest perceived saving lifts order value without torching the per-unit margin you'd lose on a 40% cut. The mechanics are in product bundling: selling more by grouping products together.
- Gift cards. For the shopper who can't decide, a digital voucher converts the sale now and brings them back in January to redeem — see gift cards for PrestaShop.
And Black Friday doesn't sit alone — it's the loudest beat in a year-round rhythm. Slotting your automation calendar against the rest of the seasons (so December and the January reset don't catch you rebuilding rules again) is the job of the seasonal sales calendar.
A build order you can actually follow
Pulling it together, here's the sequence that gets a self-running Black Friday discount engine live without a midnight scramble:
- Decide the mechanism per offer. Visible category/sitewide cut → specific price (catalog price rule). Cart-dependent offer (spend threshold, code, free shipping) → cart rule.
- Flag your protected products first, before building a single promotion, so nothing you create later can touch them.
- Build every rule with exact "from / to" date-times — future-dated, so they fire and expire on their own.
- Set stacking controls deliberately: "exclude already-discounted products" on percentage vouchers, priority on tiered rules, usage caps on codes.
- Disable all unrelated standing cart rules.
- Test every discount combination as a real staging order and read the final price.
- Schedule the visual layer — banners and badges — on the same timeline.
- For anything that moves during the event (rotations, progressive deepening, guaranteed restoration), reach for scheduled-discount automation rather than hand-managing windows.
The thread running through all of it is the same: a Black Friday promotion should not depend on you being awake. The native date fields get you most of the way — built-in, free, reliable for "open Friday, close Monday." Where your plan involves rotation, progression, guaranteed price restoration, or a calendar you'll want again next year, that's where a scheduling module earns its keep. Either way, the goal is a discount engine you configure in October and trust to run itself through the busiest 120 hours of your year — while the only thing you're doing on Black Friday morning is watching the orders arrive.
Comments
No comments yet. Be the first!
Be the first to ask a question or share useful feedback.
Leave a comment
Share a question, an installation detail, or feedback that could help another reader.