Logging Emails With HubSpot Sales

Background

HubSpot is a platform for sales, marketing, and customer success. HubSpot Sales is a Chrome extension that allows salespeople to access sales acceleration tools from Gmail and access data from their CRM. Two key features of the extension include:

• Email tracking: This alerted salespeople when their prospects engaged with their emails.

• Logging emails: This allowed salespeople to forward a record of their conversation to their CRM.

At the start of this project, we saw users express confusion between these two features as exhibited in support tickets and bug reports, The goal of this project was to improve the usability of these two features.

Users

Salespeople who had the HubSpot Sales Chrome extension installed.

Desk Research

To empathize with and start understanding users, I dug into a channels of customer feedback, including:

User Interviews

I sought to understand how much of the user pain originated from a comprehension issue (the UI failed to communicate how the features worked) or a feature issue (users were unsatisfied with the functionality of the features). This was accomplished with interviews w/ 5 HubSpot users and 3 non-HubSpot users.

Research Goals

1. Understand what users want to accomplish with logging and tracking as well as if the current functionality meets their expectations.

2. Understand how users expect log and track to works.

User interviews

Participants

• 5 weekly active users who are salespeople

• 3 non customers who are not salespeople

Format

Part 1: Exploratory question (20 minutes)

• Tell us about the last time you used the “track” feature

• Tell us about the last time you used the “log” feature

• If you think about these two functionalities, how would you describe their relationship? Are they two very distinct functionalities? Two sides of the same coin? Is one more or less useful than the other?

• How did you set these features up? How often do you change their settings?

Part 2: Effect and Cause Exercise (20 minutes)

To dig into “How do users expect log and track to work in the current UI?,” I showed participants activities in the CRM and had them identify if the activity originated from:

• Tracking the email from the extension

• Logging the email from the extension

• Logging and tracking the email from the extension

• Not from the extension

This identified areas where the UI was unclear in communicating the impact of the extension on the CRM.

Part 3: Scenario Exercise (20 minutes)

To dig into “How do users want log and track to work?,“ I showed the participants different email scenarios and asked them how they would use the log and track tools in each scenario. I wanted to see:

• Did participants prefer to track some emails and not others?

• How did users want the emails logged in the CRM? Did this vary depending on the email?

• Was the extension capable of meeting participants expectations in each scenario?

I included a mix of work emails and personal emails in the scenarios because we heard users express frustration that the extension was sending their personal emails into their company CRM and wanted to understand if this was a common scenario for the participants.

Key learnings from research

1. Both customers and non-customers successfully articulate different values in the two features, and these values aligned with functionality.

• Tracking emails provides short-term value for participants:

  • Helps them “understand what is landing and not landing” by seeing what email content results in opens and clicks

  • Tells them which prospects and clients to pay attention to based on how they engage with an email.

  • Informs them how and when to engage with their prospects and clients.

• Logging emails provides long-term values for participants and their team:

  • Automates data entry by creating a copy of their email in the CRM

  • Create a “paper trail” of previous interactions to discuss with their team.

  • Informs team members in other departments how to engage with a contact.

  • Gives participants “peace of mind” that they did their job by sending an email.

2. Users often mixed up the terms “log” and “track.”

In the effect and cause exercise, participants mixed up the terms “log” and “track.” For example, they might say an activity came from “tracking” an email and then continue to describe the log feature. This was interesting because the same participants were able to articulate the value of each feature when talking about them separately in the first part of the interview. In the UI, the features are represented as checkboxes that sit next to each other. This signaled that there was an opportunity to improve the content design or even placements of the features in the UI.

3. Participants engage different with the log feature based on the email

In the scenario exercise, participants engaged with the log feature differently based on the email they were sending. For example, for emails to prospects, most participants wanted the email logged in the CRM so the rest of their team could see it. However, for personal emails, most participants were strongly against the email getting logged because it could potentially cause embarrassment in front of their peers. When it came to emails sent within their company, participants were split on this. There were some emails users wanted logged (example: an email to finance about a customer’s billing question) and other they didn’t want logged (example: an email to their manager about performance related to a deal). This variance signaled that users needed more control over the log functionality than what was available in the UI.

Problem Definition / Solution

How might we improve logging so that users feel like they have more control over the feature as indicated by a decrease in Support tickets related to logging and improved customer satisfaction around logging?

Based on NPS comments, support cases, and round of user interviews above, we narrowed in on a usability issue with the “log” feature: While this feature did add value to users, it failed to meet two usability heuristics:

1. Visibility of system status: Although “log” and “track” present very different values to users, the UI does little to differentiate the two features. Both are represented as checkbox controls. Some key information the “log” checkbox did not communicate is where in the CRM the users would find their logged records. For example, we often got support tickets about unexpected contacts getting created in the CRM. This was because the extension would try to find a contact in the CRM that matched the email address of recipients on the logged email. If it couldn’t, it would create new contacts — a behavior the UI did not communicate anywhere.

2. Flexibility and efficiency of use: Although the extension tried to be helpful with smart logic around where it would log emails in the CRM, the interviews and feature requests proved that users wanted to have more control over the log feature based on the email they were sending. For example, if the recipient of the email has multiple deals open in the CRM, the extension would log the email to all of the deals. This was a large source of user pain because it had downstream effects on creating noise in customers’ CRM and messing up reporting based on email activity.

To solve this user pain, we decided to tackle and expand on this feature request: Select which Deal to log an email to when a contact is associated with multiple Deals. The solution would:

• Expose the logic the extension used for logging emails.

• Allow users to override the logic by selecting/unselecting which contacts, companies, and deals in the CRM they want the email to log to.

Usability Testing

I moderated 8 usability tests w/ participants sources from high usage tracking and the feature request post.

Improvements made after usability testing

1. Searching for records changed from a dropdown to a side panel:

2. Settings added to help users set better defaults For example, users who had lots of deals in the CRM wanted deals unchecked by default in favor of checking off which deals to log the email to.

3. Onboarding flow designed due to the perceived large change in functionality

Rollout / Design Tradeoffs

At the time this was written (May 2020), I was moved to another project, and this feature was in an open beta. The product manager and I had agreed that the beta would:

• Include the onboarding to educate users on the new feature

• Allow users to see the log logic and update it

Some of the tradeoffs I made with product management and engineering in order to get the beta out faster included:

• Excluding the post-send experience that allowed users to update which records the email logged to.

• Excluding the side panel for search: We agreed it was more important to get the feature out to a few users and revisit this post-beta.

• The placement of the “log” and “track” controls. I originally designed the controls closer to the “Send” button so users would not miss it. However, this presented a huge engineering risk due to potential conflict w/ Gmail’s toolbar. In favor of a more sustainable approach. I moved the controls to the toolbar below the subject line of the email.