WooCommerce Order Emails: Design and Review Safely

Redesigning a WooCommerce order email should make the order easier to understand. Start in Migma to prepare the approved visual direction and copy, then implement and test the final template through the WooCommerce controls or customization method your store uses.

Before choosing an extension or rebuilding the template, inspect the current native settings. WooCommerce's official documentation describes shared styling, individual notification settings, desktop and mobile previews, and test emails. Some controls depend on enabled features, so an older guide may not describe the settings available in your store.

This guide is published by Migma for teams reviewing transactional email design. Product details were checked on October 14, 2026. It describes a design handoff, not a native Migma plugin that automatically replaces WooCommerce order emails.

Identify the notification before changing its appearance

Open WooCommerce → Settings → Emails and find the exact notification. The official email settings guide distinguishes notifications sent to store recipients from those sent to customers.

That distinction prevents a common naming mistake: the “New order” notification is not simply a customer-facing welcome message. Review its recipients and purpose before treating it as the email customers see after checkout.

For a customer order message, confirm which order state sends it and what the state means in your store. WooCommerce documents the processing-order email as containing order details after payment. Completed-order emails are sent when orders are marked completed, usually indicating shipment. “Usually” matters: review your actual fulfillment process before adding a promise that every completed order is already in transit.

Keep a sample of the existing message and record the notification name, store version, enabled features, and relevant extensions. That becomes the baseline for the redesign.

Check what the current settings can already do

WooCommerce's documented template controls include a logo, footer text, colors, and additional appearance settings when Email improvements is enabled. Individual notifications also expose settings such as subject, heading, additional content, and email type, with variations by notification.

If the problem is an outdated logo or unreadable colors, the native controls may be sufficient. A more extensive layout change may require another supported customization path. Choose the smallest change that solves the reader's problem.

Do not assume that another store's screenshot matches yours. Extensions can add emails, and features can change which controls are available. Treat the settings visible in your own installation and the current official documentation as the implementation reference.

Before modifying anything, agree on the owner of the store change. The designer can approve appearance, while the store administrator or developer owns installation and behavior.

Prepare the reader's order of attention

Use Migma to develop a clear visual draft based on reviewed brand settings. Supply the exact notification purpose and the data that must remain visible.

For an order update, a useful reading order is the store identity, the status, the order reference, essential order details, and the support action. Keep the status explanation brief. The customer should not need to interpret internal order labels to understand what happened.

A hypothetical before-and-after might look like this:

This is a review proposal, not measured performance data. Keep the change tied to what the reader needs.

Preserve store-generated facts and placeholders

An email design cannot become the source of truth for order totals, payment state, shipping addresses, or refund details. Preserve the data generated by the final WooCommerce implementation.

The official settings guide lists placeholders accepted by certain fields, including the site title, order date, and order number. Do not assume those field-level placeholders work in every custom template or extension. Ask the implementer to verify the syntax in the destination.

Use sample orders that exercise realistic variation: a long product name, multiple items, a missing optional field, and the payment or refund states relevant to the selected notification. A neat single-item preview can hide problems in a real order.

Review currency and date presentation against your store settings. Avoid hard-coding a value in Migma merely because it makes the mockup look complete.

Separate the design preview from implementation acceptance

Run Migma Email Preflight for creative and inbox review. If you download HTML, treat it as a handoff requiring adaptation to the destination's actual template system. A file exported from Migma does not automatically install a WooCommerce email.

After implementation, use WooCommerce's documented preview and test-email controls. Then check a controlled order journey where appropriate through your team's normal process. Confirm the intended notification, recipient, subject, order facts, links, and reply route.

Review the delivered version rather than relying only on a browser preview. Your final sending setup and inbox can affect what the customer receives. Save the accepted version and keep a recovery path to the previous working template.

Approve one notification, then expand carefully

Once the first notification passes, reuse the reviewed visual treatment for related emails. Review each message's purpose and data separately; a refund message should not inherit the success wording of a processing-order email.

Migma helps make the creative clear and reviewable. WooCommerce remains responsible for the store notification's data and behavior. That division gives both teams a concrete result to approve: a recognizable email that accurately explains the order event it represents.

Frequently Asked Questions