Guiding Account Admins

Project timeline: 7 business days

Company: Yesware — a sales tool that helps users get prospect, schedule meetings, send email campaigns, and follow up with their clients.

My role & responsibilities: (Sole) Product designer handling problem research, concept development, and collaboration with engineering

Platforms: Desktop browser using Gmail & Outlook email platforms

Goal: Significantly reduce the number of support tickets automatically generated when an Account Admin attempts to remove a user who cannot be deleted because (s)he is the last leader of a team.

Constraints: There is a business logic in place that requires each team to have at least one ‘Team Leader’ or ‘Team Administrator’.

Impact: After this improvement was implemented, weekly support tickets decreased by 16% (approx 20 per week).

Product context & terminology

There are three roles involved in this product feature and will be mentioned throughout this project:

• Account Admin — This is a role within the Yesware product which manages the users in their account and the account billing.
  
• Team — Within an account, a number of teams can be created.
  
• Team Roles — Within each team, there are three roles that exist: Member, Team Leader, and Administrator. The roles determine the level of permissions the user has throughout the product features.

The Happy Path

For an Account Admin looking to remove a user from the account (eg. if the user has left the company), he or she would:

1. Navigate to the Users section in the appsite
   
2. Find the user’s name in the list of users
   
3. Tick the checkbox next to said user’s name
   
4. Click the 'Remove' button
   
5. Observe the modal (shown below)
   
6. Click 'Remove'
   
7. Observe a success message saying that user was successfully removed
   

So, what’s the problem that generated hundreds of weekly support tickets?

There is a Yesware business logic in place that requires each team to have at least one user designated as “Team Leader” or “Team Administrator.”

It is important to note that the reasoning for the requirement is so that a team consisting only of "Team Members" can’t essentially lock themselves out of the team. However, this adds a layer of complexity when a single user needs to be removed from an account and is the only Team Leader of one or more teams.

To make things more complicated, what if the Account Admin needed to remove multiple users — some of which are the only Team Leader of multiple teams?

Referring to the UI abstraction above, because the team roles aren't listed in the Users list view, you also can't see which teams only have one Team Leader or Team Administrator.

That means that whenever the Account Admin is removing users, they'll potentially get blocked by the business logic validation. More frustratingly, they have no idea why certain users can be successfully removed and why some cannot.

The deeper I dug, the more issues I found.

To get more background with the issue, I spoke to the Customer Support Team at Yesware, to get an idea of how much more complicated the current issue was.

Each time an Account Admin clicks the “Remove” button that leads to an error, they receive an automated email letting them know that an error has happened, but not why. It's quite common to try an average of 3–5 times before giving up. With each failed instance, a customer support ticket is automatically generated and then added to the queue.

Secondly, once the Account Admin realizes that they’d been charged for the seats they thought they had removed previously, the Yesware finance team would to intervene to sort out the billing.

Thirdly, the current validation in the backend processes the removal of users sequentially. What that means is once there is an error in the user list during the removal process, it will stop at that point in the list.

Looking UI abstraction example below — let's say we need to remove User #1, User #3, User, #4. If the backend hits an error on User #3, the removal process will end there and User #4 will not be removed.

Solutioning

After weighing four potential options with the Customer Support Team, the Product Manager, and Engineering, we arrived at solution that balanced feasibility and added user value.

This solution would:

• Surface which users can't be removed
• State why those users can't be removed
• List where the teams the user is a Team Lead
  

By providing these additional levels of insight, the Account Admin can understand why and which users cannot be removed and take the appropriate actions to successfully remove users.

The business and user impact

Because this issue had spanned multiple years, it is really a time saver for both the Yesware Customer Support Team and our users. Our users are directly provided the information around which users and team roles need to be reassigned before removal. Gone are the days where they get false positive success messages, vague error emails, and sit around waiting for a response from the support team.

The Yesware Customer Support Manager and Finance Manager were both thrilled to announce that just a month after this improvement was implemented, weekly support tickets decreased by 16% (average of 23 per week). ?