Posts Tagged email

Fixing our email issues

Wednesday, February 3rd, 2010

Subscription billing is a pain and we’re trying to make your life easier by simplifying it for you. Well, it turns out that email is also a pain and we’re turning to someone else for help.

Recently, there’s been a high amount of email support requests. We spool mail locally from our web application to Postfix, then deliver it out to the internet. Well, it turns out that a large amount of that email was getting dropped. Watching the postfix mail logs was a bit disheartening after seeing numerous mail servers refuse to chat with our email server. We have SPF records setup, reverse DNS, and deliver mail from a dedicated IP address — it turns out that that’s still not enough.

To our customers: I’m sorry we didn’t figure this out earlier. We haven’t done a good job delivering our billing emails to your customers. Right now, we are evaluating multiple ways to improve the email delivery rates for the emails we send to your subscribers on your behalf. There should be an immediate uptick in the delivery rate for your emails today. And over the next couple weeks, we’ll determine the best way to reliably deliver your emails with the correct domain keys, SPF records, etc so that they work even better than if you were to send the emails yourself.

To other start-ups: I hope you read this and then realize that running your own SMTP server on dedicated, non cloud-based servers can still be problematic. I thought that because we’re not in the cloud, we don’t need someone else to handle our emails — looks like I was wrong. To remedy the situation, we’re now evaluating SendGrid (shout out to another CEO named Isaac). I’ve heard great things about their service and I’ve been comparing email headers all evening. It looks like their product is doing a fantastic job handling bounced emails, invalid email addresses, ISP feedback loops, domain keys (something we didn’t have setup), SPF, and everything else. Their web UI is a little rough around the edges, but so far it looks promising. Assuming their product lives up to its marketing material, it will help us dramatically improve our email reliability.

We’re not email experts and we don’t have time to build it out ourselves — (this sounds so familiar, right?).

Once again, a big thanks to everyone for being patient as we improve our email issues.

How to maximize your yearly subscription renewals

Friday, January 29th, 2010

This past week, I’ve heard from multiple customers who offer yearly subscriptions. They took the easy route and implemented it with one time transactions — in other words, the subscription is valid for a year and then never renews. When they find out about Recurly, sometimes they want to simulate that behavior and not have the subscription renew because that’s what their customers are used to. While Recurly can do that, there’s a better way to maximize your renewal rate (or retention rate) and still keep your customers happy.

If your users forget about your service during the year and then they see the yearly renewal on their statement, they’re going to remember your service… and not in a good way. Worse yet, they might want their money back. That usually means they’ll ask you for a refund (and you should be willing to issue it if they really haven’t used the service) or they’ll attempt a charge-back (and that sucks for you and your bank account).

So right before the yearly subscription renews, remind your users two weeks ahead of time about the upcoming charge. This gives them plenty of time to opt-out of the subscription. It also gives you a chance to remind them of the value you provide so they will continue paying for the service. It’s just that easy to keep everyone happy and make more money.

And yes, Recurly will be adding this feature before your yearly subscriptions get close to expiration.


Links