Automated User Emails: Post-Purchase User Journey

Situation

Licenses for our educational SaaS were often purchased at the district level, then assigned to individual schools. Once the licenses were assigned to schools, users at the schools had to be added to the license.

There were two user roles associated with these actions. “Administrators” had permission to add or remove users or change their roles. “Teachers” taught the programs to students, or, in the case of the professional learning program, were individual users.

One of the many things that confused clients about this system was that the system roles were named after roles that already existed in the schools. “Administrators” weren’t necessarily school or district admins. They were staff who were designated administrators of the software. And “Teachers” were not necessarily classroom teachers, because the programs were often taught to kids by counselors or other staff.

Once licenses were assigned to schools, automated emails would go out explaining to users that they’d been granted access to the program and how to create an account. Other automated emails would tell users when their program role had changed or they’d lost access.

Tasks and Actions

The original emails were very long, because stakeholders felt that it was important to provide a lot of context in case schools or districts hadn’t been great about communicating to staff about what was going on. Although these emails were well-intentioned, they were a wall of words that few people would read, and the CTA was buried in unnecessary information. My tasks were to rewrite and shorten them without losing any crucial information and to make it clear what actions the user needed to take.

One of our UX designers mocked up a new template with the old (long) email copy, and I cut them down significantly.

Below are some examples with explanations. Images should enlarge when you select them.

“Access-Granting” Emails

Below are comps of emails intended to inform users that they’ve been added to their school’s license(s), and what role they were given.

Rationales

  • There was a lot of discussion about the subject lines. What would get people to open them and not view them as spam?
  • Getting rid of 80 percent of the text allowed us to make the CTA button large and easy to see.
  • Adding the name of the person who granted access was important so the recipient knew who to go to if the link didn’t work and also had some confidence it wasn’t spam or could find out it wasn’t. 
  • In cases where a school was using more than one of our programs, it seemed necessary to list them out in case the user was unaware. 

“Teacher” Access

“Administrator” Access

The information about who added this person is cut off, but I couldn’t get a better image.

“Your Access Was Updated” Emails

The next emails went out when a school or district Administrator or one of the org’s client support people changed a user’s permissions role.

Rationales

  • Since these emails were often ignored and sometimes ended up in spam folders, we wrote a clear subject line that got right to the point of the email.
  • It was important to tell the user what their new superpowers were, since they may never have held this role before, which is why the “You can now” paragraph is there.
  • In this case, the person receiving the email hadn’t created an account when they still had Teacher permissions, so they need to create an account. Most people changing from Teacher to Administrator would already have an account, so they’d have a “Log In” button.
  • As with the access-granting emails, we wanted them to know who changed their permissions in case there were problems. 

“Access Removed” Email

This email went out when license access was removed for some reason. The user may have left the school or stopped teaching the program.

Rationales

  • We wanted the user to know there was a change in access, but we also wanted to be able to repurpose parts of this email, so we used the less alarming, less-specific “access has changed” head. 
  • We wanted them to know who removed them. In this case, our support team removed them on behalf of their school leaders, so we also needed to tell them to talk to their Admin if they thought it was a mistake. 

Results

Our user testing groups indicated that the emails were clear and easy to understand. Client support staff reported fewer user questions about license roles. Metrics were not available yet at the time of my departure.