Use case
Automating Trial Expiration Reminder Emails
Convert more free trials into paying customers with well-timed, automated reminders.
Use case
Convert more free trials into paying customers with well-timed, automated reminders.
Most SaaS free trials end with a whimper. The user signs up, pokes around for a day or two, gets busy, and forgets about your product until the "your trial has expired" email arrives — by which point they've moved on. Industry benchmarks put average trial-to-paid conversion at 15-25% for opt-out trials (credit card required) and 2-5% for opt-in trials (no card upfront). The gap between average and best-in-class is almost entirely down to what happens during the trial.
Well-timed reminder emails serve two purposes: they re-engage users who've gone quiet, and they create urgency for active users who haven't committed yet. A user who receives a "3 days left" email and has been actively using your product is far more likely to convert than one who discovers their trial expired two weeks ago.
The economics are compelling. Acquiring a trial signup typically costs $20-100+ in B2B SaaS. If automated reminders improve conversion by even 2-3 percentage points, that's thousands in recovered revenue per month for a mid-size SaaS. And unlike most growth tactics, the implementation is a one-time effort with compounding returns.
There's no universal sequence, but a four-email cadence works well for a standard 14-day trial. Each email serves a different psychological purpose:
Not technically a "reminder," but it sets the tone. The goal is to get the user to their first moment of value as fast as possible. Point them to the single most important action — not a feature tour, not a 20-minute onboarding video, but the one thing that will make them think "okay, this is useful." For a project management tool, that's creating their first project. For an analytics tool, that's connecting their data source.
By day 7, users have either found value or they haven't. For active users, highlight features they haven't tried yet — ideally ones correlated with conversion. For inactive users, this is your re-engagement play: acknowledge they've been busy, reiterate the core value prop, and make it easy to jump back in with a single click.
Two days before expiration. This is where you introduce the deadline explicitly: "Your trial ends in 2 days." For active users, summarize what they've accomplished and what they'd lose. For inactive users, offer a trial extension or a quick call. The conversion rate on this email is typically 2-3x higher than the day 7 email because loss aversion is a powerful motivator.
Sent on expiration day or the day after. For users who haven't converted: a last chance offer (discount, extended trial, downgrade to a limited free plan). Keep it short. If they haven't engaged with three previous emails, a long pitch won't help. For users who converted during the trial, this email should obviously be suppressed.
The exact timing depends on your trial length and product complexity. A 30-day trial might have 6-7 touchpoints. A 7-day trial should have no more than 3. The principle is the same: guide early, re-engage mid-trial, create urgency at the end.
The most common approach: a scheduled command runs periodically, queries the database for trials that match each reminder condition, and sends the appropriate emails. In Laravel, this looks like:
// app/Console/Commands/SendTrialReminders.php
class SendTrialReminders extends Command
{
protected $signature = 'trials:send-reminders';
public function handle(): void
{
$this->sendDayOneWelcome();
$this->sendMidTrialTips();
$this->sendUrgencyReminder();
$this->sendExpirationNotice();
}
private function sendUrgencyReminder(): void
{
$users = User::query()
->where('trial_ends_at', '>', now())
->where('trial_ends_at', '<=', now()->addDays(2))
->where('subscribed', false)
->whereNull('urgency_reminder_sent_at')
->get();
foreach ($users as $user) {
Mail::to($user)->send(new TrialUrgencyReminder($user));
$user->update(['urgency_reminder_sent_at' => now()]);
}
}
// ... similar methods for other emails
}
// In routes/console.php or Kernel
Schedule::command('trials:send-reminders')->hourly();This is straightforward and works within your existing stack. Every Laravel, Rails, or Django app already has a scheduler. The downside is that it's polling-based: you're querying the database every hour for users who might need an email. At small scale this is fine. At 100k+ trials, the query gets expensive and the batch processing can create email delivery spikes that hit rate limits.
There's also a timing precision issue. If your command runs hourly, a user whose trial expires at 2:15 PM might not get their "expires today" email until 3:00 PM. For most use cases this doesn't matter, but it's worth understanding the trade-off.
Instead of polling, you publish events when a user signs up, and downstream consumers schedule the appropriate emails. This inverts the control flow: instead of asking "who needs an email right now?", you say "when this user signed up, schedule these four emails."
The implementation typically involves a message broker (RabbitMQ, Amazon SQS, Google Pub/Sub)
and consumer workers. When a user signs up, you publish a trial.started event.
A consumer picks it up and enqueues four delayed messages — one for each reminder.
This is architecturally clean but operationally complex. You need to run and monitor the broker, manage consumer processes, handle message acknowledgment and dead letter queues, and deal with the eventual consistency implications. If a user upgrades mid-trial, you need to cancel the remaining reminder messages — which is non-trivial with most message brokers since queued messages aren't easily addressable.
Platforms like Intercom, Customer.io, and ActiveCampaign are built for exactly this kind of lifecycle messaging. You define a "trial user" segment, build a multi-step campaign with time delays, and the platform handles scheduling, delivery, and analytics.
The advantages are real: visual campaign builders, A/B testing, engagement tracking, and suppression rules are all built in. The disadvantages are equally real: these platforms start at $50-100/month and scale with your contact list. Customer.io, for example, charges based on tracked profiles — at 25k users, you're looking at $150+/month just for the messaging layer.
There's also a control issue. Your reminder logic lives in a third-party platform, which means your engineering team needs to context-switch between code and a campaign builder. Conditional logic that's trivial in code (e.g., "only send this if the user has created at least one project but hasn't invited a teammate") often requires awkward workarounds in visual builders, or syncing custom event data into the platform.
At signup time, enqueue four delayed jobs — one per reminder email — with the appropriate delays. This is event-driven (no polling) and uses infrastructure many teams already have:
# Ruby + Sidekiq example
class TrialReminderWorker
include Sidekiq::Worker
def perform(user_id, reminder_type)
user = User.find(user_id)
return if user.subscribed? || user.trial_reminders_disabled?
case reminder_type
when "welcome"
TrialMailer.welcome(user).deliver_now
when "mid_trial"
TrialMailer.mid_trial_tips(user).deliver_now
when "urgency"
TrialMailer.urgency(user).deliver_now
when "expired"
TrialMailer.expired(user).deliver_now
end
end
end
# Called at signup
def schedule_trial_reminders(user)
TrialReminderWorker.perform_in(1.hour, user.id, "welcome")
TrialReminderWorker.perform_in(7.days, user.id, "mid_trial")
TrialReminderWorker.perform_in(12.days, user.id, "urgency")
TrialReminderWorker.perform_in(14.days, user.id, "expired")
end
This is clean and each job checks current state before sending (the return if user.subscribed?
guard), so early conversions are handled gracefully. The requirement is that you're already running
Sidekiq (or Celery, or BullMQ) — if not, setting up Redis plus worker processes just for trial
emails is a significant operational commitment.
One subtle issue: if your Sidekiq process restarts or Redis loses data, scheduled jobs may be lost. Redis persistence (RDB/AOF) mitigates this, but it's another configuration detail to get right.
HTTP scheduling services like Recuro let you schedule an HTTP callback at a specific time. At signup, your backend makes API calls to schedule each reminder:
// Node.js example — called during user registration
async function scheduleTrialReminders(user) {
const reminders = [
{ type: "welcome", delay: 3600 }, // 1 hour
{ type: "mid_trial", delay: 604800 }, // 7 days
{ type: "urgency", delay: 1036800 }, // 12 days
{ type: "expired", delay: 1209600 }, // 14 days
];
for (const reminder of reminders) {
await fetch("https://api.recurohq.com/api/jobs", {
method: "POST",
headers: {
"Authorization": "Bearer YOUR_RECURO_TOKEN",
"Content-Type": "application/json",
},
body: JSON.stringify({
queue: "trial-reminders",
url: "https://yourapp.com/webhooks/trial-reminder",
method: "POST",
headers: {
"Authorization": "Bearer YOUR_INTERNAL_SECRET",
"Content-Type": "application/json",
},
payload: {
user_id: user.id,
reminder_type: reminder.type,
},
delay: reminder.delay,
}),
});
}
}
Your app exposes a /webhooks/trial-reminder endpoint that receives the callback,
checks whether the user has already converted, and sends the appropriate email if not. The
scheduler handles the timing, retries on failure, and provides visibility into what's been
sent and what failed.
This approach eliminates polling, doesn't require queue infrastructure, and the scheduling happens at signup time so there's no batch processing. The trade-off is an external dependency — your reminder delivery depends on the scheduler service being available. For most teams, this is an acceptable trade-off given the reduction in operational complexity.
A user who logged in 6 times in the first week needs a different message than one who signed up and never came back. At minimum, split your reminders into "active" and "inactive" variants. Active users should hear about advanced features and team collaboration. Inactive users need a simpler re-engagement pitch — what's the single fastest way to see value?
Track a few key activation metrics (created first X, invited teammate, connected integration) and reference them in your emails. "You've already created 3 projects — here's how to automate your workflow" is dramatically more effective than a generic feature list.
Most teams A/B test subject lines and email copy, which is fine but low-leverage. The higher-impact test is timing. Does day 10 outperform day 12 for the urgency email? Does a 5-day trial with faster cadence convert better than a 14-day trial with spread-out emails? These structural tests require more patience but yield more significant insights.
If you offer multiple plans, tailor the reminder to the plan the user is most likely to convert to. A solo developer trialing your tool probably doesn't care about enterprise SSO. A team lead with 5 invited members doesn't care about the solo plan pricing. Use trial behavior to infer the right plan and frame the conversion CTA accordingly.
The highest-converting trial emails often come from a real person (or appear to). An email from "Sarah, Head of Customer Success" with a plain-text format and a genuine offer to help outperforms a polished HTML marketing email in many B2B contexts. Consider making at least one email in your sequence feel personal — a reply to that email should land in an actual inbox.
Not every trial user is ready to pay. Instead of a binary "subscribe or lose access," offer a free tier, a discounted first month, or a trial extension. The goal is to keep the user in your ecosystem. A user on a free plan today is a paying customer next quarter. A user who churns at trial expiration is gone.
Don't just measure whether your reminders are "working." Track specific metrics that inform optimization:
| Approach | Best for | Watch out for |
|---|---|---|
| Cron + DB polling | Small-medium apps with existing scheduler | Timing imprecision, batch query cost at scale |
| Message queues (SQS, RabbitMQ) | Event-driven architectures already using a broker | Operational complexity, hard to cancel queued messages |
| Marketing automation | Non-technical teams, complex multi-channel campaigns | Cost scales with contacts, logic lives outside codebase |
| Task queues (Sidekiq, Celery) | Teams already running queue workers | Redis persistence risks, infra overhead if starting fresh |
| HTTP schedulers (Recuro, etc.) | Event-driven scheduling without queue infrastructure | External dependency, requires webhook endpoint |
The implementation matters less than getting the sequence right. Start with whatever approach fits your current stack, measure the results, and iterate on timing and content. A mediocre reminder system that's actually running beats a perfect architecture that's still on your roadmap.
Recuro handles scheduling, retries, alerts, and execution logs. 1,000 free requests to start.
No credit card required