7 0

Help, we can’t afford a request management system!

According to the HDI 2017 Technical Support Practices and Salary report, a knowledge management system is the second must-have technology, with incident management receiving top ranking.

A request management system came in 8th with only 25% of respondents ranking it as a must-have. Yet you want one for your organization and can’t convince your management to make the investment.

Consider what a request management system does?

Simply put, it documents the known requests and how to fulfill them. It allows customers to browse or search the documented requests and then submit a service request ticket. Behind the scenes, the system manages a set of tasks to authorize and complete the request. Some tasks can possibly be automated, such as download a software package. I wonder how many people realized that if you have a good knowledge management system, then you also have a request management system.

I want to share an extension of knowledge management that helps organizations that can’t afford to purchase a request management system, or actionable service catalog.

Let’s start by introducing the Request knowledge article type.

The Request article type is used when documenting how to fulfill a service request where the approval to implement the change is not required from a governing body, such as a change advisory board. The service request is commonly submitted by an employee to the service desk as a ticket. If the service desk can fulfill the request, they do. Otherwise they escalate the ticket to the appropriate support partner.

Before I continue, I just used two terms from ITIL that I should quickly review for those who are not familiar with them.

  • Service Request: A request for information or advice, or for a standard change or access to an IT service.  Service Requests are usually handled by the service desk, and do not require a request for change (RFC) to be submitted and approved by the governing body known as the change advisory board.
  • Standard Change: A change that is recurrent, well known, has been documented to follow a pre-defined, relatively risk-free path, and is the accepted response to a specific requirement or need, where the authority to implement is effectively given in advance.

A request for information or advice are commonly addressed by the knowledge base. These can be simply answers to questions, how to procedures, or training tutorials. But a request for a change requires a different article type. The issue is not related to something going wrong that needs resolved to restore a service. A request relates to the desire to modify the existing capabilities.

A standard change:

  • may have a cost that is billable to the customer, the department, or the organization
  • may require approval by another party, such as the manager or financial controller
  • may require lead time to implement the change that is longer than the standard service level target
  • has a defined procedure for implementing the change
  • has defined the roles and resources required to implement the change
  • may have prerequisites that must be satisfied to approve the change, such as free disk space for a software install
  • may require an update to the equipment database, asset database, or configuration management database (CMDB)
  • is listed in the service catalog or request catalog as an option for a customer to request

The Request Article Structure

The Request article type is the template used to document all the above information. The customer’s view of the article provides them the information they need to know about the change. While the service desk’s view provides them the knowledge to fulfill the request. The service desk can further benefit when the service management system can automate portions of the workflow needed to support the request. These may be tasks related to the ticket to obtain approval, bill for the change, and notify a support partner to implement the change.

The Request article type is not defined in the KCS Practices Guide. We need to add another section to the KCS article structure to create a Request article type. This new section focuses on the requirements related to implementing the change.  This extension to KCS provides additional value to the organization and enables the request management system. You can include this content before the fulfillment procedure in the resolution field if your knowledge management system does not allow you to add a requirements section to your template.

A sample structure for a Request article type would be:

  • Issue
    • The field is relabeled as a Request to capture a description of the service request.
  • Environment
    • This portion of the article species what Product(s) or Service(s) are to be changed.
      For example, a request to add software to a PC running Microsoft Windows 10.
      This can be specific down to the version of the application or hardware.
    • The environment section could also include Demographics.
      This would be used when the resolution varies by demographic like location or BU.
  • Requirements
    • Prerequisites
    • Lead time
    • Cost
    • Bill to budget (or person and contact information)
    • Approval
      • Required / Not Required
      • Approving Party
    • Record maintenance
      • Required / Not Required
      • Database to update
  • Resolution
    • Customer Procedure - Used to set customer expectations.
    • Level 1 Procedure – documents the actions of the service desk.
    • Level 2 Procedure – documents the tasks of the field and other support teams when the fulfilment cannot be completed by the service desk.
  • Metadata
    • There are numerous metadata fields, such as when was the procedure last updated and by whom.


In a future blog, I will discuss how it is possible to extend the definition of knowledge to automate the creation of tasks when the knowledge management system is integrated with a ticketing system. Tasks, such as gaining approval for a change, billing for the change, and requesting desktop support to perform the implementation can be defined in the knowledge article and then submitted when the article is used to create or resolve a ticket. The fulfilment procedure for a request for software package can be accomplished by embedding a link to your software library in the resolution. More on automation another day.

Actionable Service Catalog

The request knowledge article type can be found through a knowledge base search or through a custom presentation of the filtered knowledge base known as the online service catalog or request catalog. The request catalog enables customers to search the catalog for service requests that have been defined as standard changes which can be fulfilled through either self-service or assisted service. The catalog is referred to as actionable when a customer can then submit a service request from the catalog and actions are taken. The service request ticket, the appropriate tasks, and the assignments are created based on the tasks defined in the knowledge article.

Service Requests that can be fully automated through self-services eliminate the need for the service desk. Automation that creates tasks from the knowledge articles can either eliminate the need for the service desk to touch the service request or minimize the involvement of the service desk. All known approved standard changes should be documented as a knowledge article and automated through the knowledge article.

If your knowledge management system is not integrated with your ticketing system, there is still value in adding request article types. The articles document the service requests that can be made by customers and fulfilled by the organization. And the filter of the knowledge base that allows customer to browse and search only request articles is a request catalog, also known as a service catalog.

If you can’t afford a request management system, then consider extending your knowledge management system.

Related Posts


Leave your comment