Background
The AQTS service has previously tracked service level agreements (SLAs) within the case management system (CMS) for priority applications.
This was a development-led feature built by the team in the absence of a designer. It enabled managers within the operational team to identify priority applications approaching or exceeding SLA targets.
Through ongoing service improvement work, several user needs were identified due to policy changes:
the ability to view both prioritised and non-prioritised applications improved visibility of applications with different SLA requirements based on country of origin greater access to SLA information for operational staff, rather than limiting visibility to management users These changes aimed to improve workload management, increase transparency, and support more efficient decision-making across the team.
How we approached it
Initial design work began within the digital team, but it quickly became clear that defining the new requirements required close collaboration between policy, operations, and the technical team.
We facilitated a co-design workshop to:
build a shared understanding of the updated SLA policy identify users, their goals, and day-to-day workflows map operational processes and pain points assess technical feasibility for the improvements with the development team This collaborative approach aimed to make sure the design reflected both policy requirements and operational realities.
Design decisions
Several design changes were introduced to support the new requirements.
Country filtering
We added a country filter to allow users to quickly view applications from specific countries. This was important because SLA processes can vary depending on country-specific requirements and team expertise.
The filter was positioned horizontally above the results table to make it highly visible while avoiding disruption to the main content.
Improved application management
To improve usability and reduce excessive scrolling, application lists were limited to 25 records per page.
Applications were also grouped into separate tabs based on the 3 SLAs: 10-days, 40-days, and 80-days. This enables users to focus on the most relevant workload.
Enhanced visibility of urgent work
We introduced colour-coded status indicators for applications that are either approaching an SLA breach or already breached.
This provides a clear visual cue and allows users to address urgent work quickly.
To further support urgent work, the page only displays applications that are nearing breach or have already breached their SLA, rather than including applications that are within SLA. This ensures attention is focused on actionable items.
Supporting operational workflows
Previously, managers often shared screenshots of SLA reports with team members to direct work allocation.
By making SLA information available to all users, the service now supports a more efficient workflow, reducing the need for information to be shared outside the service and enabling staff to manage their own priorities more effectively.
SLA totals
We introduced an SLA totals overview to provide visibility of the overall application workload. This enables management and policy teams to quickly understand the number of applications within each SLA category and which country they are from, supporting operational oversight, resource planning, and informed decision making.
SLA definitions
We added an SLA definitions section to help users understand the different targets and how the “Nearing” status is calculated. This was particularly important because applications are subject to different SLA requirements depending on the stage of their assessment.
What happens next
The feature has now been released. We will continue to monitor usage and gather user feedback through research to understand how the feature is being used and identify opportunities for further improvement.