opensubscriber
   Find in this group all groups
 
Unknown more information…

a : arslist@googlegroups.com 22 April 2005 • 11:48PM -0400

Re: Category - Type - Item Best Practice Examples
by Daniel Hill

REPLY TO AUTHOR
 
REPLY TO GROUP



>From the sounds of it you have swapped the Category | Type | Item with the
Service Catalog. While the Service Catalog is important when dealing with
Service Level Agreements and Business Processes, it does not provide the
information required to appropriately Resolve an Incident or Problem. During
my early days of working on a Help Desk, there were several times second
level support would come to me asking why they received a ticket because the
CTI didn't match anything they handled. (Ticket entered by someone other
than me of course). I would refer them to the Details of the ticket that
pointed out exactly why they got the call, but the CTI didn't match the
Details.

At a Reporting level, upper level management and executives primarily focus
on the CTI. Without defining the CTI as to what is the actual problem, the
senior management and executives will be taking inappropriate actions for
resolution.

Having worked on a Help Desk for several years, I have received quite a few
strange calls. One for example the User stated their entire site was down.
Getting into the details I discovered they were getting an error related to
an invalid password on the Mainframe. I asked if everyone was getting the
error, and the answer was No. Now Categorizing that ticket as a Site Down,
upper management and executives would have started pouring resources into
making sure the incident wasn't repeated, when the only problem was a person
couldn't remember their password. If Auto Assign would have been in place,
the ticket would have started going to groups supporting the site
infrastructure, instead of going to security for a password reset.

With a Tiered support structure your first level analysts should be able to
at least determine Category and Type. You may want an Item of To Be
Determined and / or Other to offset the inability to determine what should
be placed in Item. If the first level analysts are just call handlers and
not able to do any analysis, you should leave them at just using "Default" |
"Default" | "Default" for the CTI and let the second tier analyst perform
the function of selecting a CTI before sending to third tier.

- Daniel

P.S. - IMHO any first tier that cannot perform some type of analysis is just
providing poor service to the customer (the caller). No matter who the
customer is, through business relationships or internal employee's,
providing poor customer service is never a good thing.


-----Original Message-----
From: Rick Cook [mailto:rcook@DENA...]
Sent: Friday, April 22, 2005 10:35 AM
To: arslist@ARSL...
Subject: Re: Category - Type - Item Best Practice Examples


**
Daniel,

The reason I believe in # 1 and # 2 strongly is that when juxtaposed with
the actual resolution CTI set, they can yield areas in which training of the
users, Tier 1 folks, or both is in order.  The idea is that the reported
symptom should reflect at least enough information to start the tech on the
road to a resolution.  But, as you stated, they usually don't know as much
as the tech knows, so of course the data is going to be invalid if you're
using it as a reporting base for the true problem source.  That's where the
second CTI set comes in.

You use the Auto Assignment process with this by setting the groups up by
function or by application.  If I handle issues for an application or
hardware component, it's a good bet that I handle more than one facet of
that, so getting the ticket in the right bucket is close enough.  That's not
always going to automatically get it to the eventual correct person, but
that's why we have the ability to re-assign tickets.  Looking at
re-assignments can also yield data useful in training Help Desk Tier 1 staff
in better analysis and interviewing.

One determining factor in CTI setup is the methodology used by the Help
Desk.  If it employs a Tier 1 that is basically just a triage or calling
station that logs what the user says, maybe takes care of the easy stuff and
then sends the rest off to Tier 2, my way works pretty well.  If the Tier 1
folks solve most issues themselves, then maybe it makes more sense to do it
your way.

Rick


  _____

From: Daniel Hill
Sent: Fri 4/22/2005 5:08 AM
To: arslist@ARSL...
Subject: Re: Category - Type - Item Best Practice Examples


**
I would have to totally disagree with the first 2 statements. Right now our
CTI's focus is around what the user reports as the problem, and it is giving
us invalid information. Besides, since when does the user know what the
problem is? If they did, they wouldn't have to call the Help Desk.
I would say you definitely want the CTI to reflect what the real issue is,
at a generic level of course. Without the CTI reflecting what the real issue
is, how would you effectively use the Auto Assignment processes?
The symptoms the users report are often service focused, and should be left
to the Service Catalog, not the CTI.
RUG 2004 had a nice presentation on Categorization and Service Catalogs. In
the presentation it even made mention:
Categorizations: IT Focused - could be transparent to the Requester.
Service Catalogs: Business Focused - will be how the customer will identify
the issue.

Of course, if your support center (Service Desk, Help Desk, whatever)
supports business processes and procedures, the CTI cannot be fully IT
driven.

- Daniel

-----Original Message-----
From: Rick Cook [mailto:rcook@DENA...]
Sent: Thursday, April 21, 2005 6:00 PM
To: arslist@ARSL...
Subject: Re: Category - Type - Item Best Practice Examples


**
Heather,

No white paper, but here's some ideas that I have on the subject.

1.

        Keep them relative to the symptoms that users report.
2.

        Don't allow them to be changed to reflect the real issue - use a
separate set of CTIs for that.
3.

        Keep them generic enough to limit size creep over time - otherwise
the menus can get unwieldy.
4.

        Keep centralized control over the data, to enforce both data
consistency and ensure adherence to rules 1-3.
5.

        Consider allowing the user's location to filter the CTI's, if that's
applicable for your installation.  If that doesn't work, perhaps the user
type (user, power user, manager, etc.) could filter the lists to what's
appropriate.
6.

        Don't repeat data that is available elsewhere in the ticket.  For
instance, if you track the hardware involved, do it elsewhere rather than,
say, naming each type of printer in the Type or Item list.
7.

        Consider how certain values will best interact with any KB you are
using.
8.

        Finally, and perhaps most importantly, keep in mind what the data
will be used for, and ensure that the structure meets those needs.

Hope that helps!

Rick

  _____

From: Megyesi, Heather
Sent: Thu 4/21/2005 2:40 PM
To: arslist@ARSL...
Subject: Category - Type - Item Best Practice Examples


**

Does anyone have any white papers or other documents on CTI's?
Anyone willing to send some examples that are working good for you?
I'm looking for ideas...we have had Remedy in place for the last few years
and there is talk of restructuring the CTI's at this point.

Looking for some ideas.
Thanks

Heather Megyesi
City Of Portland
Remedy Administrator/Developer
503-823-0981
hmegyesi@ci.p...

"When all other contingencies fail, whatever remains, however improbable,
must be the truth." -- Sherlock Holmes



______________________________This posting was submitted via the Web
interface
______________________________This posting was submitted via the Web
interface


===================================================================

NOTICE - CONFIDENTIAL AND PRIVILEGED - This e-mail may contain

privileged and confidential information and is intended only for the

addressee named above. If you received this message in error,

please immediately notify the sender by return e-mail and delete the

original message; any distribution, copying or use of this e-mail

by you is strictly prohibited and may be unlawful.


______________________________This posting was submitted via the Web
interface
______________________________This posting was submitted via the Web
interface





===================================================================
NOTICE - CONFIDENTIAL AND PRIVILEGED - This e-mail may contain
privileged and confidential information and is intended only for the
addressee named above. If you received this message in error,
please immediately notify the sender by return e-mail and delete the
original message; any distribution, copying or use of this e-mail
by you is strictly prohibited and may be unlawful.

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arsl...)

Bookmark with:

Delicious   Digg   reddit   Facebook   StumbleUpon

Related Messages

opensubscriber is not affiliated with the authors of this message nor responsible for its content.