Starting CSI with the service desk

I’ve done many Freshservice demos, training sessions, and implementations. During these experiences, I’ve always received feedback on the need for reactive service desk and problem management teams. Where maybe, just maybe, the problem management team does a thorough root cause analysis and provides workarounds and permanent fixes.

However, most of the organizations I work with are missing one of the key teams or capabilities – CSI (continual service improvement). I’ve asked the same question many times: “Why don’t you invest in a team for CSI or performance improvements?” And most of the time, the answer I get is: “Our MIS (management information system) team takes care of reporting and performance improvements.”


Now, where did MIS come into the picture? Aren’t they the management reporting team, who collect KPIs and share the feedback with department heads or directors? What do they know about improving IT or help desk efficiency, or benchmarking? MIS teams will most likely focus on the number of service requests or incidents, or SLA performance, but just collating this data doesn’t necessarily help with improving the service desk performance.

Also, in my opinion, not many organizations are investing in a separate CSI team, or capability, as they think that it’s a part of problem management. But it’s actually the other way round, the CSI team drives the problem management team.

I’m also often asked…

Why is it called “continual” and not “continuous” service improvement?

When you refer to continual, it means that you go and stop and go, occurring repeatedly at intervals over a time span, and such is the case with this team. They measure, then drive, and so on. Whereas “continuous” is going from some start to some end without a break.


Now let’s focus on how we can start implementing CSI processes, without focusing too much on the potential complexity of improvement.

Why not start CSI with the service desk?

If you ask an ITIL consultant, “What should a CSI team focus on?” they might give you a list of buzzwords such as:

  • Deming cycle
  • Critical success factors
  • KPIs
  • 7-step improvement process

But let’s not focus on these for now. I’ll instead suggest a few keywords from my perspective:

  • Customer satisfaction
  • First contact  response/resolution
  • Average resolution time
  • Backlogs
  • Number of re-opens

I know that these are not your ideal CSI metrics, but these can give you a head start within your new CSI team, so that they can start to benchmark these versus industry averages and how local performance can be subsequently improved.

The reason that I’ve listed these metrics is because one of the key discussions that takes place during a CSI meeting is a set of standard questions:

  • What is our vision?
  • Where are we now?
  • Where do we want to be?
  • How do we reach there?
  • Have we reached there?
  • How do we keep the momentum going?

And the above metrics and questions can be combined to kickstart your CSI initiatives. For instance related to:

  • Customer satisfaction – ITIL ultimately focuses on VALUE to the customer and this can be obtained only when the customer is satisfied. So enabling a customer feedback system in your service desk can be a good start.


  • First contact resolution – a customer is less likely to be unhappy if their issue is dealt with immediately. Even if there is a delay in providing a permanent fix, then provide a quick response with a workaround to help ensure the end user is happy with the support and, most importantly, able to continue with their work.
  • Average resolution time – the lower the number, the better organized and more competent your service desk agents are. It most likely means that they are making use of your knowledge base articles or canned responses for quicker resolutions.
  • Backlogs – the lower the number, the better the service desk performance. It means that the service desk is staffed enough (but be careful that it isn’t overstaffed), and that agents are not moving tickets to pending or on-hold statuses.
  • Number of re-opens – IT admins and management often overlook this number. They don’t look to see why a ticket is re-opened several times – the prime reason could be the agent’s incorrect resolution or workaround where the end user needs to keep replying and re-opening the ticket. It might be the result of untrained or incapable agents.


Now, these are just to start with. It’s not the desired end state for a large organization but hey, something is better than nothing. So try out CSI on these service desk metrics to benchmark and to improve the team performance week on week or month on month.

And if you liked this post, do not forget to subscribe to our blog. We would love to share learnings and insights from the ITSM and service desk space. Leave your best email id in the field above, thank us later.