Last reviewed June 2026 — checked against PrestaShop 1.7, 8 and 9. PrestaShop 9 introduces a rebuilt discount engine (Catalog, Cart, Free-Shipping and Free-Gift discount types) that ships behind a feature flag; the calendar planning in this guide applies whichever engine your store runs.
Most PrestaShop stores run two promotions a year — Black Friday and Christmas — and improvise the rest. That leaves ten months where the only "campaign" is whatever the owner remembers to set up the week before. A seasonal sales calendar fixes that: it's a single planning document that maps every promotional moment your store will run across the year, decided in advance, so each event gets a real lead time instead of a last-minute scramble. This guide is about building that calendar and wiring it into PrestaShop — the planning view that sits above the individual events, not a deep-dive into any one of them. For the mechanics of a single sale, a single flash deal, or a single Black Friday, this post links you straight to the right sibling rather than half-explaining each one here.
The "so what?" is simple. A planned calendar gives you three things you can't get by improvising: enough lead time to build email anticipation and stock inventory, an even spread of revenue peaks so you're not living off Q4 alone, and the discipline to not discount — because once a date is on the calendar with a defined mechanic, every other week is implicitly a full-price week. The store owners who quietly out-earn their competitors aren't running more sales; they're running the right sales on purpose.
Why a calendar beats running ad-hoc promotions
There are two real risks with unplanned discounting, and a calendar is the cure for both.
The first is training your customers to wait. If discounts appear randomly, regulars learn that a price tag is just an opening offer — they stall their cart until the next "20% off everything" lands. A calendar lets you concentrate genuine discounting into a few defined windows (clearance, the summer sale, Black Friday) and protect full margin the rest of the year. The flip side — which products should never carry a discount at all — is its own decision; we cover it in why some products should never go on sale, and the calendar should respect those exclusions on every date.
The second is operational. A Black Friday set up the night before is a Black Friday with no email warm-up, no stock check, no server headroom test, and a high chance of a misconfigured cart rule discounting more than you intended. Lead time is the entire point of planning. The technical and marketing prep for the year's biggest event has its own checklist — Black Friday preparation: the technical and marketing checklist — and the calendar's job is simply to make sure that prep starts in October, not in the third week of November.
The year, month by month — and where each event lives
Here's the full annual map. The point of this table is the shape of the year: where the peaks are, what kind of promotion each calls for, and which sibling guide owns the deep build. Don't try to run all of these — the next section is about choosing. Discount-type promotions are flagged, because those are the ones you want to keep rare.
| Window | Event | Promotion type that fits | Deep guide |
|---|---|---|---|
| Jan 1–15 | New Year / fresh start | Themed launch, not a discount (resolutions, not bargains) | New Year planning |
| Jan 15–31 | Winter clearance | Genuine discount — you need the warehouse space | Running a sale in PrestaShop |
| Feb 1–14 | Valentine's Day | Gift bundles + express shipping beat flat discounts | Valentine's campaigns that convert |
| Mar–Apr | Spring refresh / Easter | New-arrivals launch; Easter modest, family/food only | Product bundling |
| May | Mother's Day (market-specific date; 2nd Sunday in May in many countries) | Gift bundles, personalization — often higher AOV than Valentine's | Valentine's campaigns (same mechanics) |
| Jun | Father's Day (market-specific date; 3rd Sunday in June in many countries) / summer kickoff | Seasonal launch; urgency around the holiday season | Product bundling |
| Jul | Summer sale | Genuine discount — common in many European retail markets, but check your country's sale periods and rules | Running a sale in PrestaShop |
| Aug | Summer slump | Defensive — don't discount into a dip; prep Q4 instead | Surviving the summer slump |
| Sep 1–15 | Back to school | Themed launch, not necessarily discounted | Back to school beyond fashion |
| Oct | Autumn launch / BF warm-up | New collections; start the Black Friday email list warm-up | Black Friday prep: automating discounts |
| Nov 11 | Singles' Day | Early discount that doesn't cannibalize Black Friday | Flash sales without manipulation |
| Late Nov | Black Friday / Cyber Monday | The big discount — plan weeks ahead, test server load | Black Friday checklist |
| Dec 1–23 | Christmas shopping | Segment by urgency: planners → procrastinators → panickers | Christmas e-commerce |
| Dec 26–31 | Post-Christmas | Gift-card redemption, self-gifting, holiday clearance | Gift cards for PrestaShop |
Two things to read off this table. First, only a handful of windows are flagged as genuine discounts — clearance, the summer sale, Black Friday. Everything else is a launch, a bundle, or a defensive move that protects margin. Second, the dates that need the most lead time (Black Friday, Christmas) have their prep events sitting a month or more earlier (the October warm-up). The calendar is what makes that lead time non-negotiable.
Don't run all of it — match events to your catalogue
A calendar that lists fourteen events is a calendar nobody executes. The discipline is choosing the five or six that genuinely fit your products and audience, and deliberately skipping the rest. Easter is a non-event for an electronics store; Father's Day is gold for a tools or hobby shop and noise for a beauty brand. Pick by category:
- Fashion / beauty: Valentine's, Mother's Day, the summer sale, Black Friday, Christmas. High gift-occasion sensitivity, strong response to bundles.
- Electronics: Back to school, Black Friday, Christmas. Customers literally wait for these three; don't dilute with minor events.
- Home / garden: Spring refresh, summer kickoff, Black Friday. Strongly seasonal demand curve — lean into the launch moments, not the discounts.
- Food / consumables: Valentine's, Easter, Christmas, and seasonal launches. Gift and occasion driven.
- B2B: New Year (fresh budgets), September (new business year), Q4 (use-it-or-lose-it spending). Ignore the consumer gift calendar almost entirely.
Once you've chosen, write the chosen events into one shared document with three columns: the date window, the promotion type (discount, bundle, free-shipping threshold, launch), and the prep deadline. That's the whole calendar. Everything below is about building each row inside PrestaShop without it becoming a manual chore.
Building the calendar inside PrestaShop

A calendar is only useful if the store actually switches promotions on and off on the right dates — without you logging in at midnight. PrestaShop gives you the raw tools for every promotion type in your calendar; the trick is knowing which native feature maps to which row.
The two native discount mechanics
PrestaShop has two distinct ways to drop a price, and choosing the wrong one is the most common calendar mistake:
- Specific Prices (set per product under Catalog → Products → [product] → Pricing, or in bulk via Catalog → Discounts in older versions / the catalog price rules screen). A specific price changes the displayed price itself — the customer sees the new, lower number with no code to enter. This is what you want for a clearance, a seasonal sale, or any "the price is just lower right now" event. Crucially, a specific price has a From / To date range built in: set the window once and PrestaShop applies and removes the price automatically on those dates.
- Cart Rules / Vouchers (Catalog → Discounts → New cart rule). A cart rule is a coupon: it can be code-based or automatic, apply to the whole cart, a category, or specific products, and trigger free shipping or a gift. Use it for free-shipping thresholds ("free shipping over €50 this weekend"), gift-with-purchase, early-access codes for your email list, and any conditional offer. Cart rules also carry Valid from / Valid to dates on the Conditions tab.
For the full decision of which to reach for and how to scope it without accidentally discounting your whole catalogue, see running a sale in PrestaShop: cart rules, specific prices and discount strategies. The calendar-level rule of thumb: price-is-lower events use Specific Prices, conditional offers use Cart Rules.
One forward note if you're on PrestaShop 9: the older "Cart Rules" and "Catalog Price Rules" screens are being folded into a single rebuilt discount engine with four explicit discount types — Catalog, Cart, Free-Shipping and Free-Gift. At the time of writing this new engine ships behind a feature flag, so a stock PS9 store still shows the familiar Cart Rules / Catalog Price Rules screens until the flag is turned on. The planning logic in this calendar doesn't change either way: you're still deciding "price-is-lower" versus "conditional offer" per row.
Make the dates fire automatically
Both mechanics above have native From/To dates — so the moment you build a calendar row, set its window and walk away. This is the single most valuable habit a calendar enables: you sit down once, configure the whole quarter's promotions with their date ranges, and PrestaShop turns each one on and off on schedule. No midnight logins, no "I forgot to switch off the summer sale" running for three weeks into autumn at full discount.
The native From/To fields handle most of the calendar cleanly. Where they fall short is the surrounding choreography — flipping homepage banners, swapping category descriptions, or coordinating a discount that needs to start the instant a countdown hits zero across several products at once. For that orchestration layer, see scheduled discounts: promotions that start and stop automatically, which goes into the back-office scheduling in depth. For the genuinely time-pressured events on your calendar — Singles' Day, a 24-hour flash — the urgency mechanics (countdown, honest scarcity, no dark patterns) live in flash sales in PrestaShop.
The visual side of every calendar row
Every promotion on the calendar needs a banner, a homepage slot, maybe a category header — and that's usually where a planned event stalls, waiting on a designer. If your calendar has a dozen events, that's a dozen design jobs. We built Banner Revolution precisely so a store owner can produce on-brand promotional banners from the back office, so the visual work stops being the bottleneck that makes you skip an event. The benefit for your calendar: the design step stops being a reason to cancel a planned promotion.
Automating the recurring events so next year is half the work
A calendar's compounding payoff is that most of it repeats. Last year's summer-sale cart rule, this year's clearance Specific Price, the recurring free-shipping weekend — these are the same configuration with new dates. Two habits make year two dramatically lighter.
First, document each event's configuration next to its calendar row: which mechanic, what scope (category? product list?), the exact discount, the conditions. Next year you're editing dates, not rebuilding from memory. Second, lean on automation for the events that are genuinely time-critical. For Black Friday specifically — where the discounts need to go live and come down on the dot, often across hundreds of products — manual configuration is where mistakes happen; automating Black Friday discounts walks through doing it without hand-editing every product.
If your calendar leans heavily on recurring, time-boxed deals — a weekly flash, a rotating "deal of the day," seasonal sales that need to launch and expire reliably — running each one by hand stops scaling. Sales Revolution automates the start/stop and countdown side of flash deals so a recurring slot on your calendar runs itself. The point isn't to add tools for their own sake — it's that the events you'll actually keep are the ones that don't demand manual work every single time.
Measuring the calendar — and pruning it next year
A calendar isn't a set-and-forget document; it's a hypothesis you test every year. After each event, you only need a few numbers to know whether it earned its place: revenue during the window versus a normal week, the margin after the discount (not just the headline revenue), and whether sales in the weeks before the event dipped — the tell-tale sign customers were just waiting for the discount.
That last check is why margin matters more than revenue. A summer sale that doubles revenue but ran at a discount deep enough to erase the extra profit, while also pulling forward sales that would have happened at full price anyway, is a loss dressed as a win. Track every promotion's real contribution in your reporting — our Financial Revolution reports break revenue down by period and margin so you can see which events actually paid — and use that to prune next year's calendar. Keep the events that earned their lead time; cut the ones that just trained your customers to wait. A seasonal calendar isn't about running more promotions. It's about running fewer, better ones, on purpose, with enough runway to do each one properly.
Common questions about a seasonal sales calendar
How many promotional events should a year's calendar actually contain?
Fewer than you'd guess — usually five or six that genuinely fit your catalogue, with only two or three of those being real discounts. The rest are launches, bundles or free-shipping moments that protect margin. A calendar listing every holiday is one nobody executes; the discipline is choosing what to skip. Match the events to your category using the breakdown above.
Do I have to log in at the start and end of each promotion to switch it on and off?
No, and that's the point of building it inside PrestaShop. Both native discount mechanics carry their own date windows — a specific price has From/To fields, a cart rule has Valid from / Valid to. Set the window when you build the row and the store applies and removes the discount on schedule. The one gotcha is caching: a full-page cache or CDN can keep serving the old price after the window opens, so flush cache at go-live for a hard-start sale. The mechanics are in scheduled discounts.
What's the difference between a Cart Rule and a Catalog Price Rule for calendar planning?
A Catalog Price Rule writes specific prices in bulk against conditions (a whole category at 20% off for a date window) — the customer sees the lowered price while browsing. A Cart Rule is a voucher that acts on the basket at checkout — free shipping over a threshold, a code from your email, a spend-and-save tier. As a calendar rule of thumb: "the price is just lower right now" rows use specific prices / catalog price rules; "do something to qualify" rows use cart rules.
Will this calendar still work on PrestaShop 9 with its new discount engine?
Yes. PS9 reorganises the back office into four explicit discount types (Catalog, Cart, Free-Shipping, Free-Gift), and that engine currently ships behind a feature flag — so most stores still see the familiar Cart Rules and Catalog Price Rules screens. Either way, every discount type still carries a date window, which is all the calendar relies on. Your planning document doesn't change; only the screen you build each row on might.
How do I tell whether an event earned its place on next year's calendar?
Look past headline revenue at three numbers: revenue during the window versus a normal week, the margin after the discount, and whether sales dipped in the weeks before the event (the sign customers were just waiting). An event that lifts revenue but erases the extra profit and pulls forward full-price orders is a loss dressed as a win — cut it. Reporting that breaks revenue down by period and margin, like Financial Revolution, makes that call straightforward.
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.