How Is IT Issue Tracking Software Used?

The use of service request software to manage the entire lifecycle of service requests using a service request fulfillment process is a good indicator of a mature implementation of IT Service Management (ITSM). Service requests are formal requests from users for an item or service to be provided or a task performed. Service request software supports the processing of the request using a service request fulfillment process, from the user’s initial service request to acknowledging it to request fulfillment, plus any authorization stages. 
Service-request fulfillment differs from incident management. Incident management focuses on restoring services when there has been an interruption or reduction in quality, whereas, service-request fulfillment does not concern itself with service failures. Without service request software to enable the process and to automate tasks, there is a greater risk of dissatisfied users due to service requests being mislaid and regular interruptions to IT when users ask for an item or service.

how is it issue tracking software used 2x how is it issue tracking software used 2x

What is a Service Request?

A service request is a formal request from a user for an item or service to be provided or a task performed. Service requests are often sent to the service desk, but can be routed directly to the team responsible for fulfilling the request by using a service request software. Service requests are usually directed to IT, but a service request can also be a request to ask the service desk to perform a task, or to ask other parts of the business to provide an item or service, including human resources and procurement. Service requests can include a request for information, a password-reset, advice, new software and equipment to be moved. Examples include an address change on a personnel record, a new mobile phone and a new version of flowcharting software to be loaded onto a laptop. A commonly used term for requests that involve moving, adding or changing an item or service is MAC – Moves, Adds and Changes. Some categories of service request may require approval before they can be fulfilled. It may be necessary, for example, for a budget holder to approve a request to purchase a new laptop before the service request is passed to the procurement department.

What is Service Request fulfillment?

Service-request fulfillment is the process of managing service requests throughout their lifecycle, from the initial request to its closure. Service request software supports the execution of the process. The service request fulfillment process includes the following sub-processes:

Request-fulfillment support

This sub-process provides and maintains the tools (including the service request software), model, processes, skills and policies necessary for the effective and efficient processing of service requests.

Request-logging and categorization

This sub-process records and categorizes service requests, including checking the completeness of requests and the requester's authorization to submit them and to support swift and effective processing of the service requests.

Request-model execution

The objective of this sub-process is to execute the lifecycle of a service request within the time schedule agreed in the service level agreement.

Request-monitoring and escalation

This sub-process aims to monitor continually the processing status of in-progress service requests, so action can occur as soon as possible if service levels are likely to be breached.

Request-closure and evaluation

This sub-process is responsible for quality controls of the service-request resolution and associated service-request record before the request can be fully closed. The aim is to ensure the service request has been satisfactorily fulfilled and all the information required to describe the lifecycle of the request has been captured in sufficient detail. The sub-process also aims to achieve continual improvement of the service request fulfillment process, based on the lessons learned during the processing of the request.

What is Service Request software?

Service request software is an IT application, which provides the functionality necessary to support the service request fulfillment process. Service request software typically includes the following features:

Actionable catalogue

An actionable catalogue capability in the software will provide users with a menu and a drop-down list of the standard services they can request, with descriptions and the capability to select one option from the list support. The list should be written using terms and language users can understand. Services should be grouped by categories, for example, information requests, password-reset requests and MAC requests. These can be further subdivided, new software and hardware requests, for example, to assist the support groups. The list should also include any associated service levels to fulfill the selected service-request category.

Service request records

The service request software will create a unique record for every service request, with a unique code identification. All the information about the request is stored in the record, and the service request software should update the record as the request progresses through its lifecycle. The information in the service-request record should include the user, when the user needs the request to be fulfilled, the justification for making the service request, to whom the service request should be routed, the status of the request and records of any approvals and actions to fulfill it. 

Service-request routing

The service request software should be able to route the request to the appropriate support teams using a workflow, according to the selected service-request category, and any sub-categories. Depending on the category, multiple people could have different responsibilities to complete the lifecycle of the service request. For example, the people involved in a service request for a new desktop PC might be a service-desk agent who records the service request after receiving a phone call from the user, a service analyst who reviews the request to check all the required information has been provided, an IT budget holder who approves the expenditure, a clerk who purchases the new PC if there are none in stock, an IT technician who builds the PC to the required specification and an IT-support person who installs the PC at the location specified in the service request. The service request software should be able to support all of the people involved.

Progress-tracking and escalation

The user who submitted the request should be able to view its status using the service request software. This should prevent users calling the service desk for an update. The support teams which fulfill service requests may also want to view the progress of each request assigned to them, which can help them avoid breaching any service levels associated with the service request. For this to work, the service request software must have the capability to associate service levels with the different categories of service requests. The software must also enable the reviewers, approvers and activators of service requests that are part of the workflow to update the status of the request and make any necessary notes of their actions. The service request software may also have the capability to send progress emails to the user who made the service request and to escalate likely service-level breaches automatically to management, so it can address them.

Request fulfillment and closure

The service request software should have the capability to inform the user the service request has been completed and close the service-request record. As well as fulfilling a request for the user, a request could be refused. The reason for refusing to fulfill a service request could include insufficient budget, incorrect authorization levels and non-availability of what was requested. The service request software should be capable of differentiating between these different types of closure.

Reporting

Reporting on service requests is good ITSM practice. As well as reporting on achieving service levels for service requests, the reports can also include the number of service requests received, number closed, number rejected, information on the different categories of service requests and comparison of different groups of users and support groups. The service request software should support the reporting of any capture information during the lifecycle of the service request. The information can then be used to identify any potential issues, so the process, user education and training and how the service request software is being utilized can be improved.

What are the tasks in Service Request software and Service Request fulfillment?

The service request fulfillment process involves a number of different tasks, including those specifically required for implementation and management of the service-desk-fulfillment software. These tasks may be the responsibility of the same individual, or different people.

Users – Requestor

Users are responsible for submitting service requests using the service request software, or any other method agreed and documented in a policy. It is important to ensure users are educated and trained in the use of the service desk software, including how to submit service requests, how to access status updates and how to accept closure of the service request using the service request software after being informed their request has been fulfilled.

Service desk

Where service request software is not used exclusively to make service requests, the service desk has the responsibility to record and categorize service requests from information users provide it. Users can use various methods to contact the service desk with the request, including phone, email and social media tools. When these methods are used, the service desk is responsible for entering the details into the service request software, acting on behalf of the user and keeping the user informed of the progress of his or her service request.

Service-request reviewers

This person is responsible for reviewing service requests to ensure they are complete and comply with any policies. The person is involved immediately after a service request has been submitted, and also during the quality checks before the service request is closed. Service request software often performs this task, as manual checks can be time-consuming and error-prone. If the user makes the initial service request directly to the service desk, then the service desk can also act as a service-request reviewer.

Service-request approvers

Some categories of service requests require approval before they can be fulfilled. This can include financial approval when an expenditure is required and the cost to fulfill the service request is greater than the approval limit of the requestor. It can also include security approval if the type of service requested requires the requestor to have sufficient security clearance. Some organizations insist that line managers review and approve all service requests that aren’t just requests for information. Service desk software can support approvers using effective workflows, including checking the service request against defined parameters, such as cost, with automatic approval if a limit isn’t exceeded. 

Service request fulfilment group

There can be several service-request-fulfilment groups, with each responsible for executing the fulfillment of specific categories and types of service requests. For some types of service request, it may be necessary for one fulfilment group to enlist the assistance of another specialist group, for example, engaging with a procurement function when it is necessary to buy equipment or services to fulfil the service request. The service request software should hold the data, so it can automatically route service requests to the appropriate fulfillment group.

Incident Manager

The incident manager is typically the process owner for the service request fulfillment process. He or she is responsible for the effective design, implementation, change management and continual improvement of the service request fulfillment process. He or she also reports for the process Key Performance Indicators (KPIs) and works with the product owner of the service request software to ensure the software supports the process. The incident manager is also responsible for defining the interfaces between the service request fulfillment process and related processes, including incident management, access management, knowledge management, change management and configuration and asset management. He or she provides the first stage of escalation for service requests that cannot be fulfilled within the agreed service levels.

Knowledge manager

This person is responsible for ensuring the knowledge required for effective use of the service request fulfillment process is captured in the knowledge base the service request software uses and is kept up to date as lessons are learned and new services are introduced. The service request software should make the knowledge available to users, the service desk and other parties involved in the service request fulfillment process, so they can make informed decisions on the type of service request and how it should be managed. 

Service request software product owner

This person has overall ownership of the service request software, with responsibility for the strategy and approving changes to the software. In effect, he or she is the service owner of the service the service request software provides and is responsible for managing this service throughout its entire lifecycle. The service-request-software product owner must review the software strategy to ensure it continues to support the aims of the organization, including IT and users. He or she is also responsible for ensuring service levels for the service request software are achieved, including any targets for availability.

Service request software support

This person is responsible for supporting the service desk software, including the application of maintenance and upgrades.

What are typical Service Request workflows?

The precise details of service-request workflows will depend on needs and organizational structures. Here are some examples of different types of service-request workflows that can be configured into the service request software: 

Request-for-information request

In this type of service request, the user is asking for information, such as “What are the operational hours of the service desk?” Ideally, to try and reduce this type of service request, as much information as possible should be made available to users in an easily accessible and understandable knowledge base via the service request software. It is never possible, however, to eliminate fully this type of request. The first step in a workflow is the user’s question, either by entering it into the service request software himself or herself or by contacting the service desk, which then enters it into the service request software on his or her behalf. If the software has type-ahead search capabilities, where possible answers are presented and narrowed as an additional information-service request is entered, then the service-request fulfillment can be achieved at this point by providing the user with the information he or she requested. When this is not possible, the workflow should use the information provided in the request and the rules documented in the service request software to route the request to the appropriate fulfillment group. It can then either contact the user directly with the requested information or send it to him or her using the service request fulfillment software. The service request can be closed in the software once the user has confirmed his or her request has been fulfilled.

“How-do-I” request

These are service requests in which the user is asking how to perform a task, function or job. The workflow for this type of service request is very similar to a request for information. Some organizations use the same workflow. Again, ideally the request can be satisfied using the service request software, and if not routed automatically to the appropriate service request fulfillment group. The difference between this type of request and a request for information is a “how-do-I” request indicates either the user requires further training in the subject or the training materials are inadequate. This is why it is good practice to categorize “how-do-I” requests separately from information requests. Reports can be generated for this category and sent to the training department/team, so it can take appropriate action.

Password-reset request

Most organizations have now installed software to process password-reset service requests without the need for support from anyone except the user. This software can be part of the service request software or separate, but with a link to it, so the user can access the reset functionality via the menu in the service request software. In organizations where this hasn’t been implemented, it is likely there will be a large volume of password-reset requests, so the process for managing them must be efficient. It is important to track password-reset requests to identify any “repeat offenders” who could benefit from training. This type of workflow has a security aspect. It is important to verify the identity of the user making the request as it could be a fraudulent attempt to gain access to systems using his or her credentials. It is vital, therefore, to include a service-request-fulfilment-workflow step, which  the service request software supports that includes verifying the identity of the user before resetting his or her password.  This is essentially access control, the process responsible for allowing users to make use of IT services, data or other assets.

Desk-move request

In this workflow, a user is moving his or her desk from one location to another. This could involve a number of different activities and fulfillment groups, including IT to move the equipment, security to issue new access passes and office services to update building location information. An efficient workflow for this type of request would use the service request software to inform all of the fulfillment groups about the move at the same time and give them complete visibility of the other groups’ plans to coordinate the move. The service request can only be closed in the service request software when all the component activities have been completed. This is a good example of a multi-branch workflow.

New-software request

When a user requests new software, the workflow is likely to include a number of different approvers. If the software isn’t used anywhere else in the organization, then the service request software will have to request approval from the team responsible for the IT architecture. If IT budgets are held centrally, then the workflow the service request software provides must obtain request approval from the budget holder for IT. Some organizations may also require approval and written justification from the user’s head of department. Rather than doing this via email, the service request software should manage this step using a workflow. Once all approvals have been given, then the service request tool should pass the service request to procurement to purchase the software, to IT to test it and potentially to desktop support to implement it. This type of service request can be difficult to define in the service request software, but once this has been completed, all similar service requests can be efficiently managed to fulfillment.

Reporting request

This workflow is used when a user wants IT to produce a report for him or her. This is a simple workflow for the service request software, as it can usually be routed directly to IT without any prior review or approval stage. 
 

Best practices for Service Request fulfillment

The best practices for service request software and service request fulfillment focus primarily on ensuring the service request fulfillment process is efficient and effective and supports user satisfaction. Best practices include:

Involve users

User representatives should be involved throughout the lifecycle of service request software. Successfully fulfilling a service request is unlikely without this involvement. This should start with defining the expected outcomes from the service request software and the supported processes. Involvement should then continue with defining the service-request categories and any sub-categories. If these are defined without user involvement, then it is very likely users will select the wrong category/sub-category when they submit a service request, resulting in more work for the fulfillment groups and damaging the reputation of the service request software. Users should also be involved in continual review of these categories, and also how the service desk software presents choices to users when submitting service requests.

Keep it simple

The design of how to request services must be as simple as possible. The number of options presented to users when selecting the type and category of service request must be kept to the minimum necessary for effective workflow routing. If simplicity is not maintained in how the service request software presents the choices of service to users, if it requires too many clicks and keystrokes to complete the request or if they don’t easily understand the language and terms used, then one of two outcomes is likely: users will either stop using the service request software and contact the service desk instead or they will pick an incorrect item from a list of available services. Both of these will result in extra effort to process the service request, negatively affect the reputation of the service request software and negatively affect user satisfaction. 

Service-request models

It is a good idea to create a comprehensive service-request model, which defines the agreed service request fulfillment process. This should include all steps defined in the service-request-software workflows for each category of service requests. The service-request model should also define any related policies. 

Self-service portal

Effective service-request-software solutions use portals that users can access from standard Internet browsers. Absence of specialized client applications encourages users to utilize the service request software to submit all service requests and from all types of devices, including mobile phones. Most people use Internet-shopping applications to search for a product, read information about it and then add it to a shopping cart. Using the same look and execution in service request software can convince users to use it.

Customizable service catalogue

The capability of the service request software to use pictures to illustrate the different services that can be requested from the service catalogue can help motivate users to use the service request software instead of contacting the service desk, as the software will assist users to navigate the choices presented.

Customizable workflows

As illustrated in the section on service-request workflows, the detail of workflows will range from simple to complex, and will vary from organization or organization. It is critical, therefore, the service desk software has the capability to customize workflows easily. This should include adding and updating service request fulfillment groups and defining different routings for different service-request categories and sub-categories, multi-branch workflows, review and approval stages and approval limits.

Self-service status information

Users should be able to check the status of service requests they have submitted using the service desk software, without contacting the service desk and submitting another service request. All of these cause delays and frustration. The service desk software should provide a search facility, so users can search for their service requests, both open and closed.

Knowledge base

A knowledge base that is part of the service request software, kept up-to-date with good search functionality and users easily understand is essential to successful service-request fulfillment. Such a knowledge base helps users resolve their requests for information and “how-do-I” requests before creating a service request in the software, and then to make the correct choices if they must to use the service request software. Feedback from using the software and regular analysis of service-request records and usage should be reviewed to support continual improvement of the knowledge base.

What is the role of Service Level Agreements in Service Request software?

To help with customer satisfaction, it is a good idea to provide users with an expectation of when their service request is likely to be fulfilled. It is also a good idea to share the information with the fulfillment groups, so they can prioritize their work on service requests based on required dates. These can both be achieved by designating service level targets for each category and sub-category of service requests.  Representatives of users and fulfillment groups should agree on these targets and document them in a service level agreement (SLA). These service levels must be added to the service request software, so it can track progress against them for each service request, provide automatic escalations if they are likely to be breached and provide reports on service-level achievements at agreed intervals. The service request software can also provide users with the expected date of completion of their service request. Typical service levels for service requests and service request software include:

​​​​​​​The service request software should notify the agents when they are close to violating the service level agreement and re-prioritizing those tickets that are near their due time. This would help agents keep track of tickets and not violate service level agreements. It would also be insightful to know which agents resolve tickets within the service level agreement.