Civil money claims - beta

The report from the beta assessment for HMCTS's Civil money claims service on 21 March 2018.

From: Government Digital Service
Assessment date: 21 March 2018
Stage: Beta
Result: Met
Service provider: HM Courts and Tribunals Service

The service met the Standard because:

  • This is a strong, capable and empowered team, working in an agile way, with increasing support from key disciplines including legal and policy specialists
  • Under significant time pressure, the team have built an effective service that addresses a well understood user need
  • Appropriate and proportionate technology choices have been made, including sufficient consideration of security and privacy issues

About the service


The service enables users to access the Civil Court to pursue debts owed by individuals and businesses in England and Wales.

Service users

At this stage the service is for Claimants and Defendants that do not have legal representation, where the dispute value is less than £10,000.


User needs

The team demonstrated a strong understanding of the different users of the service, and their behaviour, motivation and needs. The team have documented what they have learned in a good set of personas and journey maps.

The team have done an appropriate amount of research using effective methods with a broad range of participants. The team has, in particular, made excellent efforts using a range of approaches to find people with lower digital skills.

The panel were disappointed that the team has not acted on the strong recommendation made at the Alpha assessment for more research with people with disabilities to understand the barriers they experience. This was particularly obvious, for example, when capturing telephone numbers and with the final ‘print and send’ section.

The team has significant work to do to move beyond a compliance based approach to accessibility (accessibility audits), to fully understanding the needs of users with disabilities and designing the service to meet those needs and remove barriers.

There is a clear need for HMCTS to improve its capability in this area, and to ensure that primary research with users with disabilities is a mandatory requirement in all its service development.

The team has a good plan to continue learning from users and developing the service through public beta. And the team has good feedback methods for improving support channels - both directly provided and third party.


The team is well led by an empowered and highly knowledgeable Service Manager, with experienced specialists in key roles. Currently only a very small percentage of the team are permanent civil servants, and this is recognised as a problem to be addressed by HMCTS corporately, although recruitment is challenging and lagging significantly behind delivery priorities and timelines.

There are some permanent staff, with a business analyst and some junior developers joining the team, supported by a Head of User Research and product owners in the wider HMCTS. But there is a lack of permanent service design, technical architecture and user research team members. The panel were concerned that this may have led to design and development choices that prioritise delivery of functionality over solving users’ whole needs, breadth over depth.

The Money Claims service is part of a wider transformation programme, HMCTS reform, and is the first of a portfolio of new digital services to reach Beta assessment. Alongside the individual service developments, HMCTS are developing ‘common components’, including Identity and Access Management and a ‘case management’ capability. These components are developed by separate HMCTS teams, but the CMC group work closely with them, feeding into component teams’ backlogs and development priorities.

Wider engagement with HMCTS colleagues is positive and the panel were pleased to see the regular involvement of a Judge, bringing expert advice to support design and development decisions. They are supported by a sub-committee with representatives from policy and legal professions. We would like to see this engagement continue and develop, to ensure that the wider team is genuinely multidisciplinary – HMCTS should seek to erode the gap between digital/technology teams, and both the policy-making/legal sides of the organisation, and colleagues in operational delivery.

Overall the panel felt that this was a team performing at a high standard, working effectively in an agile way, despite the constraints that they are operating within. Of these, we were most concerned about the lack of progress in recruitment of permanent staff.


Common component – Identity and Access Management (IDAM)

The panel are keen that the Money Claims team aren’t constrained in their own agile development by use of common components like IDAM, particularly as other services begin to use IDAM, with the potentially conflicting requirements this presents. The decision to use a shared component should be kept under review. Firstly to ensure that an IDAM component is actually necessary – is there value to one-off users in an account mechanism in this form? Secondly HMCTS should demonstrate that common component use is more effective and efficient than, for example, sharing code and design patterns that teams across the portfolio and more widely across government use. This will be particularly relevant as or when HMCTS teams begin to adopt GOV.UK Verify.

Money Claim Service

The Money Claims journeys demonstrated the evolution of the services technology from the alpha to the beta stage and it is commendable that the team has achieved the desired results for this phase.

The team has shown that they have appropriate capacity to develop digital services in line with the service standard. Continuing the practises from alpha stage, the team has emphasized on continuous integration and continuous deployment methodologies.

The team has continued to code in the open, and the team did not present any reasons to suggest that the majority of code needed by the service could not be publicly accessible.

A key point throughout the development of the beta system is the integration of casework and other systems in the overall service environment. The exchanges of data occur at the service level through well-defined APIs, and care has been taken to ensure that the single source of truth remains clear following this integration, especially considering that the paper and mediated service processes will continue in parallel with the deployment of the digital service. If the digital service repository is allowed to diverge from that of the existing casework system there could be difficulties for the many internal users of the combined system.

The team demonstrated good agility for using the common platform components such as IDAM, GOV.UK Pay and GOV.UK Notify. It is commendable that they used the common components in line with service user needs. Furthermore, they have reviewed dependencies for these components until end of this year and they will continue to track tickets raised through JIRA as part of their sprints. As part of the beta phase, the team has adopted HMCTS reforms tactical IDAM solution and they aspire to move to Strategic IDAM subsequently. We recommend the continued engagement with GOV.UK Verify, including the LOA1 service, as a consistent way to verify the identities of claimants and respondents has obvious benefits for the trustworthiness of of the digital legal process involved.

The technology stack which includes Application Stack, Database Stack and QA stack is inline with the standards proposed and most of the technical stack remains the same from alpha stage. The few changes in beta for the tech stack follows programme technology choice which will make maintenance and code reuse easier. The change around using RPM and Docker image for backend helps reuse binaries across platform and enforces good design practises. Within the application architecture, they have introduced Robotic Process Automation and they have assured that sufficient scaling is considered for future as well.

The management of user data seems appropriate, and it is good to hear that policy advice is available to the team to support specific issues of data retention and privacy. The team confirmed that they have assured the data and service is GDPR compliant. The team has continued to focus on data security, they liaise with the security operations teams, assess the issues with stakeholders, internal IT services, external assessments with NCSC as well as supplier 6.6 where routine internal assessments are carried out. We would recommend the team to follow NCSC guidelines with password management.


Common component – Identity and Access Management (IDAM)

The panel were encouraged by the integration of GOV.UK Pay and Notify in the service development, which have been integrated seamlessly into the end-to-end service journey.

The current implementation of HMCTS’s IDAM solution is its first use across the portfolio, and the implementation shared at assessment was jarring, lacking context and explanation. The team needs to ensure that they have full control of the user experience of their service end to end, and aren’t constrained or limited by the technical implementation of IDAM. It should be possible to integrate an API/headless component like this such that users are clear where they are, what they’re being asked to do and why.

Money Claim Service

The end-to-end service map on the wall during the assessment was useful demonstrating the full scope of the service for its users, the assessment used the services prototype, so it was unclear what features are available on the prototype for testing, and what features have been shipped to beta.

The scope of the service being assessed was ‘Issue claim’ and ‘Respond to claim’ (with pathways to mediation). Both the service map and the prototype had a ‘guidance’ step at the start, the panel suggest that this part of the service be in scope at future assessment.

The team have been analysing search behaviours and have found that users land on the start page of the service. The service name is not consistent across the service content:

  • Make a court claim for money
  • Make a money claim
  • Make a money claim online

This needs aligning. The team should also ensure that the more generic names such as ‘Make a money claim online’ does not result in users of other money claim services across government (benefits, tax rebates) finding the HMCTS service.

The scope of the service assessed is for claimants and defendants that do not have legal representation, where the dispute value is less than £10,000. There is a fairly lengthy triage process to determine if a user is eligible to use the service. Many of the user journeys during the triage result in a handoff to the legacy service and in some cases other organisations. As the service is iterated, more users will be eligible to use the service and the triage process will shorten.

Users who do make the investment to complete the triage process (and are eligible to use the service) will not see their answers captured to make the claim easier for them later on.

During triage, the service links to a list of Government organisations. The assessment panel suggest using the Government Organisations register for this data.

Users are asked to create an account. Giving users ‘access to their claims’ rather than asking to ‘create an account’ is more aligned to the needs identified by the service team. The panel suggest trying different / simpler sequences of sign-in vs sign-up and if possible, help users to understand if they already have a claims history (those that already have an ‘account’).

The scope of service presented at the assessment does not meet the broader needs of the service users. “As a party in a dispute (claimant or defendant), I want my claim to be settled as early and quickly as possible so that I can continue with my life as normal.” The beta service does not cover settlement, it relies on parts of the legacy service for that. The service team must at future assessment provide evidence that users can succeed first time from end-to-end (as presented in their service map), not just within the scope of the beta service.

The team’s intention is to continue to transform the other service stages over time. The potential impact of that strategy is the service mirroring the programme structure and resulting in a fragmented service for its users.

The service breaks when an offline response from a defendant needs an online response back to the claimant. The back office process picks up the defendant response letter and emails the claimant. The beta service is not in sync with this process. The team must look at joining this up as claimant users may experience contradicting messages if their claims dashboard is not up to date.

The team acknowledge that the offline guidance for using the service needs to be improved.

The prototype has no validation which will make it harder to learn about users failing at certain points, given the data they are providing. The introductory content uses javascript-based navigation on the guidance pages and the next previous button aren’t usable when it’s disabled (other UI suggestions available as a separate document).


The team gave a clear exposition or how they have been using data and analysis to inform the private beta. Although in private beta, the service has been accessible to a wider audience as, for example the call centre has directed enquirers to try the new service. This has meant the service has collected a useful volume of data.

There have been clear outcomes for private beta - including outcomes that the team was able to quantify - such as an increased rate of engagement by defendants.

Data is being collected from digital analytics on the online service, from backend components and from the call centre and the team have built a range of dashboards to monitor activity.

The team has a strong plan for extracting value from increased volumes of data once in public beta - identifying trends and in Q4 2018 they expect to deliver second and third rounds of improvements of the service based upon performance data and user feedback.

Regarding performance indicators, the team has established a baseline for five areas - defendant engagement, defence rate, default judgement, timeliness and mediation and is able to compare a range of metrics against the legacy service.

The legacy service has a Performance Platform dashboard and the team would like advice whether to replace this with data for the new service. The assessor agrees that this is sensible, but recommends talking to the Performance Platform team.

In summary, the team gave a clear description of what they have achieved and what they plan to do - focusing not just on the digital service, but on behavioural and culture change and outcomes.


To pass the next assessment, the service team must:

  • The team and wider HMCTS leadership must seek to address the disproportionate ratio of permanent versus contract staff, to ensure the long-term sustainability of the service.
  • The team must do more to learn about the needs of people with disabilities, and develop the service to meet those needs and to remove potential barriers
  • Improve offline guidance for the service

  • The service team must provide evidence that users can succeed first time from end-to-end as other stages of the service are added

  • Integrate back office processes for notifying the claimant of the defendant response letter to ensure users do not experience their dashboard contradicting email communication

  • Consult the GDS Performance Platform team on whether to replace the performance data dashboard with data from the new service

  • Follow NCSC guidelines for password management

The service team should also:

  • Explore different sequences of sign-in vs sign-up and if possible simplify the service to help users understand if they already have a claims history

  • Use the Government Organisations register to link to a list of Government organisations.
  • Undertake a design review of the beta service

Digital Service Standard points

Point Description Result
1 Understanding user needs Met
2 Improving the service based on user research and usability testing Met
3 Having a sustainable, multidisciplinary team in place Met
4 Building using agile, iterative and user-centred methods Met
5 Iterating and improving the service on a frequent basis Met
6 Evaluating tools, systems, and ways of procuring them Met
7 Managing data, security level, legal responsibilities, privacy issues and risks Met
8 Making code available as open source Met
9 Using open standards and common government platforms Met
10 Testing the end-to-end service, and browser and device testing Met
11 Planning for the service being taken temporarily offline Met
12 Creating a simple and intuitive service Met
13 Ensuring consistency with the design and style of GOV.UK Met
14 Encouraging digital take-up Met
15 Using analytics tools to collect and act on performance data Met
16 Defining KPIs and establishing performance benchmarks Met
17 Reporting performance data on the Performance Platform Met
18 Testing the service with the minister responsible for it Met
Published 6 August 2018