Lifecycle emails

Hi,

@patio11 's talk at MicroConf inspired me to dedicate some time to improving LiberWriter’s emails. I think our users should be pretty receptive to those techniques, with a bit of modification.

About the first thing I ran into is that I have a confirmation email. Should I also make that be the welcome email, or should that be a second one? Seems excessive, but like Patrick said, what we want in terms of email communications is not necessarily what the average person wants or responds well to. I don’t really have the volume of people nor the time to test it at the time being. Any advice or experience?

Thanks!

I don’t know about “should” or what works best. But for (my) ease, I send a confirmation email, and then a separate “welcome” email, within a few minutes of the user submitting their email address.

My whole email structure is as follows:

Day 0: “Welcome” and a tip for new users, all in one email, to begin the conversation.
Day 7: “Have you tried feature X? It’s really popular” email. The real aim of this is to remind users who downloaded my software then forgot about it to take another look.
Day 14: “Did you know you customise feature Y in lots of way?” email
Day 21: “Some hidden features” email
Day 28: “Your trial is almost over, write to me with any feedback.” email

I think it works pretty well. The open rate is high for all of them, but does drop off with each email (except the “hidden features” one… which out-performs the previous email).

1 Like

I hope you are not sending Day 7 email to everyone, just the customers who haven’t used feature X… And that you only send the Day 14 mail to customer who are actually using the feature Y.

One thing I hate is to get lifecycle emails that advertise/recommend a feature that I’m already using.

They give me the impression that:
A. Sender’s lifecycle email system is broken, you should know what I did or didn’t do -> low quality sw
B. Sender doesn’t care that my time is wasted -> the sw probably doesn’t optimize for my time usage (or usability) either

In both cases, my perception of your app quality will be lower - even though I logically know that the messaging system quality doesn’t have direct connection to your app quality.

1 Like

I hope you are not sending Day 7 email to everyone, just the
customers who haven’t used feature X

That would be nice…but it is desktop software, and the tracking and integration required to do this is something I’m not motivated to do. Good point though.

A little thing that worked well for me in “your trial is about to expire email” - I just do this:

Your trial period ends on XXX (around midnight UTC), at which point your credit-card will be billed.
If you need more time to decide though, reply to this email and we’ll gladly extend your trial!

It allows people that have interest in the product yet did not actually had the time to use it, to stay longer.

I once extended a trial for one month or so.

I track the usage as well via intercom.io custom data.

1 Like

Steve, I think your approach is just fine for desktop apps - people have different expectations for them.

I think that with desktop apps many people still consider targeted emails as spying and might not appreciate customization. With web apps, it’s more natural that the app tracks what you do.