Automated Support & Changelog Emails

Super Speedy Emails can automatically email the people who own a product whenever there’s something to tell them – for example, sending the changelog for a plugin to everyone who bought it. This page explains how the feature works, how to set it up safely, and how the underlying type system lets developers control who gets an email and what it says.

The system is built in two layers:

• A generic, vendor-neutral engine in the core plugin. It fans out over a product list, resolves owners, applies your audience rules, the suppression gate and a per-day guard, then queues, sends and logs. It knows nothing about changelogs.
• A changelog implementation that lives in a small companion plugin (Super Speedy Plugins – Changelog Emails). It registers a changelog type that reads each plugin’s readme.txt and decides when there’s a new version worth sending. The core ships no changelog code – the companion is a worked example you can install, read, and adapt.

You can use the companion’s changelog behaviour as-is, or register a type of your own to send anything you like – security advisories, maintenance notices, renewal reminders – to product owners.

What a Support Email is

A Support Email is a saved record you create in the admin. It has five parts:

1. A type – what kind of email this is, chosen from the types the plugins on your site have registered (e.g. “Changelog (product update)”). The type decides how recipients are chosen and which placeholders are available, and it can add its own options to the editor.
2. Products – a checklist of the products this email is about. This is the fan-out axis: the engine sends one email per product to that product’s owners. An owner of three of the ticked products gets three separate emails, each about one product (with its own changelog and its own history).
3. Audience rules (optional) – narrow each product’s owners by purchase recency (bought within / more than N days ago, by first or last purchase), combined with ALL or ANY. Leave empty to email every owner.
4. Subject + body – the content, with placeholder tokens. The subject defaults to Updates available for {product_name}.
5. Footer and frequency – the “why you’re receiving this” line, and an optional cap such as “at most 1 email every 7 days per person”.

Key things to understand first

• Bundle owners are included automatically. If a customer bought a bundle that contains the plugin, they count as an owner of that plugin.
• It has its own unsubscribe. Support emails use the product_support category, whose opt-out is separate from your marketing opt-out. Someone who left your newsletter still gets product updates; someone who turned off product updates still gets your newsletter. (See Unsubscribes & the Preference Centre.)
• At most one per product per person per day. A built-in per-day guard means a given product can’t email the same customer twice in a calendar day, no matter how many times you click Send or how the cron fires.
• “Is there news today?” is the type’s job. The core doesn’t track versions. Whether a product has anything to send right now is decided by the type – for changelog emails, the companion answers “yes” only when the version advanced.
• A type can add its own options. The changelog type, for example, adds a Send to dropdown offering all owners or active licences only. Change it, click Preview, and the recipient counts move before you save.

The safe baseline (read this first)

The single most important thing to understand about the changelog companion: the first time it sees a plugin, it sends nothing. It records the plugin’s current version as a starting point (“baseline”) and emails nobody. Only when the version moves past that baseline does anyone get an email.

This means you can switch the feature on for a whole catalogue without accidentally emailing thousands of customers a changelog they’ve already read. So a normal rollout is:

1. Activate the changelog companion plugin and create a Support Email with your products ticked.
2. Send now once – this records baselines and sends nothing (0 emails).
3. From then on, each real plugin update emails its owners once.

Setting it up

Go to Super Speedy Emails → Support Emails and click Add Support Email.

1. Name it, pick a type, pick products

Give it a name (e.g. “Plugin updates”) and choose the Type. The type is what makes this a changelog email rather than something else; it decides how recipients are chosen and which placeholders you can use. If no types are listed, no plugin on your site has registered one yet – install the changelog companion, or see the developer guide to write your own.

In Products, tick the individual plugins whose owners should receive update emails. Use Select all / the filter box for long catalogues.

• Don’t tick bundles or service products. Bundle owners already receive each component plugin’s email automatically (via bundle expansion), so ticking the bundle itself would be wrong – a bundle has no single changelog. Service products have no changelog at all.
• For the changelog case, each ticked product needs a plugin slug mapped to it in the companion plugin so it knows which readme.txt to read. A product with no mapping simply sends nothing (it fails safe).

2. Audience rules (optional)

Leave empty to email every owner of each ticked product. To narrow by recency, add rules like “bought within the last 365 days” or “bought more than 30 days ago”, combined with ALL (every rule must match) or ANY (at least one). These run on top of the product owners.

For anything more specific, check whether your type already offers it as an option – the changelog type has a Send to dropdown for active-licence-only, for instance. Beyond that, a type’s should_send_to_user callback can apply any per-customer rule you like (licence status, region, spend). See the developer guide below.

3. Write the email

Set the Subject (the default Updates available for {product_name} works for most cases – {product_name} is filled per product) and the Body in the rich-text editor. The editor lists the available placeholders, including any the type provides.

Built-in placeholders (work in subject and body): {product_name}, {first_name}, {email}, {unsubscribe_url}, {manage_url} (preference-centre link), {site_name}, {site_url}.

Placeholders from the type are listed above those in the editor. For changelog emails they include {changelog} (the release notes), {changes_summary} (a count phrased for a subject line) and {version}. Drop them where you want that content to appear; the type fills them in.

If you leave one of the type’s placeholders unfilled – because the type couldn’t resolve it – the record is blocked from sending and the preview tells you which token was the problem, rather than mailing a raw {changelog} to your customers.

4. Preview before you send

Click Preview. This evaluates each ticked product without sending anything and streams a per-product row:

Preview is your safety check, and it never changes any state. If a product shows “No update pending”, there’s nothing to send for it yet – that’s normal until a version advances.

5. Send

Save the Support Email, then click Send now. It evaluates each product and queues the emails, which go out through the normal sending queue respecting your test mode (Live / Log-only / Redirect – see Test Modes). Always rehearse in Redirect mode first so every email comes to you.

Manual send vs. the daily cron

There’s a daily check that runs every active Support Email on a schedule, and a pause switch at the top of the Support Emails screen that governs it. Scheduled sending starts paused, so nothing goes out automatically until you explicitly resume it – and the manual Send now button works either way. Even when it’s running, nothing goes out unless the type says there’s news, and the per-day guard prevents same-day duplicates.

The type system: deciding who and what

The engine hard-codes no changelog logic. At each step it asks the record’s type – code registered by a plugin – to decide. There are five callbacks, each receiving a single SSE_Support_Context object describing the run:

A type also declares which placeholders it provides, whether it sends one email per product or one per person, whether it uses an escalating sequence of reminders, and any options it wants to add to the editor.

The full developer reference, signatures and worked examples are in Automated Support Emails – Developer Guide and the worked example How We Send Our Changelog Emails.

Why you can’t spam by accident

Three things protect customers:

1. The should_send callback – for changelog emails, it only returns “yes” when the version actually advanced, so a blast only happens when there’s genuinely something new.
2. The per-day guard – a given product won’t email the same person twice in a calendar day, so re-clicking Send or an overlapping cron run can’t double-send.
3. The suppression gate – anyone who unsubscribed from product updates, or was globally suppressed by a hard bounce or spam complaint, is removed automatically.

Before you go live – checklist

• [ ] The changelog companion plugin is active, with your products mapped to plugin slugs.
• [ ] Settings → Sending: a Product support sender identity (From / Reply-To) is configured.
• [ ] A Support Email exists with the right products ticked and saved Active.
• [ ] Ran Send now once as a baseline – it sent 0 and recorded current versions; re-running Preview now shows “No update pending” for everything.
• [ ] Rehearsed a real bump in Redirect test mode and confirmed the email looks right, with a working “unsubscribe from product updates” link.
• [ ] Switched to Live. From now on: ship an update → Preview → Send now.

Further reading

Related products

Super Speedy EmailsProgrammable, MCP-controllable emails – let an AI agent run your campaigns