In my various interactions with my customers and fellow professionals,
I have come across many queries where people ask me “If Request Fulfillment
Ticket is not correctly fulfilled, should one reopen the ticket or raise
another request fulfillment or Incident ticket?”
Service request is a request for any service or standard
change. Some examples are password reset, software installation, hardware
request, access/authorization requests, location movement, etc.
Let us consider some examples when service requests are inadequately
or unsatisfactorily provisioned:
- Reset password does not work
- Software installation was not proper or wrong version was installed
- Hardware provided was faulty or of different configuration
- Others
Let us first understand the Ticket Closure part of Request
Fulfillment process. After the ticket has been fulfilled or provisioned, the
resolver group has to seek confirmation from the user before one can assign ‘Resolved’
status to the ticket. This is one of the instances where user can ask for a
proper or satisfactory resolution.
In cases where due to whatever reason (e.g. 3-Contact Process), ticket has been assigned ‘Resolved’ status, user can reopen the
ticket citing reasons for the same. Reopening of the ticket can happen ‘n’
number of times.
What happens when
ticket is reopened?
When a ticket is reopened, the SLA clock starts ticking again.
Please note that the SLA clock does not restart. Thus, the chances of
SLA breach for the resolver group increases. Also, ticket is escalated after nth
time it is reopened (‘n’ depends on the process defined in an organization,).
How does ticket
reopen affect the KPIs?
When a ticket is reopened, two major KPIs that would be
impacted are:
- %age and number of tickets reopened (measurement of how effectively the resolver groups are able to fulfill or provision service requests)
- %age and number of tickets that breach the SLA (another measurement of effectiveness of resolver groups)
Analysis of these two KPIs and the factors that drive up the
number/percentage would lead to SIPs related to ‘People’ or the ‘Process’
itself depending on the analyzed root cause.
Why not create an
Incident Ticket?
Incident is defined as an unplanned interruption to IT
service or degradation of the quality of IT service (or a CI).
When any request is incorrectly provisioned, it is not an
instance of service disruption. The particular user does not have access to
that service itself and thus needs the access to the same. This is a service
request and not an incident.
Please note that when any process is defined, as part of the
process definition itself measures have to be put in place to monitor and
measure process performance besides the aspects that would drive continual improvement
of the process.
No comments:
Post a Comment