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).
There are three roles involved in this product feature and will be mentioned throughout this project:
For an Account Admin looking to remove a user from the account (eg. if the user has left the company), he or she would:
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.
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.
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:
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.
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). ?