SaaS Marketing Automation: Build These Four Triggers First

SaaS marketing automation is the set of messages your product sends because of what a user did inside it: signed up, reached the first useful result, went quiet, ran out of trial. The hard part is not picking a tool from a list of thirty. It is naming the one event that means a user got value, then hanging every trigger and every exit condition off that name.

The four triggers worth building first

Start by naming one activation event: the smallest action inside your product that means this person got what they came for. Not a login, not a click. The first invoice sent, the first page published, the first API call that returned data. With that name in hand, four triggers cover almost everything a one-person SaaS needs.

Signed up, not activated. Fires 24 hours after signup if the activation event has not happened. Exits the moment it does. This is the message that pays for the whole setup: it reaches people who are still interested and still stuck.

Activated for the first time. Fires on the first activation event, once per account ever, so the send is its own exit. Its job is to name the next thing worth doing, not to congratulate.

Activated, then quiet. Fires when an activated account has had no session for seven days, and exits on any session. Build it last: seven days is a placeholder until you have watched real usage, and a weekly reporting tool has a very different normal gap from a daily inbox tool.

Trial about to end. Fires from billing, three days out. Exits when a payment method is attached.

Write each exit condition before the first line of copy. A trigger without an exit is how someone gets a "you have not tried this yet" email an hour after they tried it, one of the eight failures marketing automation for ecommerce produces when a solo store skips the same step.

These four collide in one place. On a 14 day trial, an account that went quiet on day 4 hits the dormancy trigger and the trial-ending trigger on the same day. Suppress dormancy while a trial is running and let the billing message go alone, or cap the whole set at one automated email per account per day.

Where each trigger actually comes from

Two of the four come from your billing provider. Two can only come from your product.

Stripe sends customer.subscription.trial_will_end three days before a trial ends, and triggers it immediately if the trial is shorter than that. The subscription webhook reference documents that offset as three days; the renewal equivalent, invoice.upcoming, is the one whose lead time you set in the dashboard. So if you want to reach people at day 7 of a 14 day trial, billing will not do it for you. You schedule that one yourself.

The end of the trial is a fork worth configuring. For a free trial with no card on file, trial_settings.end_behavior.missing_payment_method decides whether the subscription pauses or cancels, which is the difference between customer.subscription.paused and customer.subscription.deleted reaching your endpoint, as Stripe's trial documentation sets out. Pick pause if you want the account recoverable, then write the recovery email against that event.

Activation and silence exist nowhere but in your own product, so you emit them. PostHog is where I would start: the free tier covers 1 million analytics events a month with no card required (pricing, checked September 2026). An event on every page view burns that down; events on the few actions that decide anything will not.

If you cannot add a line of code to the action that matters, the first three triggers are out of reach whatever you pay for email: one more reason to start with the repo you already own when you choose what your product sits on.

“

The hard part is not picking the tool. It is naming the one event that means a user finally got value.

”

Getting the event into the email tool

The email tool has to hear about the event. In Loops that is one request, and the events documentation gives the minimal payload:

POST https://app.loops.so/api/v1/events/send

{
  "email": "user@example.com",
  "eventName": "firstInvoiceSent"
}

You then set a workflow trigger to "Event received" and pick that name. The free plan runs to 1,000 subscribed contacts and 4,000 emails in a rolling 30 day window (pricing, checked September 2026).

Check one thing on day one. Your product knows a user by an internal id; your email tool keys on an address. Loops accepts email or userId and creates a contact when neither matches, so a mismatch still fires the event, just against a fresh contact instead of the user you meant. Send a real event, open the contact it landed on, confirm it is the right one.

The email that matters most, written out

The unactivated signup is the message worth writing by hand. The example below uses a made-up invoicing product called Ledgerlike; the name, the blocking step and the signature are placeholders, not something I measured.

Subject: your first invoice is three fields away

You made a Ledgerlike account yesterday and stopped before sending anything.

It is usually the same wall: we ask for a business address before the first
invoice, and people go looking for the exact legal one. Any address works,
and you can change it later under Settings, Business details.

If it was something else that stopped you, hit reply and tell me what you
ran into. I read these myself.

Dana
Ledgerlike

Four things do the work, and none of them are the writing. It names the action the person did not finish. It gives one unblocking instruction instead of a tour. It asks something answerable in a line. And it comes from an address that accepts replies, so you need somewhere for replies to land and a way to stop the sequence when one arrives.

Change the product name, the wall itself, the menu path and the signature. If you do not know your wall yet, that is the email to send: one line asking what stopped them beats a guess dressed up as onboarding.

The rule that keeps these honest is the one behind following up on a cold email: send when you can add something the reader did not have, not when a timer runs out. A lifecycle email that only reports that four days passed is a reminder, and reminders are what people mute.

When not to build any of this

While you can still read every signup of the week in one sitting, send that first message by hand. Ten typed replies teach you the wall faster than a sequence will, and the moment it flips is not a user count, it is the week you stop opening the list.

One product shape breaks the plan outright: where there is no gap between signing up and getting value, because the first action is the value, triggers one and two collapse into a single message. And automation aimed at people who have not signed up at all, posts and comments and replies, runs on a different trigger entirely, closer to what ReadyToPost handles.

FAQ

Which tool should a solo founder pick? The one that accepts an arbitrary event from your backend and starts a workflow from it. That rules out most list-based senders and rules in the event-based ones. Check the free tier against your contact count, and fire a test event before you commit.

Do I need a product analytics tool as well? Not to ship the first three triggers. You can send the activation event straight from your backend to your email tool this week. Analytics earns its place when you want to ask which first-week actions predict a paid conversion instead of deciding that by hand.