Default WooCommerce emails look exactly like default WooCommerce emails: a coloured header, a grey table, no logo, nothing that says who sent it. They are also, by a wide margin, the highest-open-rate messages your store will ever send — because the customer is actively waiting for them. Fixing that takes about twenty minutes and no code. Here is the whole path, and one thing to understand first about where these emails come from. These are WooCommerce emails, not plugin emails Worth knowing before you go looking for a template editor. Post-Purchase Hub does not fork your emails or add a parallel notification system. Its Emails tab exists to tell you that and send you to the right screen — the card is headed “Where these emails are configured”, and the only control on it is a button labelled Open WooCommerce email settings. This is a good thing twice over. Anything you style once applies to every transactional email your store sends, not just the post-purchase ones. And if you ever remove the plugin, your email branding stays exactly where it was. Where the settings actually live Go to WooCommerce → Settings → Emails. The Email notifications section lists every transactional email your store can send, with a toggle, its content type, its recipients and a Manage button on each row. Two things are worth noticing on this screen before you touch any styling. First, some emails are off by default, and the customer-facing Cancelled order email is often one of them. If you have switched on self-service cancellation requests, that is the message a customer gets when you approve one — leaving it disabled means approving a request silently, which produces exactly the follow-up email you were trying to avoid. Second, there is no “shipped” email in core WooCommerce. Completed order is the closest thing, which is why its wording matters more than the default text suggests, and why a live order timeline does the work an email cannot. Step 1: Fix the sender details first The least glamorous step and the one that matters most for deliverability. Set the “From” name to your store name as customers recognise it, and the “From” address to a real, monitored address on your own domain. A no-reply address on a domain that does not match your site is the fastest route into a spam folder, and it throws away every reply a customer might have sent you. WooCommerce also recommends a dedicated SMTP setup here rather than relying on your host’s mail function. Step 2: Add your logo and colours Below the notification list is the Email template section — “Customize your WooCommerce email template and preview it below.” Recent WooCommerce versions give you: Underneath sits the Color palette, with an Auto-sync with theme changes toggle that pulls colours from your active theme. Switch it off to set them by hand: If your store is on an older WooCommerce release you will see the earlier equivalents — Header image, Base colour, Background colour, Body background colour, Body text colour. The advice is identical; only the labels moved. Use the footer text for the things customers look for when something has gone wrong: store name, a support address, and a link to your returns policy. It appears on every email, which makes it the cheapest support deflection you will ever set up. Step 3: Rewrite the subject lines and headings Open any email with Manage and you get its recipient, subject, heading and additional content. WooCommerce placeholders work in the subject and heading fields, and the list is short — it is worth knowing exactly what is available rather than guessing: There is no customer-name placeholder in the subject line, so the common advice to open with a first name does not apply here. What does work: Step 4: Preview, then send yourself a real one The Email preview section lets you pick any template from a dropdown and view it desktop or mobile, and there is a Send a test email button that will deliver it to any address you like. Use both — the preview catches a logo that is too large or an accent colour that eats your text; the test email catches how a real client renders it. Then do the last mile properly: place a test order on your own store, move it through each status from the admin, and read every email as it arrives. Check it on a phone as well as a desktop. Email clients are relentlessly inconsistent, and most of your customers are reading on a phone. What emails cannot do, and what to use instead An email is a snapshot of one moment. The question customers actually have — where is my order right now — is better answered by a live page than by a message sent three days ago. Set up the order status timeline alongside your emails, then link to it from the footer text, so every email you have ever sent doubles as a route back to the live answer. That combination is what actually reduces inbox volume: fewer “where is my order” emails during a busy season, because the answer is one click away from every message you have already sent. A quick checklist

Two policies shape almost everything customers experience after checkout: how long they can change their mind, and what happens when the parcel arrives and they do not want it. Most stores write both as a wall of legal text nobody reads, then handle every case by email anyway. Here is how to set both so they hold up — starting with the thing most merchants get wrong about cancellation windows. Your cancellation window is not a timer The instinct is to set a clock: cancellable for thirty minutes, then locked. Post-Purchase Hub deliberately has no such setting. Eligibility is driven by order status. Under WooCommerce → Post-Purchase Hub → Actions, Cancellable statuses is a row of checkboxes over your own WooCommerce statuses — Pending payment, Processing, On hold, Completed, Cancelled, Refunded, Failed, Draft, plus any custom ones your other plugins add — and the button vanishes the moment an order moves out of the ones you ticked. Once you sit with it, the status model is the better one. A timer can leave a packed, labelled parcel technically cancellable at minute twenty-nine. Status tracks what has actually happened to the goods. Your real cancellation window is therefore however long orders sit in your ticked statuses before someone picks them — which means the lever is your fulfilment workflow, not a settings field. Choosing statuses by how fast you fulfil Pull up a week of orders and look at how long each stayed in a status before moving. That number is your window. Then choose accordingly: If the numbers say your real window is three minutes, that is not a reason to fake a longer one. It is a reason to add a short holding status before picking — custom statuses appear in this list like any other — which buys real time and keeps the button honest. The three supporting fields Restock on approval is the fourth switch. Turn it on if your stock counts are accurate; leave it off if you reconcile stock by hand, otherwise approvals will quietly inflate your inventory. Either way refunds are unaffected — those stay in WooCommerce, one click from the notification. Returns are a policy, not a plugin setting Worth being clear about this, because it changes how you write the policy. Post-Purchase Hub handles cancellation requests. It does not run an RMA workflow, generate return labels, or issue refunds — the readme is explicit that it never touches a payment gateway. What it gives you is the intake: the Get help with this order action, a message form that reaches you with the order number, status and items already attached, instead of a free-form email you have to decode. So the return policy itself is yours to write and yours to run. The plugin’s job is making sure the request reaches you with context attached. Writing a return policy people actually read Skip the boilerplate. Three facts, in this order, in plain language: Then add the fourth thing almost nobody writes down: what happens next, and how long it takes. “We refund within three working days of the parcel arriving with us” prevents a whole category of follow-up email. Customers skim. A policy readable in ten seconds gets followed more often than a thorough one nobody finishes. If you fulfil through a supplier, build the window around the supplier’s shipping time rather than your own — a thirty-day policy that assumes three-day delivery falls apart when the parcel takes two weeks to arrive. The dialog is your policy in practice Whatever you write on the policy page, the sentence customers actually read is the one in the request dialog: “This sends a request to the store — it does not cancel your order right away. We usually respond within 24 hours.” The number in it is the Response time you promise field, which is a good reason to keep that field honest. That reason list is worth paying attention to. Requests are stored with the reason attached, so a month of them usually points at something fixable — a misleading product photo, a delivery estimate that reads slower than it is, a variant picker that misbehaves on mobile. Keep your delivery estimates honest A cancellation policy is easy to defend when the delivery promise beside it is accurate. Under Settings → Timeline → Delivery estimates, handling time and per-shipping-method transit ranges produce the window customers see, and the Working days card below excludes your non-working weekdays and any holiday dates you list. An estimate that consistently holds removes most of the impatience that drives cancellations in the first place. Where to go next If you have not set the actions up yet, start with the self-service cancellation walkthrough. For the queue side — how to work requests quickly without pretending you can automate the decision — see cancellation request rules and the auto-approval question. If you are about to run a sale, flash sale cancellations covers what changes when volume spikes. Subscription stores have a rhythm of their own — running a subscription box on Post-Purchase Hub covers what changes when the same customer orders every month.

WooCommerce ships with one of the least informative order screens in ecommerce: a status word, a table of line items, and nothing that tells a customer what happens next. Post-Purchase Hub replaces the status word with an Order progress list built from your own order statuses, plus a delivery estimate wherever you have given it your shipping times. This walkthrough covers where the timeline appears, how the status-to-stage mapping actually works, how the estimate is calculated, and what to do when your theme is involved. Where the timeline shows up Two places, configured once. The single order page gets the full list. The My Account order list gains a Progress column showing the current stage and its timestamp, so a customer with several open orders sees the state of all of them without opening any. Every stage carries one of three sub-labels — Done, In progress, or Not yet — and the dates shown are real, recorded as the status changes happened rather than calculated backwards. If you want the timeline somewhere else, the [wpmphub_orders] shortcode and the Order timeline block render it on any page; each signed-in customer sees their own orders. Mapping your statuses onto stages This is the step that matters most and the one people rush. The stages themselves are a fixed vocabulary — Placed, Confirmed, Packed, Shipped, Out for delivery, Delivered, plus the terminal states. What you configure is the map: under Settings → Timeline → Timeline stages, every WooCommerce status your store uses gets a dropdown, and you choose which stage it lands on. The defaults are sensible — Pending payment maps to Placed, Processing to Confirmed, Completed to Delivered. Two rules make the rest work: What you cannot do is invent your own stage names — the customer-facing vocabulary is fixed. In practice that matters less than it sounds, because the mapping is many-to-one: three internal statuses that all mean “we have it and are working on it” can all land on Confirmed. Delivery estimates, and why yours might be blank The estimate lives under Settings → Timeline → Delivery estimates and is built from two numbers you supply. Both are calculated against the Working days card below them: Non-working days is a set of weekday checkboxes for the days you do not ship on, and Holidays is a plain list, one date per line as YYYY-MM-DD. Everything listed there is excluded from every estimate. The single most common question about the timeline is why no estimate appears. Almost always the answer is the same: the shipping method used on that order has no transit time configured, and a method with no transit time shows no estimate at all — a deliberate blank rather than a guess. Set it, and the estimate appears. If you run Advanced Shipment Tracking or WooCommerce Shipment Tracking, real tracking data steps in front of the estimate automatically as soon as a tracking number exists — and any other source can be wired in through a filter. Until then the customer sees your honest estimate rather than a fabricated tracking number, which is worth saying plainly in your order emails too. Placement, and what to do about your theme There is one placement setting, on the General tab, and it has two values: The advice here runs the opposite way to the usual instinct. If your theme heavily customises the order templates, that is a reason to stay additive, not to switch. Full replacement looks different in every theme and the plugin describes it as the single biggest source of support tickets for plugins of this kind — so it also refuses to turn on while it detects that your theme has customised those templates, rather than producing a broken page. The Template conflicts line in the Status panel is where you find out. The wizard’s Display step asks the same question during setup, with a preview built from a real order in your store. For finer visual adjustments, the plugin exposes filters throughout — including the stage map itself — and its markup responds to ordinary CSS in your child theme. Older orders show stages but no dates WooCommerce does not keep a history of status changes, so a plugin can only record them from the moment it is installed. Orders that predate the install show their stages without timestamps rather than showing invented ones. Running wp wpmphub backfill-timeline from WP-CLI fills in what can be derived from the dates WooCommerce does store. A quick check before you call it done Where this pays off A readable timeline is the single biggest lever on “where is my order” email volume — see cutting WISMO emails during the holiday rush for what that looks like in a busy season. Pair it with self-service cancellations and you have covered both halves of what customers actually want after checkout: visibility and control.