Customer Support & Case Management System

by on

I worked as part of a 2-person designer/developer team to conceptualize, design, and build a tool for case and user management to be used when providing customer support.

Please note: the information displayed in this case study has been significantly altered to adhere to confidentiality agreements.

Project Overview

We inherited a system that was created to be a front end for accessing and editing the info in the database. We were to to not only tighten up the existing user interface, but also create and seamlessly integrate new and much-needed features. Additionally, we had the challenge of making huge improvements while making sure that little-to-no training would be required of the agents in order to be able to use the new system.

Research

Since the users of this system were our own agents, I was able to get a few of them to sit down and speak with me about their thoughts on the platform as it currently stood. A few patterns emerged from their responses:

  • The process and interface for modifying existing customer data was severely cluttered. Many commonly used features were hidden away, and many rarely used or misunderstood features were taking up space front and center.
  • New agents had to deal with even more of a learning curve because the language used in this platform was not intuitive. For example: a field that determined whether a plan was a monthly or annual plan was a text field named “Payment Interval” and could only take the values “0”, “1”, “9”, and “12”.
  • While on a call, an agent had to switch into another application to confirm the name/phone number of the call they were currently on. There was no way to view that information inside the platform.

To The Drawing Board

With this information in hand, we were able to start whiteboarding potential solutions to the agents’ problems. Besides the interface, we were also able to use the whiteboards to figure out a better way to describe features and actions within the platform. It was as this point that we had some spirited debates about why certain names don’t work for certain actions and why certain words weren’t scalable or logical for descriptions.

Building

While mocking up, prototyping, building and testing this system, we found ourselves constantly returning to the whiteboard to hash out even the most minute details. Either we’d get some more requirements dropped upon us part-way through or we’d recognize the shortcomings in our original planned approach and needed to come up with a better solution before building too much more of it. But all of this constant building and iterating eventually yielded a product that solved the agents’ problems, required little training, and was delivered on time.

Features of this system include:

  • An interface to search for cases, and to filter the results by various parameters, such as creation date, priority, status, etc.
  • A case detail page, including the ability to add notes (and highlight important ones), upload attachments, listen to past phone calls associated with the case, etc. Because an agent may not have the luxury of being able to enter the info in a particular order, (such as when new info becomes available mid-process) this screen has all of the fields contained on one page with a sticky navigation bar at the top to help jump to sections out of order.
  • The ability to create and manage case types, including adding custom fields.
  • A way to search for users and entities, complete with an interface to facilitate the clear display of info and ability to filter.
  • A page to display all of the information about a particular user, included any policies purchased, account notes, records of communication, and shortcuts to help make it easier for the agents to make changes to the account. Due to the large amount of information that needs to be easily accessible to agents while on a call, it’s all displayed on one screen, but with the ability expand and collapse sections as needed.

Some Sample Screenshots:

User Entity Search
User/Entity Search Screen The original screen was split into 2 – a user search and an entity search. Because sometimes an agent didn’t know whether they wanted to search for a user or an entity, we combined them into 1 screen that gave the agent more flexibility and saved them more time through better sorted results and shortcuts to the actions they would commonly want to take next.
Case Screen
Sample Case Detail Screen – This screen needed to have all of the pertinent info about a case accessible in one place. The associated account, any associated files, past phone call data, notes unique to the case, and fields unique to the case type.
User Details - Expanded
Sample User Details Screen – All Sections Expanded – Another screen where an agent would have needed access to a lot of info at once. This screen houses the user info, any policies associated with that user, and the policy details. This particular screen shows the screen fully expanded, should the agent prefer to use it that way.
User Details Collapsed
User Details Screen – Most Sections Collapsed – Version of the previous screen, but with most sections collapsed. This is the view most agents would use to get to the information they need to find by expanding the correct section(s).