We have recently implemented a ticketing tool based on ITIL here in our organization. You know, like Remedy or HP OpenView or CA Service Desk, one of those.

The HelpDesk also has this tool, so they are recording their service calls into the tool and forwarding them on to the relevant escalation point to have things resolved, this works well.

However, occasionally (more often than we like) we get requests for work to be done that bypass the 1st line of help. A user will directly call his IT buddy to get something done. Our IT staff will do the work, but they won't record it into our ticketing tool. So we lose the data.

From our IT Staff standpoint, recording incidents into the tool is extra work for them. From our Service Delivery standpoint, we need that data so we can do things like report on how my incidents are bypassing the helpdesk in the first place!

Anyway, any tricks of the trade on how to influence IT members to record ALL service requests into the ticketing tool would be greatly appreciated!

For the IT staff, point out that if management start looking at resourcing the IT operation based on the number of tickets and time spent logged through the system, etc. they may come to the conclusion that they are overstaffed. In which case the staff are potentially doing themselves out of a job by refusing to log calls. That approach can be quite effective in terms of the IT staff.

You will also want to target your users. Get them to understand that if they bypass the help desk they:
- are queue jumping which isn't fair to others,
- do not have any traceability, e.g. if someone in it does something for them on the quiet, then a problem arises -the help desk have no record of what work was done. This isn't in anyone's interests.
- do not have any accountability, e.g. they can't use an escalation procedure with someone from IT who has agreed to do something for them whilst passing in the corridor

Other things you can do:
- remove the direct line numbers of your it staff from the phone book - just use the central help desk number.
- If someone tries bypassing IT, get the techie to sit down at their desk and log the call for them then say, there you go, it's in the queue. Make it clear that there is a process to be followed - don't play favourites.
- Ensure techies understand that they should not do work for users without a call being logged. If they keep to this, the users will soon get the message.
- Have a stock reply for e-mails sent directly to techies. Point out that if the techie is off sick or holiday then the request wouldn't even get looked at for potentially ages. The user will soon start contacting the Help Desk to ensure the job is logged.

Where there is a genuinely urgent incident/request, do the work and log the call afterwards - as long as it is captured.

Those are some of the techniques we've used in the past and I think one of the things the users like most is the accountability. I hope that helps you in some way. Good luck!

For the IT staff, point out that if management start looking at resourcing the IT operation based on the number of tickets and time spent logged through the system, etc. they may come to the conclusion that they are overstaffed. In which case the staff are potentially doing themselves out of a job by refusing to log calls. That approach can be quite effective in terms of the IT staff.

This is good stuff.

How about, are there any "Quick Win" type metrics that you would suggest that we take a look at to encourage IT Staff, that their entering data into the Tool is really worth their while?

Giving recognition to the tech who has solved the most cases or something I have heard before, but sounds a little cheesy and I don't think it would go over well in Japan

That kind of thing doesn't go over well in the cynicism of local government in Britain either

A couple of things that helped turn it around, particularly getting people to log calls through the help desk and not staff, was that it meant the staff weren't getting interrupted all the time which led to more resolution time > better service all around.

I don't know if your ICT department is all sealed off from the rest of the organisation or if it is a through route. Ours used to be and is no longer - we have security swipes on both entries which means people can't just walk in and demand that x be done immediately.

I'm not keen on the metric where so and so has resolved x no. of calls because this may not be representative of the actual work they have done. e.g. someone who picks and chooses all the easy quick fix calls will have a high resolution rate. Someone who picks the really awkwards ones that may take days to fix will have a really low resolution rate.

In my view a preferable option is to send call closure surveys (or another method using call backs) to users. The positives can be fed back to the staff in team briefings or one-to-ones (and negatives dealt with separately according to the nature of the complaint). In ICT it is rare to get thank yous - so encouraging users through surveys to give some positives instead of just negatives is always nice. In terms of a metric you could use something like Joe Bloggs got the majority % of positive reviews this month. If the call isn't logged, there is no chance for positive feedback.

From an operational point of view if you want to discourage techies logging calls and increase those through the help desk, write a report to show you who is logging calls, then dig to find out what kind of things are they logging, how did they come to log them, was it a valid reason, etc.

Later on when everyone is into the habit of putting things through help desk, you can remove the permission (if your software lets you) to log calls from techies so they can just get on with resolving them.

That's all I can think of for the moment. Glad the first post was helpful.

Also when techs are overworked the logging of the tickets show the true work done and can be a good way for techs to document their value to the company (AKA pay raises etc)

Also you start by having the techs log their hours and when the gaps start showing up, they will get the idea.

My favorite ruse for the ”Oh by the way” etc is to inform the user that any incidents I work on without ticket numbers have to be charged back to their department.
Seems money does change everything LOL_________________Oz

I'm not keen on the metric where so and so has resolved x no. of calls because this may not be representative of the actual work they have done. e.g. someone who picks and chooses all the easy quick fix calls will have a high resolution rate. Someone who picks the really awkwards ones that may take days to fix will have a really low resolution rate.

Another option of a metric is for the analysts to be measured on the contribution and future use of knowledge artifacts. That way, the analsyt who is cherry-picking the easy calls but never transfers knowledge to the front-line on how it can be answered first call gets one-upped by the analyst who solved a tough one AND supplied the answer to the front-line.

I really like the idea of this. The problem I see at the moment where I work is that we do not have a consolidated knowledge base and process for adding knowledge. Things are stored all over the place from a specified network drive location to a wiki to the Help Desk's own KB facility to individual's private notes collections!

With the current changes going on I am keen to get Knowledge Management on the agenda for change so that we can actually start to benefit from the wealth of knowledge that we have between us.

we do not have a consolidated knowledge base and process for adding knowledge. Things are stored all over the place from a specified network drive location to a wiki to the Help Desk's own KB facility to individual's private notes collections!

With the current changes going on I am keen to get Knowledge Management on the agenda for change so that we can actually start to benefit from the wealth of knowledge that we have between us.

Hello itilimp,

We see the same thing, virtually everywhere we go. It's very common for most enterprises to implement ITIL in a piecemeal manner, where the processes they design and deploy, along with correlating tools and technologies, are spread out over years. By the time everyone gets done with rolling out two or three solutions for ITIL specific process areas, they find that they're still a very long way from being done, and what's worse is that all the data/information from each system is not being shared and cross correlated, between systems. This is the number one complaint we get from our prospects.

I have to say that we like this problem, as it keeps us in business. We are in the business of tying it all together, which I have to say is very interesting and fun. It gives you a very strong appreciation for all of the ITIL processes when they're at their peak. One interesting thing we found is that very few people will proactively "add knowledge" to a system. As a matter of fact, we found that most people "avoid" providing adequate data, as they see the process of entering, correcting, editing, and ultimately managing data to be a tedious process. What we found was that we had to build systems that were smart enough to collect data about the individuals using the system, and history about them, to fill in as many of the data gaps as possible, automatically (sort of an artificial intelligence solution). You'd be very surprised at how much data you can automatically collect and correlate, when an entire enterprise is focusing all of their process data in one place.

In my view a preferable option is to send call closure surveys (or another method using call backs) to users. The positives can be fed back to the staff in team briefings or one-to-ones (and negatives dealt with separately according to the nature of the complaint).

I understand this survey should focus on the user satisfaction with the service call that was just completed, rather than overall Service Desk performance. Could anyone give some examples of questions that are commonly in a survey of this type?

I have seen lots of great stuff on the post concerning this. One of things that we have been doing is using a ticket monitor form. We use Witness in house to record calls and regulary review and score calls for the Service Desk. I applied this same methodology for the techs. The manager reviews a handful of the tickets a month and scores them on things like resolution, timeliness, proper procedure etc... This gives the manager a good sense of how the techs are handling tickets, we follow this up with some reporting on aging of tickets and yes we do report on the number of tickets the techs are closing. I have recently tied this back to labor cost, and use this as gauge of what a ticket costs us at various levels.

Our Service Desk is reviewed on solve rate as one of there main goals. For a long time we had Service Desk analysts that would fail to enter tickets when they were busy and they could solve a problem in a few minutes, this drastically impacted solve rate. We now have have a high degree of cooperation from the techs and the analysts. this is another one of those things that you have to just grind away on. Working in a call center environment we have a fairly high turn over rate with our customers, so this issue with them trying to bypass the queue comes up from time to time._________________Raymond Valentine
VP IS Support
IRMC
614-865-2942
rvalentine@irmc.com