Automations & Onboarding Drips

Dave Hilditch

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.


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.
  • Statusactive or paused
  • Steps — ordered list of email steps with a cumulative offset from the enrolment timestamp

Creating an automation

  1. Go to SSE Emails > Automations.
  2. Click Add New.
  3. 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 – MatchAny of these products (default) or All of these products. Empty product list = match any purchase. – Categoryonboarding is the sensible default – Active — check to start enrolling; uncheck to pause (more on this below)
  4. 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:

StepOffsetSubject
11 day, 0 hoursWelcome to Scalability Pro — getting started
22 daysReviewing your site’s performance
37 daysHelp others speed up their sites

Merge tags in steps

Steps support these merge tags, resolved per-recipient at send time:

TagSubstitutes
{{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:

  1. SSE looks at every active automation with trigger_type = wc_product_purchased.
  2. 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
  3. 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 as onboarding/product_support, which bypass marketing).
  4. The enrolment row records the order context (order_id, products).
  5. 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:

  1. Find all enrolments with status = active and next_send_at <= now().
  2. For each, render the current step’s body with merge tags from the enrolment context.
  3. Call sse_send() with the automation’s category and the rendered body.
  4. Advance current_step by 1.
  5. Set next_send_at = enrolment_time + offset_of_step[current_step].
  6. 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.

Related

Leave a Reply

Your email address will not be published. Required fields are marked *

×
1/1