Streamlining user deactivations to decrease customer support requests.

Role:

Product Designer

Team:

Product Manager, Engineers, and QA

User Management

SaaS

B2B

High fidelity design of the new deactivate user feature.

Background

Staffbase Email, a product of the Staffbase employee platform, is designed to provide users with tools for creating, sending, and tracking email metrics. While the platform offers intuitive self-management, the process for deactivating users has historically required customer support intervention.

Problem

Administrators on the platform often need to deactivate users for various reasons. However, the process is inefficient, as it requires them to submit a request to their account manager and often entails multiple follow-ups. User interviews and discussions with the engineering team revealed that this lengthy process was primarily due to the risk of losing important resources, requiring customer support assistance for recreation.

Solution:

Streamlined the process of sending from different email addresses by creating a system for managing email aliases, introduced alias sharing to enhance team collaboration, and improved access to email metrics by utilizing existing user permissions and sharing frameworks.

Problem:

While the product aims to enhance internal communication, the collaborative aspects of sending emails and viewing metrics became inefficient when involving multiple users, leading to support requests, decreased productivity, and fragmented email metrics.

Solution

  • Empower admin users to independently deactivate users within their organization without contacting customer support.

  • Ensure essential assets remain accessible by automatically transferring all resources owned by the deactivated user to the admin executing the deactivation.

Impact

  • The streamlined deactivation process significantly decreased the number of support requests related to user deactivations and resource recoveries.

  • Admin users gained greater autonomy while ensuring that their resources remain accessible, which is especially crucial for scheduled email communications.

  • The feature was released to production within a two-month timeframe, thanks to ongoing collaboration with stakeholders and the engineering team.

Key design solutions

Transferring resources

When an Admin user deactivates another user, a confirmation will display to let them know that resources owned by the user will be transferred to the Admin to ensure resources stay accessible to other users.

High fidelity design of the new deactivate user feature.

Scheduled emails

Admins are notified of any upcoming emails scheduled by the user being deactivated. This visibility empowers them to proactively manage and oversee the organization’s communications, ensuring that essential adjustments can be made as needed to maintain seamless workflows.

High fidelity design showing drafts scheduled for sending by the user being deactivated.

how can we make sending from different email addresses simple?

As I mapped the existing user flows I found that the current system inhibits collaboration and transparency.

Before (partial snapshot of userflow):

To send an email from a specific address, users need to navigate to the Team page and log in as that "user" if their account allows for that, if not then they'll need to log out of their account and manually log in with the credentials of that user.

Slice of user flow (before) for selecting a different email address to send from.

After (full userflow):

The process of navigating to the Team page is removed, the internal communicator will select the alias (sender email address) directly on the Email Preview/Send page instead.

User flow (after) of sending from a selected email address.

Future Iterations

While the solution significantly enhances the user management system, insights from user interviews indicated a strong interest in increasing resource flexibility. The designs below have been created to support future enhancements if the project is reprioritized.

Scheduled emails

Admins are notified of any upcoming emails scheduled by the user being deactivated. This visibility empowers them to proactively manage and oversee the organization’s communications, ensuring that essential adjustments can be made as needed to maintain seamless workflows.





Pain points:
- Requires customer support assistance: Users cannot deactivate accounts themselves, requests must go through the account manager.
- Inaccessible shared resources: When a user is deactivated, all resources (i.e. templates, drafts, lists) they own become inaccessible, even if shared with others in the organization.

These inefficiencies hindered productivity of our end users and increased requests to customer support.

To uncover the root cause, I discussed the issue with the engineering team:
- Each resource in the database is linked to an owner ID, defaulting to the user who created it.
- When that user becomes deactivated, that piece of resource cannot be surfaced since it is tied to that user.
- Removing the owner ID from the database is complex and could require a system overhaul, increasing the project’s scope.

High fidelity design showing drafts scheduled for sending by the user being deactivated.

Want to learn more about my design process?

let's connect

Other considerations:

Currently, all existing customers have their aliases created as a user. To make this transition from "user" to "alias" as seamless as possible for our users these are the steps that we'll need:

  1. CSM/AE of each customer account will fill out a csv template with their current users created for alias purposes.

  2. Send to our internal alias transition slack channel.

  3. Engineer team uploads the csv file into our database to convert those users to aliases.