If you’re like most Rails teams, your investment in your application’s email is probably getting short-changed. Rails does an amazing job making email easier, but it can only get you so far.
Do any of the following sound familiar?
- You’d like some help improving your email design and development workflows to work better for your team.
- You’d like to improve your automated testing of emails to catch issues faster and with less effort.
- Your team is slow to update emails because of a design, development, and testing workflow with too many dependencies.
- The rest of your application has automated tests and systems in place, but everybody dreads touching the emails for fear of breaking something.
- You’re unsure whether your deliverability is great or terrible.
- Your support team struggles to investigate reports of missing emails.
- Your support team regularly has to help customers who mistyped their email address, and now it’s bouncing.
- You’ve been thinking of switching away from your current transactional email provider but can’t find the development time.
- You want to upgrade your email templates to be accessible and responsive.
- You think your emails could use improved copywriting in the subjects, preheaders, or even the body.
- Your customers regularly encounter phishing scams created using your domain, but you’re not sure how to mitigate.
- When your transactional email provider has issues, your customers know before you do.
- You know the response time of your application to the millisecond, but you have no idea about your email delivery performance.
- You’d like to implement Gmail Inbox Actions but aren’t sure where to start.
- You’d like for your application to parse and handle inbound email through replies to your notifications but haven’t made time for it yet.
…or a variety of any other challenges with your transactional email. These are all solvable problems.
Email doesn’t have to suck. You and your customers deserve…
- Deep insight into delivery and the ability to easily identify and troubleshoot deliverability issues.
- Transparent status and monitoring tools to proactively detect deliverability issues before they’re widespread.
- Confidence that an email from your domain is from your application and not a scam.
- A rock-solid and enjoyable experience receiving, opening, and even replying to your email notifications regardless of device.
- Well-tested templates and a workflow that makes them as easy to udpate and test as the rest of your codebase.
- An email provider that cares as much or more than you do about your emails.
The end result?
You spend less time dealing with email and more time improving your product. The email side just works, and you get…
- A ton of email knowledge so your team is in a better place going forward.
- A seamless development workflow that works for your team.
- The best possible user experience for recipients of your emails.
- Happier customers with faster and more reliable delivery.
- Reduced support costs by proactively avoiding, detecting, and fixing issues before customers are affected.
- Quicker response times when deliverability issues arise.
- The ability to mitigate spammers and scammers abusing your domain.
- Improved ability to help customers when troubleshooting delivery issues.
Howdy. I'm Garrett Dimon, and I spent eight years building and supporting a Rails-based web application as a sole founder. That means I was the designer, developer, and support team for every aspect of our email delivery. After that, I spent four years working one of the best transactional email providers in the world.
I've written a guide to transactional email for Smashing Magazine, an article about senders, subjects, and preheaders for A List Apart, and a wide variety of transactional email guides for Postmark and even contributed to the migration guides.
Suffice it to say, I'm very familiar with Rails and email. However, while I specialize in email, it's not all about email. I wrote a book about building and running a SaaS application. I bring a holistic perspective and approach to ugprading your application's email. There's no one-size fits all, and we'll work together to customize a plan that works for you and your entire team.
If you're using Rails and sending transactional email, I'd love to help.
Interested or have questions?
Or, if you’re not sure, but you’d like to help in your own small way, I’d really appreciate it if you take this quick survey about how teams are working with Rails and email.