Incident Classification, Notifications Quandry

[wireed]

Issue is we are struggling to revampour ticketing systems towards ITIL. Issue becomes complicated as you ave to have a base and you can't totally cstomize for every device in a network

1) classifying the incidents, notifications and escalations. This get complicated when you are an outsourcer. We want to propely alert of an issue, but what is reasonable when notifying?

2) What is a reasonable timeline for querying the client on what's going on, i.e., status, closing info etc.

Especially difficult when the end user does not respond, do you keep ping away, quit, close the ticket?

Seems like a never ending battle that no one wins!!

Any thoughts?

[UKVIKING]

If you are a outsource bidy providing support for one of the processes, you should hodl regular meetings to discuss ticket flow

to get a policy/process set up for dealing with the unanswerable
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[Sen]

For
1) You need to 1st have proper monitoring in place and with knowledge of kind of alters set you can define the sev of an issue /alert. you can always notify based on critical ones and cover them in SLA's

If the environment is supported or handled by a Vendor, Have frequent meetings

2) The resonable time you be based on the business requirements, The thing I follow is wait for 2 days with 3-4 times reminder to user, if user not responding close the ticket.