Single Queue
Single queue was a brand new internal tool that I designed for Atlassian, that unifies and streamlines how support staff address customer’s technical support tickets, pairing each engineer with the most appropriate ticket to take at any given time based on their skillsets and urgency.
The Problem
Engineers across Atlassian didn’t have a standard way of prioritizing what they needed to work on. This resulted in missed SLAs, difficulty getting up to speed, and lost tickets. Each team had their own custom support dashboards, resulting in a ton of inconsistency in the support we gave to our customers.
My Role
Lone Designer:
Leading research and synthesis
Compiling journey maps and blueprints
Concept generation and iteration
Gaining cross-functional buy-in advocating for human-centered best
The Need
Help Atlassian engineers understand what tickets need their attention the most based on their skillset.
Custom Dashboards Everywhere You Look
One thing that popped out immediately as I sat with support staff is that every single support team at Atlassian had their own customized dashboard which spells trouble for a multitude of reasons. The variants in dashboards not only negatively impacted teams ability to jump in an assist when one team was under water, but also effected how each team thought about tackling their tickets for the day. These inconsistencies led to missed SLAs and tons of customer pain.
Discovery
A ton of my time was spent working hand in hand with support staff in order to understand what their day looks like and how they conceptualize their work. I ran multiple journey mapping sessions to get an intimate understanding of their many roles and needs.
“I have to use multiple imperfect systems to understand our workload.”
Finding the Pain Points
Chats and journey mapping exercises with different members of the support staff. Some pretty serious pain points surfaced endemically across the board:
Support engineers have to use multiple (imperfect) systems to understand workload.
It’s a very long process to gauge who has what assigned.
Support engineers often forget to update status in Trello.
Support engineers don’t always remember to do handovers to the next region taking over.
Card Sorting
One extremely valuable activity (especially once everyone went remote) was performing digital card-sorting activities to allow me to understand how support engineers conceptualize certain capabilities they were seeking. In this specific example, I was designing a way for engineers to set their status to give visibility to their teammates of the health of their queue at any time. I was curious what tasks do they consider themselves available to take tickets, which they consider themselves busy, and which they consider themselves completely unavailable.
Identifying “Quick Wins”
One methodology I used to understand how to prioritize capabilities was creating matrices of impact/feasibility. I would work with the support staff and our development team to understand how impactful a capability was for our support staff and how feasible it would be to implement. We strategized around which capabilities would be foundational for other valuable features down the road. One example of a “quick win” was the ability for engineers to set their status in the tool itself so the support team could have a sense of capacity at any given time. Before single queue, engineers would need to set their status by moving Trello cards around. The huge problem as each engineer had to remember to go into Trello whenever they were switching tasks…and to no one’s surprise, folks only remembered to do this about 50% of the time. Customer tickets breached and we let things fall through the cracks.
Not a great solution to a simple problem 😬😬😬
Collaborating Toward a Solution
One key learning in this project was the value of keeping things low fidelity. This helped support staff feel empowered to engage meaningfully with the early design decisions. If I approached them with a refined Figma prototype right away, we would have had very different conversations that would likely have caused me to miss a lot of the nuance.
Support As a Team
Engineers can see all of their team’s ticket volume in one place, ordered by priority and relevance to their skillsets.
Set Your Status
Engineers can now easily set their status in the tool, allowing their team to always know what they are working on. If they forget to set when they are away, if the tool detects no activity after 15 minutes it will automatically set them to idle, so their teammates know to look out for any of their close-to-breaching tickets.
Never miss a ticket
Engineers can quickly understand the status of all of their tickets and where to best focus. By seeing a breakdown of all the types of tickets, they can easily assess their workload.
Team Settings
Support engineers work many different queues at many different times (depending on the need). It became imperative to give them the capability to easily toggle on and off the queues they were focusing on. In the past, they would need to have many tabs with many dashboards open, this toggling capability greatly simplified this task and helped them maintain their focus.
Team Health
One extremely valuable capability I designed was the ability for engineers to see a holistic view of their entire team, the status of each member, and the overall capacity. Engineers can also easily click into any type of tickets for any of their teammates to specifically see what they are working on (if the need arises)
Team Lead portal
As single queue grew, I began designing some high-value capabilities for other roles. At the end of every day a team lead would have to indicate the “code” at the end of every day (red, yellow, green). In the past this was done in a VERY large and confusing Google sheet. Now team leads are able to see a view of their team’s daily capacity in the tool and easily edit, notate and submit their daily report.
Measuring Success
Currently we have over 90% of all of Atlassian support using this tool (10% still have to occasionally revisit the old tool for use-cases that haven’t been built out yet). One of the major indicators of success is that we have seen a 37% decrease in time it takes engineers to assign themselves to customer escalations (which are some of the more complex and time-consuming tickets).
“The separate sections direct focus to the most important tasks at hand. The features allow this tool to be used by any team, preventing the need for multiple highly customized dashboards.”
Next Steps
Building out the team lead experience
Building out administration features for leadership.