Configuration

Sekvo is configured on one screen at WooCommerce > Follow-ups, available to anyone with the manage_woocommerce capability (shop managers included). Everything is stored in a single option, followup_settings: a global sender plus a block per email type. Saved values are merged over the packaged defaults, so a partially-saved type still has every field.

Sender

Applies to every message Sekvo sends.

• From name, the sender name shown in the inbox. Stored as from_name. Blank falls back to your site name (get_bloginfo('name')); the field placeholder shows the current fallback.
• From email, the From / reply-to address. Stored as from_email, validated with is_email on save (an invalid value is discarded, not stored). Blank falls back to the site admin email. Use an address on your own domain so messages pass SPF/DKIM.

Sekvo sends through wp_mail, so any SMTP or transactional-email plugin you run handles delivery automatically.

The two email types

Sekvo ships two types, both enabled by default:

Type	Default trigger	Default delay	Purpose
Thank-you	Completed	1 day	A short note after the order is fulfilled
Review request	Completed	7 days	Asks for a review once the product is in use

Each type stores its settings under followup_settings['emails'][<type>] where the type key is thank_you or review.

Per-type settings

Send this email (enabled)

The per-type switch. When off, the type is never scheduled or sent. You can run only one type or both.

Trigger status (status)

The WooCommerce order status that schedules the email. The dropdown lists every status registered on your store (via wc_get_order_statuses, with the wc- prefix stripped), so it adapts to custom statuses. Defaults to completed. If a saved status no longer exists, Sekvo falls back to the type’s default status.

Delay (days) (delay)

Whole days to wait after the order reaches the trigger status. 0 sends on the next daily run. The field accepts 0 to 3650; values are clamped to that range on save.

How the delay is measured is worth knowing precisely: Sekvo compares each order’s last-modified date against now - delay days. It does not record the exact moment an order entered the trigger status. In practice the last-modified date moves when the status changes, so the delay is honoured, and the rule is conservative, so an email never sends earlier than the delay. An order edited after it reaches the trigger status resets this clock, which can push the follow-up later.

Subject (subject) and Body (body)

Plain-text templates. Subject is sanitised with sanitize_text_field, body with sanitize_textarea_field. Leave either blank to fall back to the packaged default text for that type. Both support the tokens below; a token in the subject (e.g. the customer’s name) is fine.

Tokens

Replaced per order immediately before sending:

{customer}  the order's billing first name; "there" if it is empty
{order}     the order number, prefixed with # (e.g. #1234)
{site}      your site name

There are no other tokens. An unknown token is left in the text verbatim.

How sending works

A daily wp-cron event, followup_daily_event, drives everything:

• For each enabled type it queries up to 200 orders per run that are in the trigger status, old enough by the delay, and not yet sent this follow-up.
• Orders placed before the plugin was activated are never picked up. Activation stores that moment in the followup_install_floor option, so switching the plugin on in a shop with years of orders behind it does not mail those customers. Deactivating and activating again does not move the floor.
• It marks the send against the order (_followup_sent_<type> meta) before calling wp_mail, then sends, then replaces the mark with the send timestamp. If wp_mail returns false, it removes the mark so the order retries on the next run. This claim-then-send order is why a crash mid-run cannot produce a duplicate.
• A send that never returns at all, a PHP fatal error or a script timeout inside wp_mail, leaves the mark in its unfinished state. The next run recognises it, retries that order once, and then leaves it alone, so one crash neither loses the follow-up silently nor mails the customer every day.
• An order with no valid billing email, or a type whose subject or body renders empty, is skipped.

The event is scheduled an hour after activation and re-scheduled on admin_init if it goes missing, so an update without re-activation does not stop the emails.

What is fixed by design

• Plain-text only. Bodies send as plain text. (Pro turns them into branded HTML through the followup/mail filter, see Building a sequence.)
• One send per order per type, enforced by the per-order meta flag.
• No shortcodes and no front-end output. Sekvo is entirely back-office plus email; it renders nothing on the storefront.

Storage and cleanup

Settings live in the followup_settings option; a schema marker in followup_db_version. Deleting the plugin deletes both options. The per-order _followup_sent_<type> meta is not removed on uninstall (it is harmless order metadata). Everything stays in your own database, Sekvo contacts no external service.

Related

• Getting started, install and test a send.
• Building a sequence, timing, copy and the followup/mail filter.
• FAQ, cron, duplicates, deliverability.