Automations & Onboarding Drips
An automation in Super Speedy Emails is a series of email steps fired in sequence after a triggering event — typically a WooCommerce purchase. The classic use case is a post-purchase onboarding drip: Day 1 “Welcome and how to install”, Day 2 “Tips for getting the most out of it”, Day 7 “How to ask for help.”
This page covers building an automation, the steps editor, the WooCommerce trigger, and what happens when an order is refunded or the automation is paused.
Table of Contents
Anatomy of an automation
Each automation has:
- Name — your reference, not shown to recipients
- Trigger — what event starts an enrolment (currently: WooCommerce purchase; extensible via filter)
- Trigger config — for WC purchases: a list of product IDs and a match mode (any / all)
- Category — the email category every step sends as. Almost always
onboarding. - Status —
activeorpaused - Steps — ordered list of email steps with a cumulative offset from the enrolment timestamp
Creating an automation
- Go to SSE Emails > Automations.
- Click Add New.
- Fill in the form: – Name — e.g. “Scalability Pro onboarding” – Trigger — pick “WooCommerce product purchased” (the only built-in trigger today) – Products — comma-separated product IDs the trigger should fire for – Match — Any of these products (default) or All of these products. Empty product list = match any purchase. – Category —
onboardingis the sensible default – Active — check to start enrolling; uncheck to pause (more on this below) - Save.
After saving, the Steps section appears on the same page.
Adding steps
Each step has:
- Days / hours — cumulative offset from the enrolment timestamp. Step 1 at Day 1 fires 24h after enrolment. Step 2 at Day 2 fires 48h after enrolment (not 24h after step 1).
- Subject — the email subject line
- Body (plain text) — the message body, with merge tag support
Click Add step to append a new row. Reorder by adjusting the offsets — steps are sorted in time order at send time.
A typical drip:
| Step | Offset | Subject |
|---|---|---|
| 1 | 1 day, 0 hours | Welcome to Scalability Pro — getting started |
| 2 | 2 days | Reviewing your site’s performance |
| 3 | 7 days | Help others speed up their sites |
Steps support these merge tags, resolved per-recipient at send time:
| Tag | Substitutes |
|---|---|
{{first_name}} | Billing first name from the triggering order, or subscriber first name |
{{last_name}} | Same for last name |
{{email}} | Subscriber email |
{{order_id}} | The WC order ID that triggered the enrolment |
How enrolment works
When a WooCommerce order moves to completed or processing:
- SSE looks at every active automation with
trigger_type = wc_product_purchased. - For each, it checks: does the order’s line-item product list match the automation’s trigger config? – any match: at least one of the configured product IDs is in the order – all match: every configured product ID is in the order – empty list + any: matches every purchase
- If matched, the customer is enrolled. If a subscriber row doesn’t exist for the billing email yet, one is created (with
source = wc_purchase,marketing_opt_in = 0— automations send asonboarding/product_support, which bypass marketing). - The enrolment row records the order context (order_id, products).
- The scheduler sets
next_send_at = enrolment_time + step_0_offset.
Idempotency: the same (automation, subscriber, order_id) combination is enrolled only once. If a webhook fires twice for the same order, only one enrolment is created.
What happens at tick time
Every minute, a cron event sse_automation_tick runs:
- Find all enrolments with
status = activeandnext_send_at <= now(). - For each, render the current step’s body with merge tags from the enrolment context.
- Call
sse_send()with the automation’s category and the rendered body. - Advance
current_stepby 1. - Set
next_send_at = enrolment_time + offset_of_step[current_step]. - If there are no more steps, mark the enrolment
complete.
The scheduler is robust to delays — if cron is late and three steps are now due for a single subscriber, only the current step fires that tick, and the next step is rescheduled normally. You won’t get three emails at once.
Cancelling enrolments
Three ways an enrolment ends without completing:
1. WooCommerce refund
When a WC order moves to refunded (via woocommerce_order_refunded hook), every active enrolment whose context.order_id matches that order is set to cancelled. Future steps are not sent.
This is the right behaviour for an onboarding drip — if they refunded, they’re no longer a customer, and emailing them “tips for week 2” is at best confusing, at worst harassment.
2. Automation paused
If you change the automation’s status from active to paused, the next tick will mark all in-flight enrolments cancelled. They will NOT auto-resume if you re-activate the automation later. This is deliberate: re-activation re-enrols newly qualifying purchases but doesn’t try to play catch-up on stale enrolments that might be confusing to receive months after the fact.
💡 If you want to temporarily stop new enrolments without cancelling in-flight ones, don’t pause the automation. Instead, change the trigger config (e.g. set the product list to a product ID that doesn’t exist). New orders won’t match; existing enrolments continue.
3. Subscriber globally suppressed
If a subscriber becomes globally suppressed mid-drip (hard bounce, complaint), the next step’s sse_send() returns a “skipped” result. The enrolment continues to advance through subsequent steps, which also get skipped. (This is intentional — if the bounce was a one-day issue and they re-engage, future steps can still go through.)
Extending: registering custom triggers
The trigger plumbing is filterable. Another plugin (e.g. ssp-product-renewals) can register a new trigger type:
add_filter( 'sse_automation_triggers', function( $triggers ) {
$triggers['renewal_due_t30'] = array(
'label' => 'Renewal due in 30 days',
'matcher' => 'my_plugin_match_renewal_t30', // callable
);
return $triggers;
} );
Your matcher decides which subscribers to enrol when an external event fires. Then enrol them programmatically:
SSE_Automation_Scheduler::enroll( $automation_id, $subscriber_id, array(
'order_id' => $order_id,
'renewal_due_at' => $due_date,
) );
SSE handles the rest of the lifecycle.
What automations do NOT do
- They don’t replace the newsletter. Newsletters are a different mechanism (see Newsletter).
- They don’t have branching logic. No “if customer clicked the previous email, send step 2A; otherwise 2B.” Just linear sequences.
- They don’t replace renewal email cadences. That’s
ssp-product-renewals‘s job. SSE provides the enrolment plumbing for it to plug into. - They don’t re-send to people who unsubscribed. Each step runs through the standard suppression gate at send time.
- Email Categories & Unsubscribes — which categories are right for which step
- Sending Campaigns — for one-off broadcasts instead of multi-step series
- WooCommerce Integration — how the purchase trigger ties into orders
- Tracking & Reporting — viewing each step’s delivery results