A service desk provides the most efficient way of managing end-user incidents. This is of benefit to end-users, who receive a fast and consistent level of service, and to technical support staff, who have their reactive workload organised so that they can process it in the best way possible.

Without a service desk the approach to handling incidents is chaotic. With no agreed point of contact, end-users are free to make up their own procedure, which is usually, and understandably, the line of least resistance. End-users may find it easier to stop a technician in the corridor and ask for help, but in the long term the quality of service they receive will be inferior.

Spontaneous requests usually interrupt other work being carried out and it is unlikely that a technician will be able to respond satisfactorily with either an immediate solution or a plan. The chances are that details will be forgotten because the technician was unable to write them down at the time, and the end-user will perceive that a poor quality of service has been provided.

When all incidents are co-ordinated by a service desk, end-users follow the same procedure every time, details are recorded and a short-term response is given in terms of the technician's estimated time of attendance. Similarly, technicians can carry out their work without interruption and therefore provide a better quality of service.

The central co-ordination of problems also helps technicians to manage their workload effectively and allows the service desk to help by taking responsibility for producing problem trend analysis reports.

Everyone involved in the use and provision of ICT services uses the service desk. End-users contact the service desk to report incidents (including requesting assistance or new services). Technical support staff can use it as a channel for communication to end-users, a source of information and a method for workload management.

A service desk works by establishing a single point of contact and making sure it is available at agreed times. By putting in place a single point where incidents can be reported, along with a tool to record details of incidents, problems, assignment details and progress reports, the service desk can control the flow of work done by technical support.

The FITS service desk implementation guide deals with the setting up of a service desk. The operations guide provides an overview of the day-to-day logging and updating of incidents and problems, and communicating with end-users and technical support staff.

These tasks are covered in full detail in FITS incident management and FITS problem management.

The flowchart below outlines the process.

The best way of deciding which type of service desk will work in your school is for users – teaching and admin staff – and those providing technical support to discuss the current situation, highlighting the benefits and pitfalls of each option.

In a small school where there are only a few pieces of ICT equipment or small systems, a paper-based system may work well.

Many service desks start as paper-based systems. We have listed the advantages and disadvantages of these in the table below.

Good processes, procedures and documentation will not eliminate the inherent weaknesses of a paper-based system.

This type of structured or intermediate service desk approach requires that you impose strict rules about how to log calls, how to approach technical support staff and how to keep users updated with the status of their logged calls. These methods may be a first step in trying to provide good technical support in a school with many computers to support. Once the process is understood by all, the school can move towards an interactive service desk.

These are some of the key steps in the process of using a structured or intermediate service desk approach:

• The school ensures that all calls are logged through an agreed system and the ‘corridor’ approach is not accepted.
• Users should give technical support staff and others providing technical support as much detail as possible to enable the technician to stand the best chance of solving the problem.
• Staff providing technical support need to ensure that the resolution of the incident is documented and that the user is informed when the system is fixed.
• If the fix will take some time, the technician must update the person reporting the incident and find an alternative system that can be used.

The table below shows the benefits and disadvantages of electronic systems.

These systems are not usually sophisticated enough to be used for looking at incident trends or be integrated with configuration details and change requests to create management reports.

A mature approach to the service desk involves selecting some users to provide local support within their department with the full co-operation of the technical support department. This means:

• dialogue between those providing technical support and users will ensure co-operation and understanding of the computer systems in use
• there is no worry that users will purchase anything outside a pre-approved list and then ask for it to be installed
• those providing technical support will release their knowledge through other staff, notes, training materials and knowledge bases
• those providing technical support work with the school leaders in developing a strategy for all areas of ICT.

This should provide a good platform for best practice in technical support. The table below shows the capabilities of today's service management systems:

These systems are not usually sophisticated enough to be used for looking at incident trends or be integrated with configuration details and change requests to create management reports.

There are various ways to log incidents and make requests. The success of the method used depends on the size of the school and the flexibility of those providing technical support.

The ‘corridor’ approach
This is a similar way of logging calls to the 'visit office' approach. If a user simply stops a passing technician or person providing technical support to tell them about a fault, they may not even have the opportunity to write down the details of the incident. The user is confident they have 'logged' the incident or request and then feels let down when the call is not acted upon appropriately.

Visit office
The user visits the technical support office to report an incident or make a request. This approach inspires confidence in the user – they have discussed the problem with technical support and know that action will ensue.

If those providing technical support are besieged with visitors and do not have time to prioritise their workload or to start working on the incidents, this method does not benefit anyone. The staff providing technical support feel that they are very busy, but not prioritising their work reduces their effectiveness. This reactive situation does not embrace best practice.

Paper record of the call
The user completes a paper form with details of the incident and posts it in an in-tray used by support staff. The tray is often placed in staff rooms or near reception. Multipart copies are useful in giving users a copy of the details they have logged.

The success of this system relies on technical staff collecting the forms and allocating priorities sufficiently quickly to encourage staff to continue using the system. It will fail if users find their form still in the in-tray later in the day.

Registering details by phone or email
In schools which use external service desks, users may use phone or email to speed up the process of logging calls. The user must be armed with information about the system they are calling about, which may include an allocated asset tag number and machine type.

The speed of response is not determined by the speed with which the call can be logged. Users may become frustrated if they are required to provide lots of information to the support team, only to find that the response is not what they anticipated. It is important to make all users aware of the agreed response times with this service.

Computer interactive
The user uses a simple online form to log the incident or request. The form is easy to follow and is automatically sent to the technical support team. Having completed the form, the user should be confident that the call will be acted upon and will wait for a response from the support team within the published response time.

Because there is no interaction with a person, it is particularly important to respond within the published response time, or users will give up this method and use the 'corridor' approach instead.

Whichever system is used, the details to be recorded for service desk calls must include the following:

• Information about the incident or request
• Priority, which will include considering the impact and urgency
• Service desk details such as initial diagnosis and escalation information (to be completed by the single point of contact)
• Resolution.

A service desk incurs costs in terms of financial expenditure, people and time.

The cost of your service desk will depend on the scale. The financial cost could include the purchase of tools such as telephones, computers, incident and problem logging software, and the hiring of new staff to perform the task. With limited funds, in the first instance you may wish to make use of the resources you already have.

The tasks to be performed by a service desk are administrative in nature and could be assigned as additional tasks to existing administrative staff. The volume of incidents you receive will have a bearing on whether this approach is sufficient in the long term, but it is a good way to start. Over time you can gather information about incident volumes and, if necessary, use it to justify your case for additional staff.

If you take the approach above you shouldn't need to buy extra telephones and computers, which leaves just the incident and problem-logging software. To get you started we have created some templates for you to use for this purpose. The implementation guide refers to the templates as you need them, and we have also grouped them together in the Toolkit.

When you are ready to automate your incident and problem logging you can choose from a variety of tools available, ranging from the cost-free to the very expensive. However, at the expensive end of the scale, products are likely to be more suitable for a global commercial organisation and probably more than you need.

People are required to front the service desk, so the cost of their time should be taken into account. As indicated above, this can be mitigated by using staff you already have to provide the cover you need, assuming they are able to take on the extra work. It is advisable to make the service desk available to end-users throughout the day, so you may like to spread the workload between more than one person, each providing a 'shift' of cover. See the roles and responsibilities section for further information.

How much time is spent on service desk activities will depend on how many incidents are reported. Time is needed to collate incident and problem information into reports for trend analysis. Finally, don't forget to allow time to implement the service desk in the first place. We have created a table of activities, below, to help you plan the amount of time required.

These systems are not usually sophisticated enough to be used for looking at incident trends or be integrated with configuration details and change requests to create management reports.

• One person or location available to all users
• A common call-logging process for users, the service desk and technicians
• Complete information about incidents and problems
• Recorded information about all calls made - incidents and requests
• Availability of information about the progress of a call and all actions taken so far
• Previous history about equipment such as installations and fixes
• Knowledge about how much technical support is required and the cost.