The first step is to identify who will be involved in the service desk and assign roles and responsibilities to them. For the initial implementation you should involve as few people as possible, so that the tasks can become familiar with minimum impact on the day-to-day workload. Assigning roles and responsibilities will depend on how you provide technical support currently and who is involved already.

Training
After you have assigned roles and responsibilities, it is important that those participating understand what is required of them. Use this reference guide as training material.

Start date
Setting a start date for the service desk to 'go-live' is important to focus those involved and to mark the changeover to new methods in the team and for your end-users. Make sure that you allow enough time to do all the other preparatory tasks beforehand.

Communication
Communication must take place within the implementation team to agree plans, schedule dates and so on, but it is important also to communicate externally and inform the end-user community of the service desk and its procedure. The implementation of a service desk can be seen as a change, just like the upgrading of a server, and the impact on the user community should be communicated to them clearly in advance of the change.

Materials
Before you can go ahead with the implementation you will need all the materials required. Make sure that you have downloaded the templates you need and that everyone involved has access to them.

Pilot
A good way to test your implementation of a service desk is to record and log one incident and manage its progress through to resolution. We have included this as a step in the implementation guide, prior to service desk 'go-live', so that participants can be familiarised with what needs to be done before exposing them to the real thing. Review the test incident and discuss any issues. When you are happy that everyone understands the requirements and that all roles are fulfilled adequately, you can launch the service desk, but you should feel free to complete as many tests as necessary beforehand.

Prerequisites
To have a purpose, a service desk should have a working incident management process as a minimum. FITS incident management is designed to work directly with FITS service desk. You can implement FITS incident management before FITS service desk but it will probably be easier for you to implement them both together, so that roles and responsibilities are assigned only once. The service desk also plays a key role in problem management but FITS problem management can be implemented at a later date. This may be advisable, so that the workload for the service desk is limited in its early days.

Assigning roles and responsibilities in a service desk
Some suggestions and guidance to help you assign roles and responsibilities in a service desk are shown in the table below.

Assigning the users of a service desk
Anyone who comes into contact with using computer equipment or the results of using it is potentially a customer of the service desk.

This would probably include:

• teachers
• teaching assistants
• students
• administration staff
• technicians
• headteachers

You also need to think about others who may benefit from being able to make requests or log incidents through the service desk,  such as:

• technical support staff 
• governors
• caretakers
• cleaners

Where schools do not provide a single point of contact this can create problems when teaching staff and technicians need to discuss an incident or request. School staff reporting an incident may not always be available when the technician arrives to fix it, which can create delays.

The solution is to provide a single point of contact who is familiar with the details of an incident when registering a support call with a technician or third-party support provider. This is particularly important where technical support is external to the school (for instance, provided by an LA or other third-party support company).

The role of single point of contact could be an additional function for the following staff:

• school administration staff
• ICT co-ordinator (not ideal)
• teaching assistant
• nominated teacher
• network manager (not ideal)
• technical support staff (not ideal)
• other nominated staff.

Bear in mind that administrative and organisational skills are more important than technical ones, and that the person in this role may need to dedicate themselves to service desk activities rather than their other job, so some staff in the list above may not be the most ideal.

The next stage is to carry out these tasks:

• Agree how calls will be recorded.
• Assess how much extra work is likely to be involved in recording details of incidents and requests.
• Decide which role in the school provides access for teaching staff and those providing technical support and can accommodate the additional work of maintaining the call log.
• Ensure that the technical support providers and school staff know who the single point of contact is.

If you are introducing the concept of a service desk for the first time, be aware that people need to trust the system and may need something tangible.

The service desk may well get visitors, phone calls, forms dropped on the desk – so it needs to be located somewhere accessible.

You want to make the customers feel confident that their calls and requests will be recorded accurately by logging them with a customer-focused service person. The decision about where to place the service desk is as important as choosing who should staff it.

It is vital to communicate the idea of a service desk throughout the school. This will ensure that:

• everyone knows how to use the service desk for all computer equipment incidents and requests
• everyone knows there is no exception to this rule
• everyone understands how this will free up technical support staff to actually do that role
• everyone understands that breaking these rules even slightly will cause the system to fail.

Ensure that the school leaders are seen to be following these rules and not bending them because of their position.

Plan training for:

• customers on how to use the service desk
• service desk support staff on their role
• staff providing technical support on their interaction with the service desk
• any third-party suppliers on their interaction with the service desk
• school leaders on their interaction with service desk.

Decide how to introduce the training. Options could include circulating documentation to users, training each person individually, or providing a group training session.

Establish the confidence of the staff using and staffing the service desk by having the workload monitored and the approach reviewed every month.

Decide what is to be monitored before the launch of the service desk. At a minimum you should monitor:

• the number of incidents and requests made through the service desk each week
• the types of requests that take the most time to record
• those customers that appear to need the most support.

It's important that implementing a service desk brings you benefits and not problems, so you should be prepared to pass a critical eye over your plans and identify where problems can occur with the process.

Risk analysis
There is a lot of information available about how to do risk analysis, but knowing your school should help you identify where the problems could arise. Identify the potential risks and what you can do to mitigate them.

Fallback plan
When you create the implementation plan, create a fallback plan. This is a plan for how to cope if things don't work as expected with the implementation. For example, if your staff (users of the service desk) cannot all receive the planned training, provide written materials and have someone who knows how it works, to show the novice user what to do.

Now you need to check which would be the best method of logging incidents - see the section on the types of service desk. You will also need to agree with the staff and technicians what details to record - the content of Call Log will help you. Now create the Call Log.

The most important factor to consider, when deciding who will be the single point of contact, is what their availability for taking calls from end-users is. It is acceptable for messages to be left during a short-term absence but calls must be returned quickly. If they are not, end-users will soon become frustrated with the procedure and revert to hunting down busy technicians to approach them directly.

Many schools find that creating a single point of contact is challenging because technicians are too busy and ICT support has only a small number of staff. It is worth looking to see whether the service desk could be staffed by someone already carrying out an administrative role in school – this is a cost-effective solution and also recognises that organisational ability and having a customer-focused attitude are important attributes in this role. Other creative solutions schools have used include:

• routing calls through to an answerphone or voicemail system which is frequently checked
• using software which automatically creates call numbers and emails an acknowledgement to network users.
• Many of these systems also allow users to track progress of the call.

Those schools that have implemented a service desk found that creating a single point of contact was challenging because ... "technicians are too busy, it is too expensive and IT support has only a small number of staff. Schools adopted a number of creative solutions to address this issue. These included:

• making the first line part of the role of administrative staff other than ICT technicians. Organisation capability and a customer service attitude are equally (if not more) important attributes for this role as much as technical capability.
• routing calls through to an answerphone or voicemail system which is frequently check and responded to.
• implementing software which automatically creates call numbers and emails network users an acknowledgement. Many of these systems also allow users to track progress of the call (assuming that the IT technicians keep these updated)". - independent 'Evaluation of the Framework for IT Technical Support (FITS)'.

The single point of contact does not have to be just one person. As long as the contact details and procedure are the same, sharing the role is a good solution, allowing those involved more freedom to carry out other tasks. See the section on roles and responsibilities and assigning roles and responsibilities for further guidance.

When you have identified the single point of contact for your service desk, the next step is to set up communications.

There are a number of possible communication methods:

• Face-to-face
• Telephone
• Answering machine
• Email
• A combination of the above.

When choosing the best solution for your needs, think about these factors:

• If the convention in your school is for end-users to speak to someone face to face to report an incident, make sure that the single point of contact has a permanent location to use as a 'reception desk'.
• If telephoning is preferred or more practical, have one number, with a group pick-up facility if there will be more than one operator. A mobile telephone could help you resolve an issue of the operator needing to move around, but remember that they will need quick access to a computer (or a printed incident record template) in order to log calls promptly.
• Use voicemail or an answering machine to record messages from end-users. You could use this as a fallback method in case an operator is unavailable temporarily. Always acknowledge messages left. Even if you log the incident and action it immediately, the end-user needs to know what to expect.
• Email can be a useful additional method for reporting incidents, but remember that email can be beset by technical incidents, so it should not be relied upon as the sole method. Use a generic email address such as 'service desk', rather than the name of an individual. This will make it easier to manage mail to and from the account, identify emails sent from the service desk and help improve communication between technical staff.
• A combination of methods will provide flexibility and contingency. When you have chosen your methods, put them in place.

If you wish, you can buy software designed specifically to record and track incident and problem details. However, this can be costly and we recommend that you familiarise yourself with the process before taking on the task of selecting and configuring an expensive tool. Even if you choose a free software tool, you will make best use of it if you first familiarise yourself with the process concept.

To help you get started we have created a number of templates for you to download. You can use them as they are or adapt them as required.

The use of these templates is summarised in the operations guide and full details are in FITS Incident Management and FITS Problem Management.

When you have decided who will be the single point of contact and set up service desk communications and tools, you will need to tell end-users how to contact the service desk and what to expect. A technical support charter is a one-page guide that can be issued to all ICT users. It can also be used as a poster for walls and notice boards or kept with computers.

As a minimum the technical support charter should include details of:

• how to contact the service desk, including secondary methods such as email and voicemail
• hours of availability of the service desk
• information required from end-users when they report an incident
• information provided by the service desk when an incident has been logged
• how to escalate an incident if the level of service provided is inadequate.

In addition, if you have implemented FITS Service Level Management, you might have established priorities of incidents and corresponding target resolution times. If so, you could include these details in your charter. It will be helpful to end-users if you outline the definitions of each priority as well as the levels and target times. There is an example technical support charter and template in the introduction toolkit.

It is important to issue a charter to all ICT users, because it helps set their expectation before they report an incident and helps technical support staff to enforce the procedure. Trying to be all things to all people is a major cause of perceived poor service, but if you don't set any rules, user expectation can be higher than your resources allow.

In addition to publishing a one-page technical support charter, you could consider preparing and issuing a full handbook of additional useful information for end-users. A user handbook is easy to implement but quickly becomes out of date, so you must be committed to maintaining it if you decide to create one.

Whilst every school will have different needs, we have put together some guidelines for creating a user handbook that should help you create a useful and sustainable document that saves time both for technical support staff and for end-users.

It is a good idea to carry out a test, or pilot, of logging and progressing an incident. This will help you get a feel for what needs to be done before opening the floodgates to all users of ICT. You can find step-by-step details of how to record an incident and progress it through to resolution in FITS Incident Management, 'implement Incident Management'.

However, not all incident management tasks are carried out by the service desk. This is also explained fully in the incident management process, but the table below shows a summary of the key steps and who performs them. It is a good idea to have implemented FITS Incident Management before you carry out the pilot but not essential.

The service desk is also responsible for keeping the end-user updated throughout the process. Follow the full instructions in FITS Incident Management 'implement Incident Management' and create your first incident record and incident log entry.

The test will be most effective if you use a real incident, so make sure your technical support staff knows when you are ready to run your test and ask them to pass you details of the next incident they receive.

Repeat this exercise as many times as you feel necessary before you launch the service desk.

When the tools are in place, the technical support charter is ready and you are comfortable with the tasks involved in logging incidents, you will need to tell everyone involved (end-users and technical support) what is happening and when.

This is an important step because you need everyone to comply with the new procedure from the moment it starts. It will be very difficult for you to manage the old way and the new way simultaneously if not everyone complies.

It is notoriously difficult to enforce change of this kind, because those being asked to change usually perceive that the simple act of doing something differently automatically makes it more difficult for them. You need to overcome this perception by communicating the benefits to them and explain to them why the old way of doing things did not provide them with good customer service.

It is of paramount importance that you have the backing of school leaders to make this change. Without their support you will find it very difficult to enforce new rules that may be perceived to have been made up by staff not on the leadership team.

It is also vital that no exceptions are made when applying the rules to school staff – as soon as one person is permitted to by-pass the procedure you have compromised your authority to enforce it with anyone else.

Establish confidence in the use of the service desk by having the workload monitored and reviewed monthly. The minimum that should be monitored is:

• the number of incidents and requests made through the service desk each week
• the types of requests that take the most time to record
• the customers that appear to need the most support.

Satisfaction surveys are an excellent method of monitoring customer perception and expectation and can be used as a powerful marketing tool. However, several key points should be addressed to ensure success:

• Decide on the scope of the survey
• Decide on the target audience
• Clearly define the questions
• Make the survey easy to complete
• Conduct the survey regularly
• Make sure the users understand the benefits
• Publish the results
• Follow through on survey results
• Translate survey results into actions.

It's all too easy to carry out a survey that elicits vague results that cannot be measured. Here are some factors to consider:

• Do not set targets that cannot be measured
• Ensure that users are aware of what you are doing, and why
• Establish a baseline before discussing formal service-level agreements (SLAs) with users
• Maintain measurements of what is necessary and viable – for instance, if your staff think that they need feedback on response times, then make sure you measure it.

Decide how to measure the results:

• Decide and set targets for a manageable number of objectives for the effectiveness of the service desk
• This task requires careful consideration because after implementation the review will be compared with reality
• Before making changes it is critical to understand the levels of service you are currently providing with the resources available now.