In this article of my IT Service Management maturity series, I will focus on Stage 2 – the IT Service Desk, which is when the service provider sets up a framework in order to move up the curve, so it is important to first have a plan and secondly to be putting together the base operational areas you need. So welcome to the nursery, let’s go!


Creating your service operation strategy roadmap

The IT Service Desk is often the front line (first contact) of the organization. To be successful in introducing an IT Service Desk it’s preferable to have the key stakeholders and process owners in place to have the same ideas about the service strategy and roadmap. From my experience, in order to have the right fundamentals, the scope and topics to discuss together start with a functional design with the following main processes to be discussed:

  • Incidents and requests
  • Agreements and Assets
  • Service Catalog

The service provider here will remain largely reactive with on-demand support but there is a Service Desk framework now in place. With that in mind, let’s first look at the move from a Helpdesk (an element of Stage 1) to an IT Service Desk operation.

In my experience with some of my clients and prospects, who are in this maturity stage, it can sometimes be overwhelming to make the leap “from zero to hero” which is why we have developed an implementation service called Jump Start and a solution called Fast Service.

Without the need for specific technical skills and high overheads in manpower and IT, it’s a simplified and focused way to configure Dynamics 365 Customer Service, to structure the process of incoming tickets, queues for specific topics, supporting the main channels of e-mail and phone to bring added value in not more than 6 weeks.
It’s all about starting with the basics, getting your teams used to more streamlined processes – in order to see better user adoption, one way of working, in order to move forward with ease.

What’s the difference between a Helpdesk and an IT Service Desk?

A Helpdesk is meant for helping end users in using IT services or components. The first Helpdesks came in the eighties and later the Service Desk came in. The Service Desk is broader and is the approach for delivering IT as a service.
In this ITSM 2nd maturity level, the service focus is on problem management processes with alert and event management features being requested. Customer inventory is starting to be measured due to costs and overheads.
Therefore, when setting up your move toward an IT Service Desk, what areas should you be providing?

Making a start building a Service Desk operation

A service desk may be seen as a service department with a team of experts. It’s of course true that you need a team of experts but from a ITIL perspective, a service desk should be in place to capture demand for incident resolution and service requests. It should be an entry point and single point of contact for the service provider for all users.
The Service Desk retains the ownership of any ticket (service or incident) until the resolution and closure. The two core ITSM activities in the IT Service Desk are:

  1. Incident management: restoring normal service when something goes wrong
  2. Service request management: authorizing access to new technology

Incident management

Incident Management is an IT service management process intended to restore “normal” service operation as quickly as possible, minimizing any adverse impact on business operations of the customer or the user. The incoming stream of Incidents for the main channels (from the start) is supported by the IT Service Desk. It’s important to address the approval and assignment process of the IT Service Desk. Business rules and workflows can be of added value by introducing a solution.

In the diagram below I visualize a common process for incident management with the starting point being one of the main service channels (e-mail, phone or the self-service portal).

The objectives of the incident management process are to:

  • Ensure that standardized methods and procedures are used for efficient and prompt response, analysis, documentation, ongoing management and reporting of incidents
  • Increase visibility and communication of incidents to business and IT support staff
  • Enhance business perception of IT through use of a professional approach in quickly resolving and communicating incidents when they occur
  • Align incident management activities and priorities with those of the business
  • Maintain user satisfaction with the quality of IT services.

Incidents vs Requests

Although both incidents and service requests are reported to the Service Desk, this does not mean that they are the same. Service requests do not represent a disruption to agreed service but are a way of meeting the customer’s needs and may be addressing an agreed target in an SLA. Service requests are dealt with by the request fulfilment process. Some organizations will be comfortable letting the requests be handled through their incident management process (and tools) – with service requests being handled as a particular type of ‘incident’.

However, there is a significant difference here – an incident is usually an unplanned event, whereas a service request is usually something that can and should be planned.
The term ‘Request’ is used as a generic description for many different types of demands that are placed upon the IT organization by the users.
Many of these are typically requests for small changes (Standard Changes) that are low risk, frequently performed, low cost etc. (e.g., a request to change a password or parameter), a Request for a Service or maybe just a Request for Information.
Therefore, in an organization where large numbers of service requests must be handled, and where the actions to be taken to fulfil those requests are varied or specialized, it may be appropriate to handle service requests as a separate work stream.
In the diagram below I describe an example of a request management process.

A word about Service Level Agreements and KPIs

You will noticed I have just mentioned SLA just now, Service Level Agreements are another new component when moving from Stage 1 to Stage 2 of the Maturity Curve. It is worth pointing out that SLAs will be in their embryonic stage here because providers will be taking their first steps in parallel to understand performance of the incident management processes being set up. Often SLAs will go hand in hand with the use of KPI based dashboards, even at a basic level.
Organizations need the following capabilities that truly simplify Service Desk operations and ultimately boost the ROI on existing technology investments:

  • Keep track on resolution time and gain visibility on urgent and for example recurring ticket requests.
  • Assign request and incidents to the right support engineer based on skills for every incoming ticket
  • Build knowledge with every ticket request
  • Identify bottlenecks and optimize inefficient processes

How a service catalogue supports your Service Desk

My additional advice when introducing an IT Service Desk solution is to start working on a solid foundation with a service catalogue.
The purpose of the service catalog management process is to provide and maintain a single source of consistent information on all operational services.
The service catalogue is one of the most valuable elements of a comprehensive approach to service provision and, as such, it should be given proper care and attention.
The objectives of the service catalogue management process are:

  • To manage the information contained within the service catalogue
  • To ensure that the service catalogue is accurate and reflects the current details, status, interfaces and dependencies of all services that are being run, or being prepared to run, in the live environment, according to the defined policies
  • Ensure that the service catalogue is made available to those approved to access it
  • Ensure that the service catalogue supports the evolving needs of all other service management processes

It’s preferable to categorize the items maintained and stored in the catalogue, offering both incidents and service requests via a structure that doesn’t require the user to know which they are logging. Keep in mind that it’s very important to have an actual service catalogue with actual data. For the users it should be easy to maintain and access.

How can you support a future-proof IT Service Desk?

One of the goals of introducing ITSM technologies to support the IT Service Desk is to simplify operations. Having the right people, processes, and technology in place is key to being efficient in taking care of incidents and service requests. The right adoption by the users of the IT Service Desk will bring enthusiasm and the right foundation to grow with the team and define the future ITSM strategy.


In my next IT Service Management Maturity article I will move up the curve to Stage 3, where I will move forward from the foundation built in Stage 2 to Service Fulfilment, and what it means for your organisation and customers.

Article initially published on LinkedIn