Background
The AQTS service sends emails through GOV.UK Notify. Over time, support tickets highlighted that some users were not receiving key emails. While the service already allowed reference request emails to be resent, other failed emails required manual intervention.
To better understand the issue, the development team and performance analyst began monitoring email delivery and capturing failures. These failures were shared with the Professional Recognition (PR) team through a weekly spreadsheet, allowing them to proactively identify and contact affected users.
Although this improved visibility, it introduced an additional offline process. To reduce manual handling and bring the workflow into the service, we decided to develop an email failures feature within the case management system (CMS).
How we approached it
We began by reviewing the weekly spreadsheet and working with PR colleagues to understand how email failures were currently managed. We explored which emails were most likely to fail, at which stage of the application journey failures occurred, and how the information was being used operationally.
Following the GOV.UK principle of starting with user needs, we focused on understanding the workflow before proposing solutions. We also identified potential edge cases and considered how introducing the feature could impact existing processes.
Design decisions
We explored several concepts, including both an MVP and enhanced future versions, and worked closely with the technical team to assess feasibility.
The chosen solution was a table view within the CMS, accessible through the primary navigation.
Key information identified as essential included:
the applicant and application details associated with the failed email information that could be easily copied into Zendesk when follow-up contact was required the recipient's role (for example, applicant or referee) which stage of the process the failed email related to the colleague assigned to the application, helping ensure ownership of any follow-up actions We also considered several usability and operational questions, including:
how much historical data should be displayed how to communicate that the data was not updated in real time what users should see when there were no email failures whether pagination would be required Following feedback from both technical and operational colleagues, the design was refined. We decided to display two weeks of historical data, aligning with the previous weekly reporting process while keeping the information manageable. We also included clear messaging about when the data was last updated, supporting transparency and helping users understand the limitations of the information displayed.
Pagination was not implemented as failure volumes were typically low, and displaying all records on a single page better supported quick review and action.
Outcomes and next steps
The feature has now been developed and released within the CMS. We demonstrated the functionality to the PR team and incorporated their feedback before launch.
By bringing email failure monitoring into the service, we removed the need for a separate spreadsheet process and gave colleagues direct access to the information they need to support applicants.
We will continue to monitor usage and gather feedback through wider user research and operational engagement to identify opportunities for future improvements.