Every cancellation that arrives by email costs you the same four minutes: read it, find the order, check whether it has shipped, reply. Post-Purchase Hub moves the front half of that onto the customer’s own order page. They submit a structured request with a reason attached; you get a queue with two buttons instead of an inbox thread. What it does not do is cancel anything on its own, or issue a refund. Both are deliberate, and understanding why is most of what you need to set this up well. Why manual cancellation handling costs more than it looks A single cancellation by email spans three tools: the inbox, the WooCommerce order screen, and whatever you use for refunds. None of them know about each other, so you carry the context in your head between them. Do it ten times in a week and it is an afternoon. The expensive part is not the decision — that usually takes seconds. It is the retrieval: working out which order the email refers to, checking its current status, remembering whether this customer already asked once. A request that arrives already attached to the order removes all of it. Step 1: Install and run the wizard From Plugins → Add New, install and activate the plugin, then run the setup wizard. Nothing reaches your storefront until you finish it. The full installation guide covers the requirements and all seven steps if you want the detail. Step 2: Choose which actions customers get The wizard’s Actions step — later WooCommerce → Post-Purchase Hub → Actions — asks what a customer can do about an order without emailing you. There are four, each an independent toggle: Turning an action off is not cosmetic: it is removed from the customer’s order pages and refused at the API, so a hidden button cannot be submitted anyway. Reorder and invoice are close to risk-free. Cancellation requests are the one worth configuring properly before you go live. Step 3: Set the cancellation request rules This is the core of the setup, and it works differently from the countdown timer most people expect. There is no “cancellable for 30 minutes” setting. Eligibility is driven by order status: Cancellable statuses is a set of checkboxes over your WooCommerce statuses, and the button disappears the moment an order leaves them. That is a better model than a timer, because it tracks reality: an order that is already packed should not be cancellable at minute eleven just because your window said thirty. In practice your effective cancellation window is however long orders sit in the statuses you ticked before your team moves them on — worth measuring before you set anything. There is more on choosing them well in setting cancellation windows that actually work. Three supporting fields sit alongside it: Restock on approval is the fourth. Switched on, approving a cancellation returns the items to stock. Refunds stay in WooCommerce, one click from the notification — the plugin never touches a payment gateway. Step 4: See what the customer sees Log in with a test account, place an order, and open My Account → Orders. Alongside the new Progress column, each order shows only the actions that apply to it: Request cancellation on eligible orders, Buy these again on completed ones, View or print order and Get help with this order throughout. The dialog itself is doing quiet but important work. It opens with one sentence — “This sends a request to the store — it does not cancel your order right away. We usually respond within 24 hours.” — then asks for a Reason from a dropdown and offers an Anything else? (optional) box before Send request. Step 5: Work the queue Requests land under WooCommerce → Requests, with a count in the menu of everything waiting on you. The list has All types and All statuses filters and sortable columns for request, order, type, age and status — so you can pull the oldest pending cancellations to the top in one click. Open one and you get the order, a link straight to it, the items, the customer’s chosen reason and their note, and an Internal note (not shown to the customer) box above the Approve and Decline buttons. Approving changes the order status and optionally restocks; declining leaves the order exactly as it was. Requests also appear on the WooCommerce order screen itself, so you are never surprised by one you did not know about. A checklist before you go live Frequently asked questions Does it cancel orders automatically? No, and it never will. A request lands in the queue and nothing happens to the order until you approve it. If you were hoping to automate the approvals themselves, the honest answer about auto-approval is worth five minutes. Does it issue refunds? No. Approving a cancellation changes the order status and optionally returns items to stock. The refund is done in WooCommerce, on the order, one click from the notification. Why can one of my customers not request a cancellation? The button hides itself, correctly, when the order is not in a cancellable status, when a request is already pending on it, when the order has hit its per-order limit or is inside the waiting period, or when you have switched the action off. Where to go from here Cancellation requests are one half of the picture; visibility is the other. Pair this with a customised order status timeline so customers can see where an order stands before they think about cancelling at all. If you are heading into a flash sale or run a subscription box, both have wrinkles worth reading first.

If you have just switched on self-service cancellation requests, the next question is almost always the same: can I approve the easy ones automatically? It is a fair thing to want. Reviewing forty low-value cancellations a week is not a good use of anyone’s morning. The honest answer is that Post-Purchase Hub will not auto-approve anything, and the readme is unusually direct about it: “No, and it never will.” Here is the reasoning, and what to do instead — which, in practice, gets you most of the speed you were after. Why nothing is approved automatically The plugin’s position is that a cancellation request lands in a queue and nothing happens to the order until a person approves it. No rule engine, no “under fifty dollars goes through”, no exceptions. The Actions settings say the same thing twice, in the card description and again in the help text under the status checkboxes: a request is never an automatic cancellation. The reasoning holds up. Approving a cancellation is not a data operation — it is a claim about the physical world. Has the parcel been picked? Has the label printed? Has it already left with the courier? WooCommerce order status is a decent proxy for that, but only a proxy, and the gap between the two is exactly where an automatic approval does damage: stock returned for a parcel already on a van, a customer told their order is cancelled while it is in transit to them. The second reason is scope. The plugin never touches a payment gateway and never issues a refund; approving changes the order status and optionally restocks. An automatic approval would therefore produce a cancelled order that is still fully paid, quietly, with nobody aware of it. That is a worse outcome than a request sitting in a queue for two hours. What the rules actually do There is real automation on the Actions tab — it just runs at the other end of the process. Instead of deciding requests for you, the rules stop requests you would have declined from ever being submitted. Tighten the status list and the queue shrinks dramatically — usually more than any approval rule would have saved you, because a request that is never submitted costs nothing at all. Choosing those statuses well is the highest-leverage half hour in the whole setup. Making the review itself fast The remaining work is the queue, and it is built to be worked in batches rather than one email at a time. It sits at WooCommerce → Requests, with a count in the menu of everything waiting on you. Each row carries the request number, the order, the customer, the type, the reason they chose, how long it has been waiting and its current status. Type, age and status all sort, so “oldest pending cancellations” is one click. A routine that works for most stores: Handled this way, a queue of forty is fifteen minutes — and unlike an inbox, it tells you at a glance whether anything is outstanding. A sensible policy, without a rule engine What people are really asking for when they ask about auto-approval is: how do I stop thinking about the easy cases? That is a policy question, and you can answer it without any automation. Start conservative and widen as the history accumulates — which means keeping the history. On the Advanced tab, Keep resolved requests for sets how many days a resolved request survives the daily cleanup, and zero keeps everything. If you intend to review your own decisions, zero or a generous number is the setting you want. If you genuinely need automation Be realistic about what is on offer. The plugin ships filters throughout — the stage map, action availability, tracking detection and invoice sources are the documented ones — but there is no supported hook advertised for deciding requests, and building one means taking on precisely the responsibility the default design was avoiding. The PHP source and test suites are public on GitHub if you want to judge that for yourself. And a refund still will not happen by itself. Where to go next The queue only gets busy if requests are getting through, so start upstream: setting the cancellation rules first, then handling the spike during a flash sale. If you fulfil through a supplier, returns as a dropshipper covers the extra handoff that makes fast approvals harder.

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.