ITIL self-service ticket handling

[rockon]

Hi,
Since the ITIL defined service desk handles both requests and incidents, could someone tell me what is the preferred default ticket type we should set for self-service? Since the software we use requires us to pick one or the other, should the tickets default to a Request or an Incident? Either way, we have to re-assign the ticket type for some percentage of tickets. It seems to generate extra work for service desk staff? Do you have better idea for self-service?

Also, from the last self-service thread, it seems no tickets should bypass service desk:

1. Doesn't it defeat the purpose of self-service to route ticket automatically to the right person? Now we require service desk to do all the routing of tickets.

2. How do you convince the current users who are used to go to their support person directly. Now their tickets will be going to service desk before it gets to their appointed support person. They think it causes delays. Does that put a lot of pressure on service desk folks?

Thanks.

[fighter]

Rockon,

The Self Service Ticket should always be a Request.

SD recieves the SS Ticket and evaluates the severity and classifies the issue and routes it to the concerned Support Teams and follows it up and bring it to a closure.

If the user is allowed to create an Incident and route to the Technical Person directly how would you know your Technical Resources are utilised for the purpose they are meant to be.

SD purpose would be to classify and investigate the incident if its an incident and they have a resolution the turn around time for your customer would be even lesser than them directly contacting your Tech support.

If you would like more speedy response, Identify the no of tickets coming through SS and based on it you can assign a dedicated SD person to monitor the queue and escalate it as and when its necessary.

Bottom line is you are trying to change the organisation behaviour. It will take perseverance and prolonged effort to make the changes which will eventually make a difference in the way your IT works.

Hope it helps!

Cheers
Vimz!

[ARoll]

I can see both sides of this and seems to be a blurred line between Self Service (or Self Help how i view it) and a Service Catalogue. Maybe it seems a bit simplistic but when accessing an initial question when entering the system: Are you reporting a problem with an existing software, hardware or other component? or Are you request a modification or new software, hardware or other component? (Yes very high level question and can be detailed down further based on your organization). From here this would drive the type of ticket that would be generated. If a user is requesting a new/modification this could potentially feed into your service catalogue or based on the application/hardware/component etc they are requesting within your CMDB you would have owners for that that the service request would be routed to. If a user is reporting a problem they would have a set of online knowledge documents that could be linked to the incident that the user went through to resolve the issue. if it is not resolved from there this would route to the service desk and by already having listed what the user attempted would drive their next steps or determiniation of who it needs to be routed to. If it resolves the issue, simply a resolved incident.

granted this is easier stated then done but depending on your toolset and level of maturity this approach would be highly approachable. Is there a potential for a user selecting the wrong scenario, yes, but that may need to be an acceptible risk when it comes to end users. Just need to build a better mouse trap

But i would like to see other approaches as i'm sure there are many doing this different ways.

[fighter]

ARoll,

What you have mentioned in you post is very valid and a good one too.

We would like to promote the SS Request through internet as an alternative mode for the end users to contact the SD and reduce the volume of calls coming in to SD through Telephone.

The user will validate his ID, User name and login to the system and create a summary and description. All the queries or requests will be routed as a request to the SD. The SD will classify and escalate/resolve the request/issue.

Also there would be a knowledge base which would guide the users on most common queries and issues for their reference.

My reason behind keeping the self service nice and simple is due the maturity of my end users in terms of IT awarness and knowledge.

Based on who your end users is and what their capability in terms of IT usage should drive how detailed your SS can be and what it should do.

Your thoughts on this approach?

Vimz

[ARoll]

That would be the approach that i would take. Its really important, to me, when designing your self service that it does cater to your end user. An approach that can be helpful is if you already have an enterprise wide tool that is widely used on a daily basis, say an hours tracking or HR portal etc. If you can mimic the look and feel, if possible, users are more likely to utilize the tool as well as enjoy the experience. Nothing pains me more then when having to utilize different enterprise wide applications which have no common theme or work flow. In other words if application A looks and acts more like application B, your typical end user will be less apprehensive about using something new becase it is familiar. Also the depth you go into on your self service really also depends on the type of user base. This will probably be the hardest to judge as finding that happey medium of not too technical, but just technical enough and get the desired end results.

[ranjithraghunathan]

I work in a company whose self-service website was appreciated as one of the best in an industry consortium. The CEO expressed his joy post this appreciation through an audio webcast.

As far as I have been part of the evolution of this tool, I have the following points.

The self-service website is value-addition from the SD in terms that it is available 24*7*365 days. Also during high call frequency, there is no waiting time required if the issue can be resolved through the self-service website.

Take the following points:

1. The self-service website has to be evolved in its content over a period of time.
2. The content could be hot fixes, top issues, self-service requests like ID creation etc, user procedures, company policies with respect to IT etc.
3. Self-service website should have links for installation of any authorized softwares to the site that houses these installation packages (including installation instructions)
4. When hot fixes/top issues are identified to be hosted in the self-service website the resolution provided in the solution documents should be easy for anyone (can depend on the general skills of the audience - for an IT company more technical troubleshooting documents can be included. For a company that has their core work in insurance, sales etc...the documents should be very simple to follow). All documents should end with a statement "If your issue is not resolved or you need further assistance....." and should include contact information for global SD.
After a user follows a document and still is not able to resolve the issue, the steps mentioned in the document should go into the ticket and then the ticket assigned to the Service Desk.
5. All ID processing requests that requires very little input in terms of any specific functions performed by the SD should go straight to the concerned approvers/ID admins etc. Approvers - in case where ID processing requries approval.
6. W.r.t point 5, any ticket/service request that usually goes through the SD, but where SD adds very less value or no value at all should be moved to the self-service website.
7. There should be a sponsor for the self-service website who constantly monitors/runs reports on the service requests/incidents that go through the self-service website, so that the site could be progressively improved.
8. In the Incident Management team, there should be a specialised team (the team could be a single person - who monitors the incidents/requests that reach SD through the self-service website, usually like a work coordinator) who will run reports on direct incidents that reach the service desk, based on frequency of the incidents, analysing to find out what more service requests/incidents can be moved to the self-service website.

There are many more I could keep writing, but I think once the above are implemented, you could yourself get on to find more ways to enrich and improve the self-service website.

I think, if the self-service website tickets reach the Service desk without exception, then the idea of having a self-service website is beaten to context and we rather call it just as a service website and not as a self-service website.
_________________
Ranjith Raghunathan
ITIL Foundation Certified

P.S - Most of my posts are to understand the ITIL fundamentals clearly. So please excuse if not genuine answers to questions.

[ranjithraghunathan]

The points I have mentioned above is for the content and implementation fo the self-service website.

We also adopted ways of rewarding users who access the self-service website for resolving their IT issues.
Like rewarding the users based on the frequency at which they access the site, rewarding users for forwarding a hot issue resolution document to their colleagues. (It so happens that a person who is a regular at the self-service portal knows that a resolution for an issue his colleague is facing resides in the self-service website, so he might forward the resolution and thereby increase the popularity of the tool among his colleagues, hence rewarded)

There should be feedback links for the end-users to express their opinion about the service so that the sponsor can have inputs to improve the site and content.

I could go on and on, but anyone who starts with the implementation can go on to, so I leave it with you.
All the best
_________________
Ranjith Raghunathan
ITIL Foundation Certified

P.S - Most of my posts are to understand the ITIL fundamentals clearly. So please excuse if not genuine answers to questions.