The 5 essential rules of SaaS email integration

Despite all the great user interface design we see on web applications today, one of the most important user interfaces for a SaaS product doesn't live in the browser and may have very little “design” to it at all.It's email. Yes, email!  That bothersome bit of technology we all were expecting to die years ago is far from going off the deep end.  Email is still the most important integration point for any web application.Somehow, while we developers were all trying to make our applications OAuth2-friendly so that we could fill our customer base with Twitterers and Facebook users, our customers still seemed to respond to the messages we sent through plain-old SMTP. Yes, that archaic, relatively insecure mechanism to transfer data from one server to its final resting place – an uncategorized mess of inter-office Fantasy Football messages, shipping confirmations, and pleas from Nigerian princes – is alive and oh-so-well.A report out last month from Custora showed that the rate of customer acquisition through email marketing campaigns on 86 different Realtor sites has risen from under a percentage point in 2010 to over 7% today. During that same period, Facebook and Twitter notifications barely registered a blip on the radar, and do worse than that other concept that should have died years ago: banner ads.

Email customer acquisition success rates vs. other media (courtesy: blog.custora.com)So what's going on exactly?  Well, the popularity of social connections like Twitter and Facebook has actually carved out the niche that email currently thrives under. Email has found its calling in the vast negative space between all these other vehicles of online communication: Namely, when stuff pertains to you and you don't feel the need to broadcast it to the world, you go through email.And, exactly what type of communication might fall into this category? Well, namely every kind of private communication on every kind of web-based software you might be using today.For instance, I don't want Basecamp messages or DoneDone updates going to my Facebook feed. Send them to my email inbox — my horribly curated list of messages that I will attend to because I know it's all stuff specific to me.On that topic, Twitter and Facebook also demonstrated something else: We actually can respond well to an infinitely scrollable list of things. A few years ago, we were all very worried about the cluttered inbox. Merlin Mann’s “Inbox Zero” battle-cry was a valiant order – one that I’m failing at miserably. My current inbox is 51,420 messages deep — yet, I still check this damned thing religiously.  So, while social networks seemed to spell the end for email, all it did was build the niche for email, and prove that we've adapted to consuming largely uncategorized lists of content.If you’re building a SaaS product, you must make email a cornerstone of the experience. That doesn't mean just sending software updates, payments, and other in-application updates through email. It also means that people can interact with your software solely through email. So, while you design a beautiful and compelling UI for your SaaS product, also keep in mind that email is a large piece of your interface too.

All social networking did was build the niche for email, and prove that we've adapted to consuming largely uncategorized lists of content.

So, here are the five essential considerations you need to make when integrating email into your SaaS product:

#1 - It’s a two-way street: Avoid the do-not-reply email at all costs

Many applications make email a read-only vehicle by setting the reply-to email address to something threatening (e.g. do-not-reply@myproduct.com). You’d be surprised how many people still reply to the email address.A far better alternative is to set the reply-to email address to, say, your support team. If a user really does have a question about their “forgot password” email, you'll be ready to respond.

#2 - Serious bonus points: Make replying-to-email an application feature

An even better alternative is to make replies to an email a feature of the application. For example, in DoneDone, when a user replies to a new issue notification in their inbox, the reply attaches a new comment to that issue.So, how do we know which email reply maps to which issue? Fortunately, an email document gives you plenty of mechanisms to embed information that your app can use to decide what to do:

• Use custom headers in your email creation (these start with “X-”). The RFC822 (“Standard for the Format of ARPA Internet Text messages”) notes that any header field beginning with “X-” would not be a part of any specific email standard. So, you could embed a custom GUID or public identifier that would reference back to the original item in your application. When the email is replied to, your app can grab that custom field value and know which item it maps back to.
• Derive a custom reply-to email address. As I stated above, many people don’t pay attention to the reply-to email address. So creating a human-readable reply address isn't all that important. An alternative to appending a public identifier in the email header is to simply create a dynamic email alias for each reply-able email (e.g. 02919203920@myproduct.com). Then, have all unrecognized email addresses forward to a general bucket where you can parse out the alias.
• Work off the user’s existing email address. You can also leverage the user’s email address on replies back to your server to verify who it’s coming from. For example, in DoneDone, we map the email address from the replier back to the issue they are replying to (grabbed from the original email’s reply-to email address) to verify the user exists in our database.

#3 - Don’t DIY: Offload email parsing to a third-party service

Now that you’ve built email as a feature of your application, how do you parse all of the replies clogging your inbox? One of the drawbacks of email is its lack of a real standard. JSON? Yeah right. XML? Not even.Writing software to parse email is a pain. Period. And when something is a pain, you let someone else do it. A company like Postmark takes care of all the parsing madness and ships off once-icky email documents into beautiful JSON objects. Postmark then shoots off the data to a webhook you provide back to your application.By handing off the email nastiness to a third-party, you can now focus your work on the product itself. How should the incoming email’s title and description map to your application? How do you want to treat incoming file attachments? What should happen after your email’s data is processed? Those are the questions you get to focus on by letting companies that parse and package email content for a living do the dirty work. Here’s a quick write-up on how we integrate with Postmark.

#4 - Who dat? Make sure you can instantly tell where the email is coming from

When we first integrated email replies into DoneDone, we made the mistake of displaying just the user’s first and last name in the email’s “from” name. So, if my business partner Craig sent me an issue, I’d get an email from Craig Bryant, mixed in with all the other emails Craig sends me about blog posts to read and dishes I haven’t washed in the company kitchen.We got a lot of the same feedback from our users - they had a hard time distinguishing between emails sent from DoneDone on behalf of a co-worker and emails sent directly from a co-worker.What did we do? We simply changed the email name from “Craig Bryant” to “Craig B. via DoneDone”. Having the “via DoneDone” bit at the end of the name rather than in the front also makes email lists incredibly easy to scan. This small change we made had a lasting impact.  No one's confused anymore.

A customized email "From" name makes it obvious where it's coming from.

#5 - Silver bullet or Sliver bullet: Don’t overcomplicate email integration

Finally, when considering what purpose email serves in your application, remember its limitations. Emails are very thin, lightweight documents that have titles, descriptions, attachments, one sender, and one or more receivers. Email replies going into your application should serve a very specific purpose.In DoneDone, replies add a comment and optional attachments to an issue, nothing more. We don’t let replies effect the status of an issue. We don’t let users change the priority or the fixer of an issue via email. We definitely don’t let you automatically upgrade or downgrade your subscription via email.Just as you might avoid complexity in your application’s UI, you also want to avoid complex syntax to support a bunch of features through email.In fact, our most complex integration with email in DoneDone is creating an issue. We’ve defined a specific structure to let users create issues, and assign fixers, and priorities. Otherwise, DoneDone makes default assumptions to avoid complicating the email syntax. We automatically make the tester the person who sends in the issue, and we don’t let folks add in tags or due dates through email.When defining what email does in your app, make it just a sliver – don’t overcomplicate what it does.

Email is the old man here to stay

If email had a smell, it would be an old musty cigar box –the kind your grandfather used to have by the side of his chair. But, as much as we’ve tried to take it out of its misery over the past decade, email is stronger than ever. And you owe it to your customers to make it a foundation of your SaaS product.Sign up for a DoneDone account in 30 seconds. Want to read more by Ka Wai Cheung? Ka Wai’s new book on the modern-day programmer, The Developer’s Code, is available in eBook and print. You can follow him on Twitter @developerscode.