Skip to main content

Alcohol Wholesale Registration Scheme - Alpha Assessment

The Alcohol Wholesale Registration Scheme service will allow alcohol wholesalers to apply to HMRC for registration in compliance with the AWRS rules.

Department / Agency:
HM Revenue & Customs (HMRC)

Date of Assessment:
6 July 2015

Assessment Stage:

Result of Assessment:

Lead Assessor:
A. Lister

Service Manager:
A. Chadwick

Digital Leader:
M. Dearnley

Assessment Report

Outcome of service assessment

The Alcohol Wholesale Registration Scheme is not yet meeting 3 points of the Digital by Default Service Standard for the reasons outlined below.

However, given the limited scope of the service presented at the assessment (a service allowing wholesalers to apply to join the register, as opposed to an end-to-end service for confirming wholesalers’ legitimacy), and the early stage of development, the assessment panel concluded that the service is sufficiently on track to meet the standard and can therefore proceed to private beta.

Panel's Assessment

The panel is content to allow the service to proceed based on the following:

  • There is a valid, overarching user need for the service, and strong evidence that it is something the industry actively wants.
  • There is a well-formed, skilled, multi-disciplinary and agile team in place which is working according to the methods in the service manual.
  • The service team was able to demonstrate that it has used the GDS design patterns and has made many changes to the service during the alpha development, based on learnings from user research, and is providing healthy challenge back to the business about what information HMRC actually needs from alcohol wholesaler.
  • The service team are using the proven technologies that the department is familiar with to deliver the on-screen service - taking advantage of, and contributing to, common components used across HMRC.

However, the panel have a number of concerns about the service which the team will need to address in order to pass a beta assessment.

User Needs

While the team has conducted some valuable research during the alpha including remote and contextual research, the work done to date does not go far enough and the panel felt there were gaps in the team’s knowledge of the audience, and of the range of circumstances in which the service might be used. Specifically:

  • The criteria used in user recruitment were from the perspective of the service team rather than users, and were all functions of size (e.g. number of directors, number of premises). The existence or relevance of other dimensions has not been explored (e.g. internet confidence, English as a second language). There may be further dimensions among the estimated 20,000 alcohol wholesalers in the UK, yet to be discovered, which may have important implications for service design.
  • A significant part of the audience will be new alcohol wholesalers, estimated to be 4,000 per year (generally these are wholesalers of other products who diversify or switch to alcohol). No research has yet been conducted with this segment.
  • Recruitment for research has been conducted internally by a colleague who is not a user researcher and who has found users via trade associations, Google searches and cold calling. This is not a good way to get a representative or reliable research sample.
  • The quantity of research has been too small to give sufficient confidence about the decisions the team is making (i.e. the sample size and coverage is too small given the expected eventual user base).
  • The team has identified a single, high-level need for the service that focuses on proprietors of alcohol wholesale businesses. The team needs to break this down into more detailed users’ needs, consider the varying needs of different kinds of employee who might apply on behalf of the proprietor, and include the wider users of the service such as the risk assessors who will work with the information once collected.

Taking these factors together, there are likely to be significant skews and gaps in the representativeness of the sample up to this point, and hence in the robustness of the findings.

User Research

The plans for research at the beta stage are focused around sole proprietors. The expectation is this focus will help to uncover needs among those who are unable to use the product without help from others. However, there was not a firm or determined plan to achieve the aspiration of between 30 - 50 respondents for the phase.

Open Source Code by Default

The team explained that their planned approach would be to publish code selectively, when it is "ready". The panel felt this was not aligned with the policy of open source by default and coding in the open.


In order to pass the beta assessment, it is vital that the team address the following recommendations.

User Needs

  • Ensure there is sufficient user research time assigned to the service’s development. We recommend that at least one full time researcher works on the service.
  • Conduct more and deeper research, using professional recruitment methods to find a broader range of users (including those who will need assisted digital support to use the service) and understand their needs. This may include direct contact between researcher and trade associations, or the use of an external recruiter as appropriate.
  • Develop a more thorough and well considered segmentation of the audience against relevant criteria, and ensure that research is done specifically with users with the lowest level of digital skills, and that suitable recruitment methods are used to find users (i.e. not just those with an online presence).
  • Continue the contextual research activity, to explore audience make-up, user needs and use of the service in context.
  • Increase the number of users seen per iteration of the product. Consider methods that will allow face-to-face contact with respondents during product testing.

User Research

Develop a firm research plan for beta which outlines:

  • research questions
  • research methodologies
  • target segments among the audience
  • recruitment methods
  • researcher resource
  • research outputs
  • timescales

Open Source Code by Default

  • Publish all source code, excluding only those parts of the code for which there is a compelling security reason to protect it.

Create a Simple and Intuitive Service

  • Ensure the service includes support routes that address the needs of users who will not be able to complete the service independently, including creating and accessing an email account.

Digital by Default Service Standard Criteria

Criteria Passed Criteria Passed
1 No 2 No
3 Yes 4 Yes
5 Yes 6 Yes
7 Yes 8 No
9 Yes 10 Yes
11 Yes 12 Yes
13 Yes 14 Yes
15 Yes 16 Yes
17 Yes 18 Yes