Automations

This page covers the emails that go out on their own. Use it to set up a welcome series, a thank-you email two days after a purchase, or a reminder for subscribers who have not opened an email in three months.

An automation runs a sequence of steps when a subscriber signs up, makes a purchase or receives a tag. For example: wait two days, send the welcome email, wait until Tuesday morning, send the second email, add a tag, then finish. Each subscriber progresses independently. Review the steps carefully before activating an automation, since it may run unattended for months.

Before you begin

• A list with confirmed people on it, and a working From address.
• The worker running every minute. Automations run on the tick.
• kahunacart.newsletters.manage to write one, and kahunacart.newsletters.send to turn it on.

Start from a recipe

The add-on includes three ready-made automations with steps, waits, subjects and email bodies. Use Start from a recipe on the Automations screen to create a draft.

Recipes create drafts. Sending, enrolment and discount-code generation begin only after you activate the automation.

Welcome series

The series sends three emails during the first week after a subscriber confirms their address: an immediate welcome, answers to common questions two days later, and a first-order offer three days after that. Subscribers leave the automation when they make a purchase.

Before you switch it on. The third email is a placeholder, so write the offer into it or take the email out. Review the second email and update it to reflect your shipping and returns policies. On a store without double opt-in, subscribers do not confirm their addresses. Change the trigger to When somebody joins a list so the automation can enrol them.

After somebody buys

A thank you the day after an order completes, and a week later a note asking how it went.

It runs once per person rather than once per order, so a regular customer is thanked the first time and left alone afterwards. Core already sends the confirmation and the receipt for every order.

On a store that already asks for reviews. If reviews.request_after_days is above zero, KahunaCart is already emailing customers asking for a review, and this recipe leaves its own review email out. That is decided once, when the draft is written. If you turn core's review request on after creating this automation, take its second email out yourself or both will go.

Before you switch it on. Sign the thank you as a person rather than as the shop. Point the second one at wherever you collect reviews.

Win somebody back

One email carrying a discount code of its own, sent to anybody you tag win-back. Tagging them starts it, and the recipe makes the win-back tag for you if the store does not have it.

Each person gets a code minted for them alone at the moment their email is built.

Before you switch it on. Check what the group gives away, because every person tagged gets one code from it. Write the offer into the email in your own words. Consider narrowing it with a segment so somebody tagged by mistake is still left alone.

Write one

1. Go to Newsletters → Automations and click Write an automation.
2. Enter a name.
3. Pick the one trigger that starts it, and fill in the picker if that trigger reveals one.
4. Optionally narrow it with a list, a segment, or both.
5. Configure the two switches described below.
6. Add the steps, in order.
7. Click Save.

The automation is saved as a draft and does not enrol subscribers yet.

The ten triggers

Two of them reveal a picker: which tag, or which product. The tag is a select of the store's own tags rather than a text box, so a typo cannot make an automation that never fires.

The three subscription triggers do nothing on a store without the Subscriptions add-on. An automation using one of these triggers cannot enrol subscribers without that add-on.

The two switches

Let somebody go through this more than once is off by default. Keep it off for a welcome series; enable it when subscribers should be allowed to enrol again.

Take somebody out as soon as they buy something stops the rest of the emails the moment an order completes. Turn it on for anything trying to talk somebody into buying.

Who is allowed in

Four rules, and they apply to a trigger and to the Enrol somebody button equally.

They have to be mailable. Subscribed, and nothing else: never pending, never unsubscribed, never bounced, never complained, never on the suppression list. On a store with double opt-in, a welcome series on the subscribed trigger would mail nobody, so use confirmed there.

They have to be on the automation's list, when it names one, with a real subscribed membership.

They have to match the automation's segment, when it names one. The segment is asked about that one person rather than counted over the store.

They have to be new to it. By default, a subscriber can enrol only once, regardless of how the previous enrolment ended. Resubscribing twice does not trigger three welcome series. An automation can allow re-entry, but a subscriber cannot enrol again while their current enrolment is active.

The six kinds of step

Steps are numbered from one, and those are the numbers a branch names. A branch before any email step, or after one that could not be sent, takes the "no" branch.

The steps are an ordered list of cards. Every card moves up and down and can be removed. A step with active subscribers cannot be removed; the disabled button shows how many subscribers are at that step.

The email step

A step's email is a subject, a preheader, Markdown and a layout, with the same merge tags and the same preview a campaign has. Once the automation has been saved, Refresh the preview renders that email through the real layout with a sample subscriber.

Behind it there is one campaign row with kind = flow on it. A flow's mail uses the same renderer, open pixel, click redirect, UTM parameters, unsubscribe headers and email log as a campaign. It never appears on the Campaigns screen, is never scheduled, and is never "the last campaign" on the Overview.

A flow's email reaches each person once. A subscriber who re-enters the automation progresses through its steps but does not receive the same message again. The same unique key that stops a campaign mailing anybody twice enforces it.

An email step that hands out a discount code

An email step can carry config_json.coupon_group, the name of a coupon group as it reads on the Coupons screen. A number there is read as a group id instead.

When it is set, the step draws one code for that one person as their message is written, through the same generator the Coupons screen's own Generate button calls. The message reads it as {{ coupon.code }}, and {{ coupon.url }} is a link to the shop that applies it.

One code per person, and never two. The code is drawn inside the same transaction as the send row, so a redelivered tick mints nothing and a failed step rolls the code back.

When there is no code to give. A group that does not exist, a group somebody switched off, or a group whose pattern has no room left all end the same way: that one person leaves the automation with failed against their name and a line in the Grav log naming the group, and nothing is mailed.

Nothing is minted when an automation is written, saved or created from a recipe.

Waits, weekdays and the store clock

A duration-based wait lasts for the specified interval: two days means two full days.

A wait until a weekday and an hour is answered on the store's own clock: reports.timezone in the KahunaCart settings, falling back to Grav's system.timezone and then to UTC. "Tuesday at nine" means nine in the morning where the shop is, including on the week the clocks change.

A weekday wait reached at exactly its target time waits until the following week. Somebody reaching a "wait until Tuesday at nine" step at exactly nine on a Tuesday waits for the next one.

Turn it on

Turn it on starts the automation from that moment. Past trigger events do not enrol subscribers retroactively.

Pause stops progress and new enrolments. Resume continues each subscriber from their current step. If a wait expired during the pause, the subscriber advances on the next tick.

Deleting is blocked while subscribers are still active, and the message shows how many remain. The confirmation prompt offers to delete it anyway, removing those subscribers with the reason the automation was deleted. This cannot be undone.

Edits to a running automation apply to active subscribers from their current step. Saving a step with its existing id preserves its row, so fixing a typo in step four does not restart a subscriber who is three days into the series.

Read one automation

The top of the screen shows four counts: moving, waiting, finished and left. The last count also shows the most common exit reason.

Steps shows the numbered sequence. Each email step displays sent, opened and clicked counts and rates, plus a button to open its campaign.

People lists all past and current enrolments with their status, such as "Waiting until Tue 9:00 AM at step 3". The list is paginated and filterable by status, and shows the reason for each exit. Enrol somebody lets you find a subscriber by name or address and enrol them manually, subject to the same four rules. You can remove a subscriber who is still moving or waiting from their row.

Why somebody stops walking

Exit on purchase applies whatever the automation listens for. A purchase takes people out before it puts anybody in, so a store running a welcome series with "leave when they buy" and a post-purchase thank-you gets the purchase ending the first and starting the second, in that order.

The mailable checks run before every step rather than at the moment the status changed. An unsubscribe, a bounce or a complaint that arrived by any route takes them out of every automation, and the worst case is that the screen catches up a minute later. Nothing is sent to them in the meantime.

The tick, and what "within a minute" means

Automations run on the worker. A tick is queued at most once a minute, and two workers whose runs overlap queue one between them.

One tick moves each person by exactly one step. So an automation whose first three steps are a tag, a tag and an email takes three minutes to reach the email. A wait of two days is over within a minute of two days, and a welcome email "sent immediately" arrives a minute or two after the signup.

One tick takes on at most automations.per_tick people (200 by default). A run that hits that number queues itself again straight away, so a store that has just switched an automation on with eight thousand people already qualifying drains in a few minutes.

A step that throws takes that one person out of that one automation with failed against their name and a line in the Grav log, and the tick carries on with the next person.

Setting automations.enabled to false pauses all automations: ticks stop being queued and processed, enrolments remain intact, and subscribers resume from their current step when it is enabled again. Use it while moving a store or changing a transport.

What is not here, and why

No visual canvas. Automations use an editable list of steps with at most one branch.

No nested branches. A branch jumps to a step, then execution continues through the remaining steps in order.

No conditional waits. A wait is a length of time or a weekday and an hour. To wait on an event, write a second automation on the trigger for that event.

Related

• Campaigns
• Segments
• Subscribers, lists and tags
• Settings reference
• Developers
• Coupons
• Subscriptions
• Cart recovery