Service Desk Ticket Quality

An open discussion on issues related directly or primarily to the service or help desk.
Post Reply
User avatar
vz-r_Dave
Itiler
Itiler
Posts: 15
Joined: Tue Oct 27, 2009 8:00 pm

Thu Dec 24, 2009 9:00 am

Hi Guy's

I would like to know the methods that you use to improve the ticket quality from your Service Desks. Currently we are experiencing lack of information in tickets. This ofcourse is reported to the team leader but unfortunately changes nothing.

The service desk are fairly technical and understand basic trouble shooting techniques. There seems to be a distinct lack of understanding of the importance of ticket quality.

Thanks

Dave


User avatar
Timo
ITIL Expert
ITIL Expert
Posts: 295
Joined: Thu Oct 25, 2007 8:00 pm
Location: Calgary, Canada

Thu Dec 24, 2009 12:49 pm

Physical pain is always a good motivator... or firing a couple of SD folks to set example. Kidding.

But to play devil's advocate, what is the importance of ticket quality? How do you define ticket quality? Put your self in the shoes of the SD analyst and ask your self these questions. If you can't provide an answer that makes sense, you won't be able to get the SD to buy into that.

If you do, then it's a question of training, coaching and just some time. It will become more of a cultural/people issue to get these folks to capture better information in the tickets. Including ticket quality as part of their performance review is one way. Perhaps some penalties in terms of less favorable shifts or something like that. Point is, just like with everything else in the company, things will take time and there needs to be a sustained coaching effort on part of SD management to review tickets, point mistakes, explain what needs to be captured (and how... is there an adequate ticketing tool to make SD analysts life easier?), provide some perks, recognition to those who bought in, promotions, etc, etc... Just don't expect an overnight change.

I think another important thing is working with team leads (depending on your SD structure), as often they are trusted more by stuff than say some ITSM consultant :)
User avatar
AgentJay
Itiler
Itiler
Posts: 19
Joined: Sun Sep 02, 2007 8:00 pm

Tue Dec 29, 2009 10:21 am

Gud points. And some more to add.

First define what the structure is. Have it documented

What a Summary should contain; What Notes should contain and What details you are looking for specific issues in Work Info (Case documentation)

Keep rolling tech alerts once in a week; Send a mail on the best documentation and broadcast the best example.

Additionally, create templates (if you are ok with that) to standardize the case documentation across the floor. All they have to do is use this as a macro or copy/paste in the work info.

This is what I did and my Quality team i quiet happy now with the result
User avatar
smehdi
Itiler
Itiler
Posts: 16
Joined: Tue Dec 08, 2009 7:00 pm

Tue Dec 29, 2009 10:57 am

Hi All,

All the above gentelmen are very correct.But would like to add more in terms of monitoring.Doyou have a proper Incident monitorin system in place .Are you documenting lack of information in an Incident as the error of that particular analyst.Align the no. of errors to his quarterly , monthly or yearly appraisal, whatever is applicable.

I am sure they will start taking it more seriously.
User avatar
vz-r_Dave
Itiler
Itiler
Posts: 15
Joined: Tue Oct 27, 2009 8:00 pm

Mon Jan 04, 2010 1:44 am

smehdi wrote:Hi All,

All the above gentelmen are very correct.But would like to add more in terms of monitoring.Doyou have a proper Incident monitorin system in place .Are you documenting lack of information in an Incident as the error of that particular analyst.Align the no. of errors to his quarterly , monthly or yearly appraisal, whatever is applicable.

I am sure they will start taking it more seriously.
To all above thanks for the information, we already have a set structure in place for ticket structure and the information that should be obtained. This is more to do with performance of the individual and the above would be a very good idea. How easy it will be to implement is a different matter but it is not something we are currently using to measure performance.

Thanks again.
User avatar
JohnKing
Itiler
Itiler
Posts: 5
Joined: Sun Dec 28, 2008 7:00 pm
Location: Midlands UK

Mon Jan 18, 2010 6:31 am

Weve had a focus on ticket quality for a few years now. This came about after a relocation of our service desk.

If there is a feeling that a ticket is not up to the expected quality, a support action flag is put into the ticket. This is unique to the Quality Issue. For example we have them for
- Incorrect SLA
- Incorrect Team
- Insufficient Troubleshooting.

At the end of each month these are reviewed and then feedback to the service desk for discussion and development.

Now for some reality’s
-Has it stopped the poor quality tickets - No. Some people have learnt and taken on board the information. However it tends to be the same people over and over again.

- Not everyone flags the issues. The same 3 people out of a team of 10 will flag 99% of the tickets. Majority are fair, however some are unfair and just moans.

-Metrics -Our service desk has a target of no more than 30 TQ instances in a month. This means that there is more a focus on hitting that target than fixing the issues. Where as in France, there is no target so there more willing to highlight the issues.
Post Reply