Devlog 1 - Stopping Replies to Notifications

As Wyatt mentioned in our first blog post, we tend to bike shed on things. One area that we like to spend a lot of time thinking about is what the user experience of a signature request should be. This is obviously a pretty critical part of the application, and—because we’re pretty new—it’s almost always the first experience someone has with Ream, so we want it to be a smooth, easy experience.

And the first interaction that someone has with our signature request flow is the email notification telling them that someone has requested their signature.

The Problem

The issue we’ve been seeing is that people are replying to the signature request notification, with their feedback (”Hey, there’s a typo in my last name, can you fix that?”, “I don’t understand the third clause, what does that mean?”). Which is a problem, because replies go to our internal notifications@reamdocs.com mailbox instead of being delivered to the sender.

Like most user behaviors, this makes perfect sense once we start looking at it.

First, they have no other real option—we don’t share the sender’s email address anywhere in the email. Furthermore, we didn’t implement comments in our signature requests (as we did for approvals and negotiations), in an attempt to simplify the signature request process as much as possible. We really tried to pare down the experience to just signing to reduce opportunities for confusion. This was too much, though. Now if the user had something they need changed, they don’t have any way share that.

Second, we’ve hinted that the email originally came from the sender. If the sender is John Doe, the email’s name comes across as “John Doe via Ream”, and in many clients may get truncated to just “John Doe…”. So it’s pretty natural to expect that if you reply, the reply would go back to John Doe.

Finally, we don’t provide a lot of context in this email. If you weren’t expecting to receive a signature request from John, you might not have any idea what this is and (currently) no ability to ask questions.

The “Easy” Fix

One easy solution that we could imagine is just changing the reply-to email address to the sender. This sounds nice, and would cleanly turn the desire path into a supported user flow in the application. The best way to make Ream feel seamless is to take advantage of natural behaviors.

So, update the reply-to and job done? Well, sadly, no. We’ve got to be a stick in the mud here, for the sake of security. The issue is that the original notification email contains a link that will let you sign the document. If the recipient replies to (or forwards) the email, the sender would receive the link in the quoted-text of the reply. The sender would then be able to sign the document on behalf of the recipient. We ask the recipient not to forward the email to anyone to prevent exactly this kind of impersonation.

Our Attempted Fix

The screenshot below shows our updated email. Let’s take a quick look at the ways we’re trying to address this. We’ve implemented the following changes, and will be monitoring over the next 30 days to determine whether we’ve had the desired impact.

Add Comments to Signature Requests

The biggest thing that this user behavior shows is that people are always going to have feedback that they need to share with the sender. When we first built Signature Requests, we tried to simplify it as much as possible, and we went too far. Clearly we need comments on signature requests, so we’ve added them.

(A) Remove Sender’s Name from "From"

We’re hoping because the email now comes from “Ream” instead of “John Doe via Ream”, that people will be less inclined to reply to the email.

(B) Add Sender Contact Information

We’ve added the sender’s email address into the body of the email. We’re hoping a user that really wants to contact the sender, but either doesn’t notice that they can leave a comment, has a technical issue with the site, or just wants to stay in their email inbox, at least has a way to contact the sender directly.

(C) Sender Descriptions

For Approvals and Negotiations, we’ve always allowed the Sender to optionally add a description that gets included in the email. We’re adding this to Signature Requests, in the hopes that a little bit more information about what this email is about will just reduce the number of questions that people need to ask.

(D) Explain how to comment

We implemented comments in signature requests, but it doesn’t do us much good if a recipient of the email doesn’t know that they exist. We’ve added a small bit of explanatory text to try and intercept a user who has a question, and direct them towards leaving a comment.

(E) Make the Call to Action Bigger

We made the “Review & Sign” button bigger. This is the primary action, and we want people to click it. Since we implemented comments, the sooner we can get people into the Signature Request and discover that there are comments, the better. This also helps with our primary use-case, of this notification email, which is actually signing a document. We really want people to click this button, so size++

(F) Add a “Do Not Reply” Message

We’ll start telling the users not to reply in the footer of the email. I’m not sure how effective this kind of message is, but hey, we might as well explicitly state our expectations.

Future Work

Eventually, we’d really like to get back to letting users reply to the notification email. We like the way Github deals with replies to pull request notification emails—it just becomes a comment on the pull request.

This is more than we want to tackle right now for the feature—we have a lot of other important functionality that we need to build and there are some real complexities and annoyances that come with parsing email replies.

So we’re definitely putting that into our backlog. At some point, we’ll setup our inbox to receive these replies, parse them, and turn them into comments on the signature request. Then we’ll have the best of both worlds—user’s getting to stay in their email inbox without exposing the link to the sender.