My role
Product design lead
The working team
Product manager who was also a support team SME, team of 3-4 engineers
Project duration
About 6 months
The Up digital bank platform was built from the scratch, and that included all the software for managing customer support via in-app chat.
When I joined the company in 2020, the in-house chat system that they were using was very basic – there was one customer chat inbox, and all the support team members would manually pick chats to respond to from that inbox.
I designed the first version of their chat system that assigned support team members chats in priority order, based on which chats had been in the queue the longest – this was the version that the team used until recently.
By 2024, the support team had grown about five-fold in size, and had also grown in complexity with more layers of management, sub-teams, and specialisations. And the team was still growing, adding new team members every few months.
The single chat queue that had served the team so well for years was no longer adequate – I was asked to design an update for the system.
Discovery
The single chronologically-ordered chat queue was no longer sophisticated enough to manage all the different types chats the support team had to handle.
Over time, the single queue had been split into multiple “buckets” (mini queues) for specific chat types that needed to be highlighted for some reason, chats would be triaged into those buckets, and staff would be assigned to monitor each of those buckets.
This system worked for a while, but with the continued growth it was not sustainable:
staff rostering was becoming unmanageably complicated;
high fluctuation in the volume of the buckets meant it was difficult balance resourcing;
urgent chats were being triaged into its own bucket with the intent that it would be highlighted and addressed more quickly, but sometimes the urgent bucket grew disproportionately so that it was actually slower to get through.
I worked with the support SMEs to understand the reasons why we had each of the buckets. After some sorting and categorising, it seemed there were four main types of reasons…
It seemed to me that if we could factor those properties into the prioritisation and assignment logic, we could get chats to the right people at the right time without all this manual sorting.
Data design
Having worked out what we needed to track conceptually, I now needed to match this to information that we have.
There was nothing useful in our technical systems at this stage, but I found useful information that existed elsewhere, for example:
training documentation for the support team, with sections broken up into different categories of chats;
training program schedule which showed how support staff were onboarded gradually over weeks;
SLAs that were documented in our operational guidelines and in our T&Cs.
Where I needed additional information, I called on specific SMEs who were responsible for specific buckets to find out more details about systems and processes.
With this information gathered, I proposed data representations for each property we needed to define.
At this point I defined the design problem more specifically:
Logic design
Conceptually this was the order of events previously:
Chat is prioritised
First in, first out
Chat is assigned
First person available picks up highest priority chat
Chat is categorised
Assignee categorises the chat after reading the message
What we were proposing would be something like this:
Chat is categorised
Somehow…
Chat is prioritised
Based on age of chat and whether it’s time critical
Chat is assigned
The next available person picks up the highest priority chat they can answer
I then proposed logic/options for each of the stages:
Chat is categorised
Somehow…
Version 1 by manual triage
Version 2 through machine learning-driven auto-categorisation
Chat is prioritised
Based on age of chat and whether it’s time critical
Sort by:
Lowest number of minutes left until any SLA is exceeded first, highest minutes left last; then
Customers with “high priority” flags first, everything else after; then
Oldest chat first, newest chat last
Chat is assigned
The next available person picks up the highest priority chat they can answer
When a support team member hits “give me a chat”, give them the first chat on the priority list where the user’s properties match the requirements for the chat’s category.
UX design
Having introduced a bunch of new properties into the system, we wanted to make sure we had a sensible way to manage them, rather than just coding them into the backend! I designed new interfaces for managing properties of the categories, and properties of a user.
There were no changes required for the actual chat interfaces, as the changes were primarily around the logic and setup.
Delivery and release
My involvement in the implementation included:
preparing annotated Figma files and descriptions of the proposed logic for the engineering team;
working through any design and functionality queries with engineers during build;
reviewing and testing the built UI;
observing and taking feedback during user testing session run by the product manager.
Although our initial testing with manual triage went smoothly, the product manager and stakeholders decided to hold off release because we were close to having an automated categorisation option available.
The new updates were finally released in around April of 2025 and is now in use by the support team.