CRM SUPER ADMIN PORTAL

We launched the CRM desktop product in early 2019, and the MVP required the need for developers to create and delete accounts, and run various scripts to get different metrics to understand performance in those accounts. With the adoption of the tool by a flood of customers, we needed to remove the bottle necks to account creation, setup and onboarding. We did this by introducing a Super Admin portal that would give the Onboarding and Customer Service teams an interface and the tools to accomplish anything they needed without have to wait on a developer to be assigned.

By introducing this feature, we were able to cut down the onboarding times of new customer from multiple weeks to a few days. This cleared up the support queues, empowered client-facing team members, and left the developers to focus on other importing coding tasks. 

I was responsible for understanding the exact needs and functions we needed this portal to support, and designing that interface within the confines of our limited resources and timeline.

For the initial release the Super Admin portal needed to support:

• Creating new accounts
• Editing existing accounts
• Set accounts as active/inactive
• Associating a Vendor's account to an Agency
• Removing an Agency association from a Vendor's account
• Adding and editing users
• Resetting user's password
• Account specific Super Admin reports

Unlike many of the other projects I worked on for this product, I wasn't tasked with redesigning a feature, rather I was tasked with creating the initial version. Working with the PM and Senior Director of Development, we identified the underlying architecture that needed an interface built onto it. We researched where in the onboarding process the bottlenecks occurred due lack of OBM and CS empowerment and reliance on Developer action. These areas are what drove the requirement and acceptance criteria. Once this was defined, I was able to get to work on sketching the basic screens we would need. To create broader consistency in the product suite, I adopted design patterns used in Super Admin pages from our other tools.

One thing we heard over and over from our internal support teams, was confusion around different customers and what products they purchased, which sometimes affected how accounts were setup or the onboarding process that was followed. Often times it was hard to locate the original SOW detailing this information after-the-fact. Taking this into consideration, I knew we would need to somehow give users the ability to make note of the products purchased by the customer, to provide greater insight both in the onboarding stages and later support stages.  

In researching the volume of onboarding tickets that were created over a quarter, I also discovered additional tickets created at the same time for an initial Admin user to be created by the developers. In discussions with the developers, I learned that each account created needed at least one user associated for everything to function properly. That first user had to be created on the backend by a developer, just like the accounts needed to be created by a developer. Given this, I would be able to cut down at least 2 onboarding tickets for every customer sold if I also introduced the ability to create users in this Super Admin portal. 

The final research observation was the number of support tickets created asking for developers to run various scripts to provide metrics around orders coming into the account, exports going out, payment gateways connected, etc. For the most part, this was all information that existed in the actual accounts but not in a consolidated, easily consumable way. We would therefore need to create different reports so users could easily access this information for account health checks and to facilitate upsells and contract renewals. We would also need to show some of these high-level, bite-size pieces of information readily on the account's profile, so users didn't have to always dig through a report to glean that information.

Upon initial sign-in to the Super Admin Portal, I decided users would land directly on the Manage Accounts list. Here users could go directly to editing or adding a new account, which was the majority of the problem we were looking to solve. I decided to stick to design patterns that would be familiar to the user as shown across all products in the suite. Simplified searching and filtering made it easy for a user to find an account they wanted to work with, or easily start creating the new account. 

I introduced the idea of color coding the various agency tags that can be associated to an account to easily identify the different agencies a vendor might work with. By adding this information to the account list, as user would immediately have insight into the type of account and volume of activity that account should be involved with, without having the delve deeper into the account's profile, saving the user unnecessary clicks. 

I wanted both the last modified date and the account active status on the Manage Accounts listings as well, because understanding the last time an account was changed in some way and its active status are two key pieces of information for the CSM team when troubleshooting issues. If the CSM sees an account is inactive they can immediately get vital information about that account which ultimately saves time in the support ticket resolution process. The same goes for the last time the account was modified and its association to various agencies.

On the account creation page, based on the prior research, I knew we needed an area for users to select the products and modules purchased by the customer, as these items affected certain functionality available in the account itself, as well as the account's interaction with other products in the suite.  

Because of the volume of customers we were onboarding, and our push for shortened turn-around times, I didn't want to require more information than needed to create the account. Only three pieces of information would be required, to satisfy development needs, and only pertinent information could be added optionally. I made the create account form as targeted as possible to get only the necessary pieces of information. Additionally, I designed for the admin user (the one that is required on all new accounts) to be added automatically for each new account creation, so that the user wasn't having to do that step. This would save time for the OBM, and ensure the user was being setup in the proper way with the proper permissions, and the account would function as desired.

With this user flow we would cut down account creation times from 1-2 weeks (depending on developer availability and support queues) to less than 10 minutes, and removed the need for support tickets entirely. OBMs would now be able to create an account, perform any needed associations, and create users all in 10 minutes without any assistance. This was paramount to providing our Super Admin users with the power they needed to perform their jobs in the most efficient way possible. 

Once the account was created, users could access the account's profile. We used the same design pattern seen on the account creation page, but with more information listed as was available. It was important to have a summary dashboard feel, with key bits of information highlighted for CSMs to easily access. Much of this information could be found by logging into the account itself, but that would require precious time and knowledge of where to get said information. Other pieces of information, had previously only been available to developers in the database. I wanted to empower our CSMs and expose all pertinent information that would make their jobs easier and help us to both renew and extend contracts. Through research, we knew some of the regularly requested pieces of data, so I included them in the design to always display to the users. Again, cutting down the need for support tickets and slashing the time it would take to get valuable insight into account activity and health. From the account's profile you could now go to one place to see if import and export feeds were running and of their status, how many new customers and orders the account was receiving, and how many of those orders were using credit card payments. This was vital information being provided in a summary snapshot to anyone that needed it. We saw a marked decrease in internal support tickets, as we made the tool more and more autonomous. 

Finally, I explored the initial base reports that we would need to build into the Super Admin portal. Based on requirements provided by the PM and utilizing the design patterns already established in the product's reporting module, I designed a few options to display the complex data information. One option was filtering built directly into the header columns to both reduce vertical space and provide a more robust filtering of the data. However, with both time and development constraints, we opted to follow the filtering method we used elsewhere across the tool. One key change I introduced was color coding the change percentages of positive (green) and negative (red) to more easily digest what the data was reporting.

Initial feedback on the pages was positive, and its introduction certainly made the entire team more efficient. One thing we heard was the desire to see the associated suite products displayed on the Manage Account list, as we showed the associated agencies. We will also be monitoring support tickets to determine if there are additional pieces of data to highlight on the account profile page, or if any chose to show are providing less value that originally expected. 

As always, I worked with the development team to understand the limitations around exposing certain data. Originally I had designed more data charts and reports to be available directly on the profile pages, but doing so would have required a huge data lift and would likely have slowed down the pages, potentially hurting the efficiency we were shooting for. 

Since this project, we have started discussions around adding functionality to support the management of agency accounts separate to vendor accounts, as well as integrating reporting of API feeds as we begin to move away from the file-based data exchange.