When an end user sends a request, he always expects it to be considered as High priority. Even if it is a minor issue, it is a High Priority one, in his terms. I always suggest my clients to carefully design the Requester's Incident Form in the Self-Service Portal in such a way that the Requesters do not drive the workflow of the ticket. Here are few thoughts on what inputs should be gathered from the form,

Fields which should definitely be in the requesters incident form,

• Requester Name
• Subject
• Category

Fields which should not be in the requesters incident form,

• Priority
• Technician
• Level

 Configure SLAs based on priority

ServiceDesk Plus allows you to configure SLA based on many available criteria, however it is highly recommended to configure SLAs based on Priority. It is always easier to classify any ticket  (irrespective of the type, category, and requester) based on the priority.  This way, you can classify all your incoming requests with fewer SLAs and set up the due by time as per your environment's acceptance level. Now this raises the question, how to assign the right priority to each ticket? To address this, we have come up with a feature called Priority Matrix.

Define your Priority automatically using Priority Matrix.

You can define the Priority of any incident based on the Impact that incident has created in the organization and the Urgency in which the ticket should be resolved. For those who need clarification on Urgency & Priority, here is a scenario for explanation. Consider a payroll server down on say Jan 5th & the same server being down on Jan 27th . In this case, the urgency to resolve the ticket is higher on Jan 27th as it is towards the end of the month and needs to be addressed immediately compared to Jan 5th when the payroll usage is minimum. Depending on the Urgency, the Priority of the ticket raised on Jan 27th is Higher. 

ServiceDesk Plus allows the End User or the Technician to define Impact & Urgency based on which, the Priority Matrix will automatically sets the Priority. This way, the SLA too can be set based on the Priority Matrix.

It is better to automate the SLA based on Priority Matrix (Impact and Urgency) than letting end users define the SLA.

Arvind Parthiban

A Day in the Life of a Change Manager: A Perspective for Service Desk Professionals | August Webinar

.

Tuesday, August 16th
1:00 - 2:00 PM Eastern
12:00 - 1:00 PM Central                                                                            
11:00 AM - 12:00 PM Mountain
10:00 AM - 11:00 AM Pacific

A Day in the Life of a Change Manager: A Perspective for Service Desk Professionals
With Glenn LeClair, CMC & Arvind Parthiban,  Sponsored By ManageEngine, ServiceDesk Plus

Register Now!
.........................................................................................

.The change process is often a “Black Box” to many front line service professionals. The change decisions that are made greatly impact the workload of support staff and the quality of services provided. This webinar is intended to de-mystify change management and offer a perspective for service desk managers by examining the normal activities and challenges of a change manager.

Moving beyond the basics of ITIL theory, Glenn will guide you down daily events that include:

• Communication requirements
• Late change requests
• "Emergencies"
• Approval processes
• CAB composition
• Basics of CAB administration
• Role of the service desk

By the end of the session, you should have a clear understanding of how the process can work to help you, and what rights and obligations come for service desk managers with a "seat at the CAB table."

About Our Presenter:

Glenn LeClair is an experienced, "hands on" consultant and former change manager. As a Certified Management Consultant (CMC) he has been an active practitioner in a variety of fields for 20 years. For the last 12 years he has been focused on the domains of ITIL and IT service management and is a certified instructor and v3.0 Expert. He is a graduate of Trent University and holds an honors degree in policy studies. He is a former member of the faculty of Humber College, and an author of several ITIL and IT governance publications. Glenn is also a consultant in the field of service management, a former director of management consulting with DMR/Fujitsu Consulting and former senior consultant with Hewlett-Packard Canada.
Member Price: FREE
Non-Member Price: FREE

Register Now!

Arvind Parthiban

ServiceDesk Plus

I know most of you are using ServiceDesk Plus in the right way, however in few of our customer environments I found certain features are used improperly. So I have started a series of tips & tricks blogs to use ServiceDesk Plus features efficiently. Here's one example where tickets were merged in place of implementing Problem Management.

Merging Tickets

When to merge a ticket?

The purpose of merging tickets is to avoid duplicate entries. When a requester raises a request twice for the same incident, the two tickets can be merged.

Here's a scenario: A requester, say Bob, sends an email to the help desk for his laptop problem. He then calls the help desk to reconfirm the logging of this incident and the help desk creates another ticket for the same issue. The duplicate tickets fall under these conditions,

• Same Requester 
• Same Incident  
• Duplicate entry 

When the above condition occurs, the tickets can be merged and the rest of the tickets/conversation will be continued as a conversation thread under one ticket.

What not to merge?

In the same scenario, if multiple requesters report the same issue, do not merge them. If tickets from many requesters are merged, then only one requester will be emailed and the records will be tied only to the parent request. These multiple incidents can be analyzed and moved to Problem Management, if necessary.

.............

Problem Management

"The primary goal of Problem Management is to reduce adverse impacts caused by incidents and to avoid the recurrence of problems related to these incidents."

Consider a scenario where a "wi-fi not connecting" incident is reported. The technician suggests basic troubleshooting tips to resolve the issue. However, over a period of time, the incident occurs again and again. To eliminate this issue permanently, the root cause of the incident is to be found and resolved. A problem involving a group of incidents should be created for this purpose and assigned to an appropriate technician.​

Rules of engagement for Problem Management:

1. Root cause is unknown.
2. Multiple incidents involving the same issue.
3. Common Symptoms.
4. Known Error with a possible workaround.

Add your doubts/ interested modules in which you are looking for more tips & best practices, so we can blog more about these tips & tricks of ServiceDesk Plus.

Use ServiceDesk Plus efficiently and help us help you.

Arvind

www.servicedeskplus.com

•      One of the tips that I would always suggest is to send them links to the Knowledge Base while replying to their tickets. If they are prompted to use the Knowledge Base several times, they would sink into the routine of accessing the Portal before raising tickets.
•      ​Direct them to the Self-Service Portal by skipping the login screen with single sign-on

In recent times all consultants, ITSM courses, blogs have been buzzing the term "Service Catalog". They suggest you to start implementing ITIL in your environment with a simple Service Catalog. But the question is "Is Service Catalog really that simple to start with?" For those who don’t know about SC, it is like a menu card for IT department telling the users what services are offered to them, how soon it can be delivered and the process to deliver it.

So, when is the right time to implement Service Catalog?

Service Catalog is not a module to start your ITIL expedition with. You need the basic building blocks to be implemented first. In my opinion, you definitely need the Incident Management and Change Management in place before you proceed with the Service Catalog.

Packaging your work is as important as the work itself.

Service Catalog helps you to organize the offered services that are specific to the user requirements. It also provides clarity & visibility about your IT operations to your end user and sets the right expectation on the delivery time of the service. Service Catalog also takes care of the work flow process right from approval to implementation of each service. In short, Service Catalog gives your IT a new face. I would say that Service Catalog is definitely a necessity for those who have the basic processes in place - adopt Service Catalog now and do not play the catch-up game later. And for those who do not have Incident and Change management, Service Catalog is only a luxury.