Post-Purchase Emails: What to Send After Someone Buys

Last reviewed June 2026 — the order-status email triggers, mails/{iso}/ template paths and back-office locations below are current for PrestaShop 1.7, 8.x and 9.x (with the 1.6 menu names noted inline).

The moment someone clicks "Confirm order," your store sends an email automatically — PrestaShop fires the order confirmation without you lifting a finger. And for most stores, that is the last email the customer ever hears from you until you blast them a newsletter weeks later. That silence is the gap. A buyer who just paid you is at the single highest point of trust they will ever have with your brand: they are checking their inbox for the confirmation, watching for the dispatch notice, thinking about the thing they bought. Everything you send in that window lands. This post is about exactly what to send in it — mapped onto PrestaShop's own order lifecycle, so you know which emails the platform already sends, which ones it can't, and what to bolt on for the rest.

One boundary up front, because it decides which tool you reach for: post-purchase email splits into transactional messages (confirmation, dispatch, delivery — tied to an order changing state) and lifecycle marketing (review nudges, cross-sells, the slow drip back toward a second order). PrestaShop handles the first natively and handles the second not at all. Knowing where that line falls is the whole game, and most of this guide is about working both sides of it.

What PrestaShop already sends — and from where

PrestaShop's transactional emails are driven by order statuses, not by a marketing schedule. Every status in your shop lives in the ps_order_state table and is managed under Shop Parameters → Order Settings → Statuses (in PrestaShop 1.6 it sits under Orders → Statuses). Open any status — "Payment accepted," "Shipped," "Delivered" — and you'll see a checkbox, "Send an email to the customer when changing to this status," plus a field naming which mail template to use (the exact control varies by version). When an order moves into that status, PrestaShop calls Mail::Send with the matching template. That is the entire native engine: a status change is the trigger, and the email is the payload.

[SCREENSHOT: a PrestaShop order status edit screen under Shop Parameters → Order Settings → Statuses, highlighting the "Send an email to the customer when changing to this status" checkbox and the template selector]

The templates themselves are real files on disk, not database rows. They live in mails/{iso}/ — for example mails/en/order_conf.html and its plain-text twin order_conf.txt, alongside shipped.html, order_changed.html and the rest. There is one folder per installed language, and PrestaShop picks the folder matching the customer's language at order time. This matters for two reasons. First, if you edit a template under International → Translations → "Email templates translations" (Localization → Translations in 1.6) and your changes vanish, it's usually because a theme or module ships its own mails/ override that wins over the core copy. Second, every variable in those templates ({firstname}, {order_name}, {shipping}, {products}) is populated by the controller that fired the mail — so the data you can show is whatever the order object already holds, nothing more.

So out of the box, with zero extra software, PrestaShop gives you three of the five emails below: confirmation, payment accepted, and shipped. The catch is that they fire only on a status change, they fire once, and there is no concept of "send this email three days after delivery." That timed, sequenced behaviour is precisely what the platform can't do — and where the rest of this guide earns its keep.

The post-purchase sequence, mapped to PrestaShop order states

Here is the sequence worth running, with each email pinned to the PrestaShop event that should trigger it and an honest note on whether the platform can do it alone.

1. Order confirmation — the most-opened email you'll ever send

Confirmation emails are opened at rates most marketers would trade a limb for; transactional mail of this kind routinely clears the open rates of any promotional campaign by a wide margin, because the customer is actively looking for it. Don't waste that attention on a bare receipt. PrestaShop's default order_conf template already lists products, totals and shipping — edit it under International → Translations → "Email templates translations" (or directly in mails/{iso}/order_conf.html) to add: a realistic shipping timeframe, a direct link to order tracking in the customer's account, and one clear support contact line. Every "where is my order?" message you pre-empt here is a support ticket you never have to answer. So what? The single highest-attention email in your store doubles as your cheapest support-deflection tool — you're answering the question before the customer asks it.

One practical PrestaShop note: if a customer says they never got the confirmation (spam folder, typo'd address, a payment that confirmed late), the native back office has no clean "resend" button on older versions. We built Resend Order Confirmation for exactly that — re-fire the confirmation from the order page in one click, so a missing email doesn't turn into a refund request.

2. Dispatch notification — anxiety, defused

The window between "I paid" and "it's coming" is where buyer's remorse and anxiety live. The shipped email closes it. PrestaShop fires the shipped template automatically when an order changes to a status configured to send that template — ideally after the tracking number and the carrier's tracking URL are set — and the template then exposes that tracking URL. Make sure the carrier's tracking link is actually configured under Shipping → Carriers (the "URL" field with the @ placeholder for the tracking number), otherwise the email ships a dead link. Reinforce the delivery window you promised at checkout: if you run an estimated-delivery-date display on the product page, quote the same dates in the dispatch email so the story is consistent end to end. Mismatched dates between the product page and the email read as carelessness and breed exactly the support pings you're trying to avoid.

3. Delivery follow-up — the email PrestaShop can't time

Two or three days after the parcel lands, ask one human question: did it arrive, and are you happy with it? This is the first email in the sequence the native platform cannot send on its own, because it isn't a status change — it's "X days after a status change." You have two honest routes. If your carrier writes a "Delivered" status back into PrestaShop, you can hang a follow-up off that status; if it doesn't, you're scheduling off the order date plus an estimate. Either way you need something running a clock, which is where an email-automation platform comes in (covered just below). The payoff is double: you catch a damaged or wrong item before it becomes a chargeback or a one-star review, and you warm the customer up for the ask that follows.

4. Review request — timing beats everything

Ask too early and the customer hasn't used the product; ask too late and the glow has faded. Five to seven days after delivery is the sweet spot for most physical goods (longer for products with a learning curve). The mechanics matter more than the copy: the request must drop the customer onto the exact review form for the exact product they bought, in one click — no login wall, no hunting through the catalogue. PrestaShop doesn't provide a full modern review workflow in core for many installs, so most stores run a reviews module; ours, Reviews & Ratings, generates that per-product review link and can verify the reviewer actually purchased, which keeps the ratings honest and the rich-snippet stars legitimate. A review request isn't really a post-purchase email — it's a loyalty mechanism wearing a post-purchase costume, and we treat it as one in loyalty programs for PrestaShop. Reviews you earn this way also feed your referral engine — a customer who just told the world they love the product is the easiest one to ask for a friend's name.

5. Replenishment and cross-sell — the second order

Two to four weeks out, the email shifts from service to gentle commerce. The trick is that it must be driven by what they bought, which means reading the order's products. Two distinct plays:

• Replenishment for consumables — coffee, filters, supplements, pet food. If the typical reorder cycle is 30 days, land the reminder at day 25 so it arrives just before they run out. This is the single highest-converting cross-sell because you're not selling, you're reminding.
• Complementary cross-sell for durable goods — the camera buyer who needs a bag, a card, a strap. "Customers who bought X often add Y" outperforms "BUY NOW" every time, because it reads as help, not pressure.

Both plays need to read the order's line items, which live in ps_order_detail. You can preview your replenishment audience for a given product in the read-only SQL Manager (Advanced Parameters → Database) before you build the flow — this lists buyers of one product (by product_id) whose order is about old enough to reorder, newest first:

SELECT c.email,
       c.firstname,
       od.product_name,
       o.date_add AS ordered_on
FROM ps_order_detail od
JOIN ps_orders o   ON o.id_order = od.id_order
JOIN ps_customer c ON c.id_customer = o.id_customer
WHERE o.valid = 1
  AND c.newsletter = 1
  AND od.product_id = 42            /* the consumable's product ID */
  AND o.date_add < DATE_SUB(NOW(), INTERVAL 25 DAY)
ORDER BY o.date_add DESC;

That's a one-off snapshot for planning. To send it on a rolling 25-day clock per customer, you hand the logic to an automation platform — the query just shows you the data is there.

Keep this strictly separate from your promotional calendar. A customer who paid full price for a winter coat on Monday should not see it half-price on Thursday — that's the fastest way to teach people to wait for the discount and to feel cheated for not having. Hold all sale and new-arrival blasts until the post-purchase sequence has finished; let the lifecycle emails own this window cleanly.

Where native stops and a tool starts

Lay the five emails against PrestaShop's capabilities and the split is clean: the platform owns the status-driven transactional pair (confirmation, dispatch) and can't touch the time-driven, product-aware trio (delivery follow-up, review request, cross-sell). To run the back half you need a tool that does three things PrestaShop's order engine doesn't: schedule on a delay, branch on what was purchased, and stop the sequence if the customer reorders. That is an email-automation platform syncing your PrestaShop customers and orders.

Which platform depends on how far you're taking this — and this is a decision the whole cluster covers, so pick the depth that fits rather than over-buying:

• Mailchimp — the gentlest on-ramp; fine for a basic timed sequence if your needs are simple.
• Klaviyo — built for e-commerce lifecycle: product-level triggers, replenishment logic, SMS alongside email.
• Omnisend — if you want the post-purchase flow to spill into SMS and push from one place.
• ActiveCampaign — when the sequence needs to branch on real CRM conditions, not just timers.

Whichever you choose, the prerequisite is a clean sync of your PrestaShop order and customer data into it — without "this customer bought product 4821 on the 3rd," none of the timed, product-aware emails above can fire. For where post-purchase fits inside the bigger automated-email picture, the overview is email marketing for online stores, and the list those automations send to is grown the right way in the PrestaShop newsletter guide.

One thing this sequence is not: win-back

It's tempting to keep emailing until the customer buys again, but there's a clear handoff. The post-purchase sequence runs while the customer is still engaged — days and weeks after a recent order. The moment a customer has gone quiet past their normal reorder cycle, you've crossed out of post-purchase and into re-engagement, which is a different sequence with a different tone and different incentives. Don't fold the two together. When a buyer lapses, hand them to the win-back sequence — that's the post built for exactly that job, and keeping the two separate is also how you avoid sending the same person two overlapping campaigns.

Measuring whether the sequence actually pays

Transactional and lifecycle emails get judged on different numbers — don't average them together.

• Transactional (confirmation, dispatch): watch open rates (these run very high — a sudden drop usually means a deliverability or spam-folder problem, not bad copy) and, indirectly, your "where is my order?" ticket volume. Fewer of those tickets is the real win, and it's free.
• Review request: click-through to the review form, and reviews actually submitted. If clicks are healthy but submissions aren't, the form has friction — usually a login wall or the wrong product.
• Cross-sell / replenishment: the only metric that matters is repeat-purchase rate within 90 days for customers who got the sequence versus those who didn't. That's the number that tells you the back half is paying for the tool.
• Unsubscribe rate per email: keep it low. A spike on one specific email in the chain — almost always means that email is mistimed or too salesy; cut or re-time it.

Compare those numbers over a real window — at least 30 days and enough orders to be a trend, not noise — before you decide a given email earns its place. It's common to hear that stores with a disciplined post-purchase programme see meaningfully higher customer lifetime value than stores that go silent after the receipt; treat that as a direction to test on your own data, not a guaranteed figure.

The honest summary: PrestaShop already does the hard, scary part for free — it confirms the order and announces the dispatch the instant the status flips, and you should make those two templates work harder than they do today. Everything past that — the follow-up, the perfectly-timed review nudge, the replenishment reminder that lands the day before they run out — is timed, product-aware marketing the platform was never built to run, and it's worth one automation tool to do it. Get both halves right and the customer who just paid you once becomes the customer you barely have to sell to ever again.

Frequently asked questions

Which post-purchase emails does PrestaShop send without any extra module?

Three of them, all tied to order statuses: order confirmation, payment accepted, and shipped (dispatch). Each fires once, the instant an order moves into a status that has "Send an email to the customer when changing to this status" enabled under Shop Parameters → Order Settings → Statuses. The delivery follow-up, review request and replenishment/cross-sell emails are time-based, so native PrestaShop can't send them — they need an automation tool.

I edited an email template and nothing changed — why?

Almost always a mails/ override. A theme or a module can ship its own copy of a template (for example themes/your-theme/mails/en/order_conf.html), and that copy wins over the core mails/en/ file and over edits made in International → Translations. Find the override that actually loads for the customer's language and edit that one. After editing, clear the cache so the change is picked up.

How do I resend an order confirmation a customer says they never received?

On many PrestaShop versions the order page has no clean one-click resend for the confirmation specifically. Check the order's status history first — re-applying a status that's configured to send email will re-fire that status's template. If you need a reliable, dedicated button, our Resend Order Confirmation module re-sends the confirmation from the order page directly, which avoids juggling statuses just to get one email back out.

Can I time a "review request" or "replenishment" email natively?

No. PrestaShop only triggers email on a status change, never on "X days after" an event. A review request 5–7 days after delivery, or a replenishment nudge at day 25, both need a scheduler — that's an email-automation platform (Klaviyo, Omnisend, ActiveCampaign or Mailchimp) synced to your order and product data so it can fire on a delay and branch on what was bought.

My order emails are landing in spam — what do I check first?

Go to Advanced Parameters → E-mail and switch from PHP mail() to authenticated SMTP with a sender on your own domain. Then publish SPF, DKIM and DMARC DNS records for that domain so receiving servers trust your mail. Since order confirmations are the highest-open email you send, a sudden drop in their open rate is usually a deliverability problem, not a copy problem — start there.