opensubscriber
   Find in this group all groups
 
Unknown more information…

a : arslist@googlegroups.com 23 April 2005 • 1:51AM -0400

Re: Category - Type - Item Best Practice Examples
by Chris Woyton

REPLY TO AUTHOR
 
REPLY TO GROUP




I'll sort of echo what Rick said before and add a bit
to it.

First off, CTI's are not that much of a black art,
really. The thing to keep in mind is that CTI is used
in multiple places in ITSM (and custom apps as well,
typically).

Not only do you need to consider it's use in
identifying the type of call, though, you also need to
consider how it affects Auto-assignment, SLA's,
Knowledge Base, Data Validation and Reporting.

Keep in mind these simple truths as you go along and
periodically remind yourself of them:

1. All business systems exist for at least one of two
purposes: completing the task at hand and gathering
information for planning, metrics and reporting, i.e.,
Tactical and Strategic data gathering. If something
supports neither of these two concepts, it does not
belong in the system. As this pertains to CTI - only
catalog the items you will actually use.
2. The System adapts to the process; do not adapt the
process (and people) to the system (this, of course,
assumes you have good process in place already, but
that's another thread).
2a. A counter-point to the above: never adopt a system
solution to a management problem.
4. Garbage in, garbage out.

Now then...I think there is some disconnect about what
Categorization really is on this thread. CTI is being
interpreted as both "what an issue is" and "what an
issue appears to be".

The most obvious piece of information CTI refers to is
establishing the identity and classification of the
record. Certainly, knowing how the user perceives the
issue is valuable in terms of training or
communication. However, the best practice when dealing
with direct customer input is to not rely upon the
data as entered 100%.

The real question here is: does how a User interprets
an issue provide any real value to a Service and
Support business unit?

It might be nice to know for training, certainly, but
the goal isn't to train the users, it's to deliver
services to them as quickly and efficiently as
possible.

To that end, maintaining the original Categorization
doesn't do much good if it does not classify the
record accurately (of course, one could keep that data
on the ticket anyway in associated fields if deemed
necessary).

It really falls down to this: you can call it CTI,
Categorization, Classification, Type, Call Class or
Malaysian Agriculture and it won't matter. You're
using the data to identify *what kind* of request the
record refers to and use it as such.

The use is key here - are you basing assignment, SLAs,
Reporting, etc. on the perceived issue as given by the
User or the actual issue as defined by the Support
staff?

I would think you would want your workflow and
business process to work on actual, and not perceived,
data.

At any rate...to the original question, this is how I
would devise a custom CTI catalog...

At the core, you want to provide a "decision tree" of
sorts - that is, a hierarchy of values that follow
logically from one to the other.

As Rick suggested, going by symptom as opposed to an
analyzed categorization is a good method to ensure the
User's problem is observed correctly and the data
input with the least amount of effort on the part of
the Agent taking the call. This, however, depends on
the complexity of the issue, the layout of the
Categorization Matrix, the skill of the front-line
agent, and the accuracy of the description.

Just keep in mind that as details are clarified, the
CTI can (and should) change. If the agent can get the
details correct and can identify the issue properly,
then by all means set the correct CTI from the
beginning.

This leads to the next idea...how does one represent
CTI with data?

One trick I do sometimes is to describe a particular
thing in small, granular taxonomic terms and then
identify the CTI values from a range. For example,
consider the case of someone not able to retrieve
email:

Problem
Computer System
Software
Network Service
Messaaging
Outlook
POP Mail
Mail Retrieval

Going from the most general "Problem" to the most
specific "Mail Retrieval" provides a sort of scale. If
you do this for a few common issues you might
encounter, it becomes a bit easier to see what level
of granularity your process and culture requires.

Since the ITSM suite provides a "Call Type" field to
define a Problem ticket (as opposed to an IMAC,
Procurement, etc.), we can exclude that top-level item
as it's accommodated in other places.

If your desk works exclusively with computer systems,
you might use "Software" as the 1st level and skip
"Computer System". If you support multiple systems or
business process calls, "Computer System" may be the
best top-level categorization. By the same token,
"Network Service" might be your 2nd level if you
support multiple Network Services, if not, "Messaging"
might be best for a 2nd level. If you only support 1
messaging software, then Outlook might be best as a
2nd level categorization, and so on.

As you can see, a pattern develops based upon amount -
for a given level, you want to reduce the number of
choices for the current level and maximize the number
of choices for the next level. Also, it's good to
exclude assumed or unused data elements as redundancy
makes the whole thing quite unwieldly to use and
administrate.

Another thing to do when analyzing the layout of the
CTI is to check for "inverted" data. For example:

Email->Network Outage
Database->Network Outage
Web->Network Outage

The best approach in cases like this would be:

Network Outage->Emai
Network Outage->/Database
Network Outage->Web

The only time you would probably want to retain an
inversion like this is if the lower-level data means
different things...

Hardware->Monitor
SNMP->Monitor
Civil War Battleship->Monitor

Or the category items of the parent-level are
unrelated:

Hardware->Change
Software->Change
Procedure->Change

Another good trick is to do as Rick suggested and work
from your outputs back to your inputs.

If you know you'll be required to provide reports on
how many Software related issues you have in general
compared to Hardware or Procedure or Service items,
you know you'll need to provide a break in the data at
that level.

By the same token, if you need to provide the number
of Password Reset, Account Setup and System Move
calls, you know those data elements need to be present
at some level as well.

As it pertains to function, you want to make sure the
distinctions you make for reporting needs don't impede
Assignment or menuing requirements.

For example, if some messaging issues go to a Server
Support group and others go to a Security Group and
yet others go to a Desktop Support group, you want to
make sure your CTI reflects differences for each of
those groups to make assignment rules manageable.

Another *very important* piece of the puzzle as well:
ALWAYS provide an "Other" category. This drives some
people crazy having uncategorized records floating
around, but this is essential. Misclassified data is
far worse than unclassified data.

This also gives one the ability to check out how the
dataset works in a real world scenario. A large number
of "Other" tickets can point to deficiencies in the
CTI catalog or training issues (or both). Part and
parcel to this is preventing free-form data entry in
the CTI fields - do everything you can to both ease
normalize your data and make data-entry hassel-free.

It's easy enough to track down "Other" tickets and
change the CTI of the record to apply to your catalog.
This also allows you to identify areas where you need
to expand the CTI catalog to accommodate something
that's missing.

Basically, since CTI is used to categorize the types
of calls, you want to make sure the categorization is
meaningful to your particular uses.

Also keep in mind that the CTI catalog will change as
needs change and evolve over time. It's best, I've
found, to introduce changes to the catalog gradually
and assess the reporting impact - you may find it
necessary to change the CTI on existing records to
support new requirements or prevent old requirements
from being broken.

Like most things ARS, it's better to add than delete
or modify - liberal use of deactivated CTI items will
help keep things working in the background while
keeping Users from accessing them via the menus.

Hope this helps,

Chris Woyton

-ps pardon the duplicate if it arrives - my outbound
email from my regular ISP seems to be flaking out.

--- "Luebbe, Tom" <Tom.Luebbe@NIEL...> wrote:

> I feel that the CTI's should be a direct reflection
> of your service
> catalog.  Why have CTI's for things that your
> organization does not
> support?  We have the Categories as the main points
> of our service
> catalog.  IE.  This is what we support for Client
> Services, this is what
> we support for Data Management...  Those are all the
> Categories.
>
> We have gotten our Management to quit looking at
> CTI.  That is a bad
> thing to focus on.  We have made it a huge effort to
> focus on Priority.
> If that site was reported down, but it was a Low
> Priority, it would not
> be as major of a concern as that same ticket with a
> high or urgent
> priority.  We have a report, that is our main "What
> happened yesterday"
> report that just looks at everything marked as High
> and Urgent.
>
> The statement that you made that the second level
> person came back to
> you questioning why do I have this CTI in my bucket,
> sounds like they do
> not use the support console, where they would see
> things assigned to
> them, or to the group, independent of the CTI.  They
> should not have to
> go into the Details of the ticket to prove why it
> was assigned to them.
> We would actually like to hide the CTI after it is
> logged, since that
> has no bearing on getting the customer back up and
> running again.  After
> it is logged, the second level tech would see it in
> his bucket, and work
> on it.  If, after some investigation, sees that it
> is not his issue,
> just select a new group. (We put an icon next to the
> assignment group
> that switches the menu for the group, to allow all
> groups to be listed.
> This then notifies the service desk to a possible
> group that needs to be
> added to the skills.)
>
> Just my 2 cents.
>
> Tom Luebbe
> Nielsen Media Research
>
>
> ________________________________
>
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSL...] On Behalf Of Daniel
> Hill
> Sent: Friday, April 22, 2005 11:48 AM
> To: arslist@ARSL...
> Subject: Re: [ARSLIST] Category - Type - Item Best
> Practice Examples
>
>
> **
> 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.
>
> ______________________________This posting was
> submitted via the Web
> interface
>
>
_______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at
> http://www.ARSLIST.org
> (Support: mailto:support@arsl...)
>


Chris Woyton
bach@prim...
602.538.0376

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

_______________________________________________________________________________
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.