Support Console
Optimizing Customer-Facing Support Workflows
My Role
I served as product designer for this project. All screens here are my original designs.
The direct development team included ~5 engineers and a product manager. Work was organized in an Agile framework with three-week sprints. Strategy was coordinated by myself and my product manager.
Impact
Challenge
Customer-facing employees were losing valuable time navigating across multiple tools; Zendesk, Salesforce, internal systems, spreadsheets, to find basic account information. This fragmented experience led to shaky handoffs, double work, and slow ticket resolution times, which ultimately risked customer churn.
Solution
Create a single internal touchpoint where support teams could find everything they need, fast.
Features
Customer & Location Information
Interactions
Process
This was one of the first projects I worked on at Ceterus, and it had even come up during my interview process. Since I hadn’t been formally onboarded, I was learning on the fly—figuring out our development process, understanding how operations worked, and getting to know my teammates. As a result, the research phase was less structured and lacked strong quantitative data, both of which I would improve later in my time there.
Discovery + Research
This feature was originally proposed after a newer executive spent time shadowing several customer service representatives. They observed that the growing volume of support tickets and slow response times were major contributors to customer churn. Improving this workflow was identified as the next logical step for strengthening this part of the business.
With that direction, my product manager and I conducted additional research through user interviews, our own shadowing sessions, and an analysis of support tickets. We started initially with trying to understand the nature of our support tickets, but quickly hit a road block upon seeing that most support tickets were simply labeled as “accounting”. Due to limited tracking tools at the time, this made our quantitative data unreliable. Taking that into account, we shifted our focus toward qualitative research through user interviews and focus groups.
A few possible support ticket problems and the steps taken to resolve them
From those sessions, we uncovered some of our biggest insights: shaky handoffs, double work, and most notably, scattered information. Internal users often had to jump between four to five different applications just to find basic location details—sometimes even referencing manually updated Excel sheets. And that didn’t include the actual accounting or bookkeeping data.
Design
With a better understanding of the information that is required for most support tickets, we aimed to provide that critical information in one place and give users the quick links to related internal and external applications.
For the MVP, the main priority was consolidating key customer and location information. At the time, information was spread across multiple systems; Assembly and Administration (two internal applications), Zendesk, Salesforce, Asana, Excel and QuickBooks Online. That doesn’t even account for the specific pages within each application where the information might live. With a rough idea of what was needed, we shared an early prototype to internal users and our development team.
Early on, I tossed out the idea of allowing users to search by either customer or location, since the customer name might not always be relevant depending on the user’s role. However, due to technical constraints, only one flow could be supported without significantly increasing development costs. The gain in efficiency there would not be enough to offset the development cost, so we opted for a customer-based search that would allow users to select from their associated locations. The consolation here was that our component for customer search allowed users to search by email and customer id as well so it wasn’t too restrictive.
When designing the page layout, I focused on creating a clear data hierarchy and enabling users to switch between locations quickly. This led to a modular layout designed to minimize vertical scrolling. Since most support staff worked with multiple monitors, one of which would often be dedicated to this page, keeping all key information visible reduced friction when switching between customers or locations. This modular structure also made future enhancements easier: new elements could be added as tabs rather than appended at the bottom of a long page.
This design would then be prototyped in Figma and presented to our internal users once again to validate that all the essential information was present and that the overall experience supported their workflow.
Conclusion
What was referred to as the “Single Pane of Glass” or SPG during development eventually became the Support Console, a single touchpoint for solving customer issues. Information that previously required navigating through multiple applications was now accessible in one place. The Support Console quickly became the most visited page in our internal platform, Assembly, earning high praise from it’s self proclaimed #1 user, our CEO.
As the new cornerstone of our internal tools, the Support Console continued to evolve. Future iterations included additional features, such as integrating all customer communications directly into the console.
Screenshot of the Support Console's first iteration
Final wireframe for the Support Console Interactions feature