When to Send Transactional Emails: A SaaS Timing Guide

Your SaaS has its emails planned. Now each one needs a moment to go out. A welcome email that turns up an hour late feels broken. A trial reminder sent on the day the trial ends feels like a trap. Most timing problems come down to one question: is this email instant or timed?

This guide covers when to send transactional emails in a typical SaaS: which go out instantly, which wait for a set time, and which should check before they send. Transactional emails are the one-to-one messages your product sends about someone's own account, such as sign-up confirmations, password resets, receipts and reminders. You'll also get the exact messages to send Claude Code, and a way to check the timing works.

Which transactional emails should go out instantly?

Any email the person is waiting for should go out within seconds of them acting. That covers sign-up and verification emails, password resets, receipts and team invites.

A quick test: did the person do something, and are they now looking at their inbox? If so, it's instant. Someone who asked for a password reset may sit refreshing their inbox until it lands. A delay there doesn't only annoy them; it stops them using your product.

Some instant emails exist for safety. OWASP, a widely used source of web security guidance, recommends emailing people once their password has been changed, so they'd notice if it wasn't them. It also says reset links should work only once and expire after a set period. A reset email that arrives late may already be useless.

Other instant emails start outside your SaaS. If you take payments with Stripe, Stripe sends your project a webhook when a payment succeeds or fails: an automatic message one service sends another when something happens. Your receipt or payment failed email goes out the moment that message arrives. The guide to sending your own emails after a Stripe payment covers this in more detail.

Which emails should be timed?

Timed emails go out at a set point after something happened, or before something is due. In a typical SaaS, that means a day 3 check-in, a trial ending reminder, a renewal reminder and regular summaries.

There are two ways to count:

• Forward from a start, such as "3 days after sign-up".
• Back from a deadline, such as "3 days before the trial ends".

For deadlines, Stripe can do the counting. By default, Stripe tells your project 3 days before a trial ends, and you can change the number of days in Stripe's settings. For renewals, Stripe sends a similar notice a few days ahead, based on its Upcoming renewal events setting. Stripe can also send its own trial reminder emails 7 days before a trial ends. If you switch those on, pick one reminder so people don't get two. The trial ending email guide covers what to say.

Every timed email should check before it sends. A "finish setting up" email shouldn't reach someone who finished on day 1, and a trial reminder shouldn't reach someone who has already upgraded.

What does a timing plan for a typical SaaS look like?

Here's a starting point. Adjust it to the emails your SaaS sends; the 12 transactional emails every SaaS needs covers what goes in each one.

Stripe defaults checked October 2026. For a longer welcome sequence, see onboarding emails for your SaaS.

How do you tell Claude Code when each email should go?

Describe the timing the way you'd brief a colleague: what sets the email off, how long to wait, and when to skip it. Claude Code builds that timing into your project.

For an instant email:

The password reset email needs to arrive within seconds of someone asking for it. Make the link work once and expire after an hour, and send a short "your password was changed" email once they've reset it.

For a timed email:

Three days after someone signs up, send them a short check-in email, but only if they haven't created their first project yet. Send it in the morning, their time, if we know their time zone.

Or hand over the whole plan at once:

Here's when I'd like each of our emails to go out: [paste your timing table]. Check it against how our SaaS works, flag anything that doesn't fit, and wait for my OK before building.

Timed emails run on a scheduled job: a small task your hosting runs at set times, also called a cron job. Each run finds who's due an email and sends it. On Vercel's free Hobby plan, scheduled jobs can run once a day and may start any time within the hour you choose; the Pro plan runs them to the minute. Vercel uses UTC, a standard world time, so ask Claude Code to convert from your local time. A daily job suits "3 days after" emails. Instant emails never wait for a schedule. How to automate emails with Claude Code explains scheduled jobs in more detail.

Once your project is live, real emails go out from the project itself through your email service, not from the chat. For the full journey from planning to live emails, see transactional emails in Claude Code.

How do you check the timing works?

Test instant emails by doing the action yourself. Test timed emails by shortening the wait for a while.

1. Time the instant emails. Sign up with your own address, ask for a password reset and invite a teammate. Each email should arrive within seconds.
2. Shorten the timed ones. Waiting three days to see a check-in isn't practical:

In a test version of the project, make the day 3 check-in and the trial ending email send after 2 minutes instead of days, so I can see them arrive. Then put the real timings back and tell me when that's done.

3. Test the skip rules. Create a test user who has already finished setup or upgraded, and confirm they don't get the email meant for everyone else.
4. Check after launch. With SimpleSends connected, Claude Code can read your send logs and delivery status, so you can ask in plain English:

Did yesterday's day 3 check-in emails go out? Tell me how many sent and whether any failed or bounced.

If a whole batch is missing, the scheduled job may not have run at all. The guide to checking whether your emails actually sent walks through that.

How do you adjust timing later?

Send Claude Code a message. Timing lives in your project, so changing it is a brief, not a dashboard task.

Common changes include moving a check-in from day 3 to day 2, sending annual plan renewal reminders earlier, or switching a weekly summary from Monday to Friday. One thing to watch: if you change Stripe's number of days, tell Claude Code too, so wording like "ends in 3 days" still matches.

Our trial reminder feels too late. Move it to 7 days before the trial ends, update the wording so the number of days matches, and tell me what else changes.

To change wording or design rather than timing, see how to update your SaaS emails by asking Claude Code.