Accessibility and assisted digital

Set up and manage user support

You must provide user support for people using your service. This should:

  • handle user requests for information
  • help direct users to the information they want

You should use feedback you get from user support to decide how you’ll improve your service.

Why user support is important

User support is important because it can:

  • help you improve your service in line with user feedback
  • allow for continuous improvement
  • act as ‘eyes and ears’ to tell you what’s really going on with your service

You should not set up your user support so it’s:

  • done in an isolated way, separate from the rest of your organisation
  • only about reacting to problems

Planning for user support

How you plan your user support will depend on your organisation.

You’ll need a call centre professional to help you plan. This should be someone who has experience in capacity planning or managing contact centres.

If your department or agency does not have someone with these skills, you can use the Digital Marketplace to hire a consultant.

Before you set up your user support, consider:

  • what types of enquiries you expect to get and how many
  • how long you think it should take to deal with enquiries
  • how you’ll staff your user support
  • how you’ll measure the performance of your user support

Estimate demand

You need to make separate estimates for:

  • the number of enquiries you’re likely to get, broken down by channel (for example email, phone, social media)
  • the types of enquiries you think you’ll get (for example questions, problems, freedom of information (FOI) requests)

Use these estimates to:

  • help you make decisions on what technology you’ll use to route, handle and store data
  • adjust your plans (for example, if you start getting a lot more enquiries by online chat than by email or phone)

Check historical data

You can use historical data to get an idea about:

  • the number of enquiries your service will receive
  • what channels your users will use when they have enquiries
  • how quickly you’ll be able to deal with enquiries

If you do not have historical data from an existing service you can use similar services, for example online user support in another part of your department or a related organisation.

Calculate response times

After you’ve worked out likely demand, you should work out how how many staff you need and how quickly they’ll be able to deal with individual enquiries.

Think about what kind of enquiries you get and when. For example, if you get a lot of calls on Fridays and none on Mondays but you have staff on Mondays and not on Fridays.

Your response times will also depend on which channel staff are assigned to, and whether they can work across multiple channels at the same time.

Use historical data to:

  • estimate the average handling time (AHT) for each of your channels
  • calculate the average number of enquiries one agent can handle each day per channel based on the types of enquiries you usually get

Set a target service level

You should use your historical and AHT data to work out your service level. This is the percentage of enquiries you aim to solve for each channel in a given time period (for example, you might plan to answer 80% of email enquiries within 24 hours).

You need to know what your service level is when building a user support system so you can:

  • work out how many staff you’ll need for user support
  • schedule helpdesk staff so you can meet service level targets
  • check the level of service you’ll be able to provide
  • improve your user support

Your organisation might choose the service level or you might be able to decide the best level of service you can give your users.

Measure your user support performance

You should start planning how to measure the performance of your user support during your discovery phase. You can use subgroups and data sharing to do this.

Set up subgroups

You’ll find it easier to analyse and respond to user enquiries if you arrange them into subgroups. For example, it’s easier to identify and solve a problem if you know not just that an enquiry is from a department, but which department, or which team in that department.

How you set up and manage your subgroups will depend on how many enquiries you get and how complicated they are.

If you get a lot of enquiries you may need specialist software that can sort them into subgroups automatically.

Choosing your subgroups

As a minimum, you’ll need to create subgroups for each:

  • support channel
  • internal team or group that can act on the feedback

You may also want to create subgroups based on:

  • type of enquiry or common reasons for users contacting user support (for example complaints, forgotten passwords or asking what’s happening with an application)
  • user group (including whether it’s an anonymous enquiry and you need to know who’s asking for help and which department they’re in)
  • enquiry status (for example, if it needs more action or whether a reply is expected)
  • content type (including content owned by a different department)
  • how enquiries are handled (for example, the day or date it was received or solved)

When your user support is up and running, you should collect data on how many contacts you get, the response and handling time to:

  • improve and refine all the estimates you made previously
  • plan for improvements based on how your helpdesk performs

You should do this for each channel, team and individual.

Using data to make improvements

You should prioritise improvements to your user support. Usually you’ll do this by focusing on:

  • cost - which issues will save you the most money if you solve them
  • the percentage of affected users - which issues affect the largest group of users

The best solutions come from staff who deal with users directly, so you should talk to anyone who:

  • handles enquiries
  • built the service
  • manages the live service

Treat enquiries as faults

A great model for improving your service is to treat enquiries as faults. This is because faults indicate something’s wrong.

Faults are not always obvious. For example, the real problem might not relate to what the user’s reporting. It might relate to the way a call centre handles enquiries or a paper letter that users get as part of their journey through a service.

You may find the following guides useful:

Last update:

Guidance first published