{"id":285,"date":"2020-10-21T09:07:08","date_gmt":"2020-10-21T09:07:08","guid":{"rendered":"https:\/\/fitsed.org\/members\/service-desk-cloned-at-2020-11-01-071147\/"},"modified":"2021-12-15T17:27:53","modified_gmt":"2021-12-15T17:27:53","slug":"overview","status":"publish","type":"page","link":"https:\/\/fitsed.org\/members\/service-desk\/overview\/","title":{"rendered":"Overview"},"content":{"rendered":"

\"\"

<\/svg><\/i>Menu<\/span><\/a><\/svg><\/i>Close<\/span><\/a>
<\/svg><\/i>Guidance Area<\/span><\/svg><\/i><\/a>
<\/div>
<\/div><\/div><\/div>
<\/div><\/div>
<\/div><\/div><\/div>
<\/svg><\/i>Blog<\/span><\/svg><\/i><\/a>
<\/div>
<\/div><\/div><\/div>
<\/div><\/div>
<\/div><\/div><\/div>
<\/svg><\/i>Contact Us<\/span><\/svg><\/i><\/a>
<\/div>
<\/div><\/div><\/div>
<\/div><\/div>
<\/div><\/div><\/div><\/div>
<\/div><\/div><\/div><\/div><\/div><\/p>\n

Module 4: Reactive Processes<\/h2>\n
\" data-op-animation-style=\"\" data-op-animation-loop=\"\" data-op-timer-minutes=\"\" data-op-timer-seconds=\"\" class=\"op3-background-parent\" data-op3-stack-columns-desktop=\"\" data-op3-stack-columns-tablet=\"\" data-op3-stack-columns-mobile=\"\" >
    <\/ol><\/div>\n

    What is a service desk?<\/h2>\n

    A service desk is a single point of contact for anything to do with ICT services. It is the one-stop shop for users of ICT services and it provides a focal point and co-ordination for technical support staff. It is a bridge between those who use ICT services and those who provide them. A service desk can also be the hub of ICT activity and play a vital part in the co-ordination of many other FITS processes.<\/h2>\n

    Examples of service desk activities include:<\/p>\n

    Setting up communication methodSetting up incident and problem logging toolsDocumenting procedures for the logging of incidents by end-usersReceiving visits, telephone calls or emails from end-usersLogging end-user incidentsPassing details of logged incidents to technical support for resolutionTracking the progress of incidents and problemsProviding feedback to end-users about their incidentsIssuing communications to end-users about forthcoming changesCreating service reports for technical support managementBeing aware of general trends in incoming incidents and spotting potential major incidents<\/p>\n

    Why use a service desk?<\/h2>\n

    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.<\/h2>\n

    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.<\/p>\n

    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.<\/p>\n

    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.<\/p>\n

    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.<\/p>\n

    Who uses a service desk?<\/h2>\n

    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.<\/h2>\n

    How a service desk works?<\/h2>\n

    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.<\/h2>\n

    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.<\/p>\n

    These tasks are covered in full detail in FITS incident management and FITS problem management.<\/p>\n

    The flowchart below outlines the process.<\/p>\n

    \"\"<\/p>\n

    Types of service desk<\/h2>\n

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

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

    Paper-based service desk<\/h2>\n

    Many service desks start as paper-based systems. We have listed the advantages and disadvantages of these in the table below.<\/h2>\n

    Benefit<\/p>\n

    Disadvantage<\/p>\n

    Simple setup and maintain<\/p>\n

    x<\/p>\n

    Individuals can record and update details and solutions<\/p>\n

    x<\/p>\n

    Minimum amount of detail is recorded<\/p>\n

    x<\/p>\n

    Incidents can only be logged; call tracking is not available<\/p>\n<\/p>\n

    Often the calls are not prioritised<\/p>\n

    x<\/p>\n

    Often the written solution will not aid new call diagnosis<\/p>\n

    x<\/p>\n

    Difficult to produce reports from paper based systems<\/p>\n

    x<\/p>\n

    If the system is simply a technician with a notebook it will always be reactive<\/p>\n

    x<\/p>\n

    Good processes, procedures and documentation will not eliminate the inherent weaknesses of a paper-based system.<\/h2>\n

    Simple spreadsheets or database systems \u2013 an intermediate approach<\/h2>\n

    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.<\/h2>\n

    These are some of the key steps in the process of using a structured or intermediate service desk approach:<\/p>\n

    The school ensures that all calls are logged through an agreed system and the \u2018corridor\u2019 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.<\/p>\n

    The table below shows the benefits and disadvantages of electronic systems.<\/p>\n

    Benefit<\/p>\n

    Disadvantage<\/p>\n

    Improved efficiency as calls can be prioritised and tracked<\/p>\n

    x<\/p>\n

    Accuracy by using a standard way of recording the call<\/p>\n

    x<\/p>\n

    Fast access to past solutions<\/p>\n

    x<\/p>\n

    Availability of management information about known errors and call histories<\/p>\n

    x<\/p>\n

    The system does take time to set up<\/p>\n

    x<\/p>\n

    Users need to be aware of how it works<\/p>\n

    x<\/p>\n

    The data should be backed up- even if to just a floppy disk<\/p>\n

    x<\/p>\n

    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.<\/h2>\n

    Advanced service management systems<\/h2>\n

    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:<\/h2>\n

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

    This should provide a good platform for best practice in technical support. The table below shows the capabilities of today’s service management systems:<\/p>\n

    Benefit<\/p>\n

    Disadvantage<\/p>\n

    Manage, track and monitor requests<\/p>\n

    x<\/p>\n

    Allow priority levels to be set for incidents<\/p>\n

    x<\/p>\n

    Provide response time advice to the user<\/p>\n

    x<\/p>\n

    Manage, track and monitor contractual obligations with technical support providers<\/p>\n

    x<\/p>\n

    Track staff resources and workflows<\/p>\n

    x<\/p>\n

    These systems will also integrate with the other essential service components as described by FITS, for example, the management of assets and configuration<\/p>\n

    x<\/p>\n

    The cost of these systems may make them prohibitive to schools with a small IT infrastructure and small budget. They are well placed in bigger schools with many different technical systems to support.<\/p>\n

    x<\/p>\n

    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.<\/h2>\n

    Logging incidents and making requests<\/h2>\n

    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 \u2018corridor\u2019 approachThis 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 officeThe user visits the technical support office to report an incident or make a request. This approach inspires confidence in the user \u2013 they have discussed the problem with technical support and know that action will ensue.<\/h2>\n<\/p>\n

    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 callThe 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.<\/p>\n

    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 emailIn 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.<\/p>\n<\/p>\n

    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 interactiveThe 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.<\/p>\n

    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:<\/p>\n

    Information about the incident or requestPriority, which will include considering the impact and urgencyService desk details such as initial diagnosis and escalation information (to be completed by the single point of contact)Resolution.<\/p>\n

    What does a service desk cost?<\/h2>\n

    A service desk incurs costs in terms of financial expenditure, people and time.<\/h2>\n

    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.<\/p>\n

    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.<\/p>\n

    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.<\/p>\n

    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.<\/p>\n

    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.<\/p>\n

    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.<\/p>\n

    Activity<\/p>\n

    Example<\/p>\n

    Further Information<\/p>\n

    Preparing for implementation<\/p>\n

    Discussions, planning<\/p>\n

    Service desk implementation guide<\/p>\n

    Implementation<\/p>\n

    Training, pilot, actual implementation<\/p>\n

    Service desk implementation guide<\/p>\n

    Review of implementation<\/p>\n

    Difficulties with process or roles<\/p>\n

    Service desk implementation guide and process review<\/p>\n

    Taking calls from end-users<\/p>\n

    Discussing incident details, impact and urgency<\/p>\n

    Service desk operations guide<\/p>\n

    Logging incidents<\/p>\n

    Completing incident records, updating incident and problem logs<\/p>\n

    Service desk operations guide<\/p>\n

    Liaising with technical staff<\/p>\n

    Contacting technicians with details of urgent incidents, passing on incident records, updating incident and problem logs with feedback<\/p>\n

    Service desk operations guide<\/p>\n

    Liaising with end-users<\/p>\n

    Updating end-users with incident resolution progress<\/p>\n

    Service desk operations guide<\/p>\n

    Continuous improvement<\/p>\n

    Monitoring effectiveness of process, improving efficiency<\/p>\n

    Service desk continuous improvement<\/p>\n

    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.<\/h2>\n

    Benefits of having implemented a service desk<\/h2>\n

    One person or location available to all usersA common call-logging process for users, the service desk and techniciansComplete information about incidents and problemsRecorded information about all calls made – incidents and requestsAvailability of information about the progress of a call and all actions taken so farPrevious history about equipment such as installations and fixesKnowledge about how much technical support is required and the cost.<\/p>\n

    Back to Service Desk<\/a><\/p>\n

    Members Only Content – Please LOGIN OR purchase below<\/p>\n

    FITS Member<\/h2>\n

    This content is for members only.  Please purchase below to get instant access.<\/p>\n

    Special Limited Time Offer<\/p>\n

    Get full member access for only \u00a34.95\/m<\/h2>\n

     We are currently offering full access to the members area for a very special rate. <\/p>\n

    Get your discounted access Now<\/a><\/p>\n

    Already a member? – Login Here<\/a><\/p>\n

    Privacy Policy<\/a> | Terms of Services<\/a> | Cancel Membership<\/a><\/p>\n

    Some content on this website is provided under the provisions of the Open Government License. All other content including, but not restricted to, website design, images logos, etc. <\/p>\n

    Copyright \u00a9 2020 – FITSEd<\/a>. All Rights Reserved<\/p>\n","protected":false},"excerpt":{"rendered":"

    Module 4: Reactive Processes What is a service desk? A service desk is a single point of contact for anything to do with ICT services. It is the one-stop shop for users of ICT services and it provides a focal point and co-ordination for technical support staff. It is a bridge between those who use […]<\/p>\n","protected":false},"author":2,"featured_media":0,"parent":248,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"op_builder_blank","meta":{"footnotes":""},"class_list":["post-285","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/fitsed.org\/members\/wp-json\/wp\/v2\/pages\/285","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/fitsed.org\/members\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/fitsed.org\/members\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/fitsed.org\/members\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/fitsed.org\/members\/wp-json\/wp\/v2\/comments?post=285"}],"version-history":[{"count":1,"href":"https:\/\/fitsed.org\/members\/wp-json\/wp\/v2\/pages\/285\/revisions"}],"predecessor-version":[{"id":2439,"href":"https:\/\/fitsed.org\/members\/wp-json\/wp\/v2\/pages\/285\/revisions\/2439"}],"up":[{"embeddable":true,"href":"https:\/\/fitsed.org\/members\/wp-json\/wp\/v2\/pages\/248"}],"wp:attachment":[{"href":"https:\/\/fitsed.org\/members\/wp-json\/wp\/v2\/media?parent=285"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}