Rick,
We're using ITSM 6.
I like your phrase "where the theoretical meets the practical..." There is
obviously a fine line, or tipping point, that needs to be found to balance
those two concepts.
Joe
Joseph Kasell
Network Management Integrator
Global Telcom Services
Navy Federal Credit Union
12851 Worldgate Drive, 7th Floor
Herndon, Virginia 20170
Rick Cook
<[EMAIL PROTECTED]
.COM> To
Sent by: "Action [email protected]
Request System cc
discussion
list(ARSList)" Subject
<[EMAIL PROTECTED] Re: CTI Management Question
ORG>
04/23/2008 02:42
PM
Please respond to
[EMAIL PROTECTED]
RG
------=_Part_17655_31672132.1208976163570
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Joseph, CTIs are the main place where the theoretical meets the practical
in
a Remedy application. Can you tell us what version of Help Desk/ITSM you
are using? It makes a big difference in terms of what you are practically
able to accomplish.
Rick
On Wed, Apr 23, 2008 at 11:35 AM, Joseph Kasell <
[EMAIL PROTECTED]> wrote:
> I don't know if this has been discussed previously but I wanted to find
> out
> how others on this board approached the management of CTI's. In our Help
> Desk application alone, we have 811 defined CTI's. To me that seems
likes
> a lot but it's relative and another organization may not think of that
> number as too high. I know that it has gotten this way because of quick
> replies to requests like "we need a CTI for this" or "we need a CTI for
> that", all of which are arising from a metrics requirements. I know also
> that as this number has increased, it becomes very easy from a
> front-line-support standpoint to get lost when attempting to classify a
> ticket with the appropriate CTI, or from an administrative standpoint
with
> respect to seeing that the need driving a new CTI may already be answered
> by an existing CTI.
>
> I spoke to Support on this and they really had no resource they could
> point
> me to for guidance. They did say that the software should have no
> problems
> handling a large number of CTI's. I've heard of a rule of thumb where
you
> shouldn't have more than 10 Categories, 10 Types for each Category, and
10
> Items for each Type, which seems like a good starting point. I just
would
> like to get ideas from others out there as to how they handle this.
>
> I appreciate the help.
>
> Joe
>
> Joseph Kasell
> Network Management Integrator
> Global Telcom Services
> Navy Federal Credit Union
> 12851 Worldgate Drive, 7th Floor
> Herndon, Virginia 20170
>
>
>
_______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
------=_Part_17655_31672132.1208976163570
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
**
Joseph, CTIs are the main place where the theoretical meets the practical
in a Remedy application. Can you tell us what version of Help
Desk/ITSM you are using? It makes a big difference in terms of what
you are practically able to accomplish.<br>
<br>Rick<br><br><div class="gmail_quote">On Wed, Apr 23, 2008 at 11:35 AM,
Joseph Kasell <<a href="mailto:[EMAIL PROTECTED]
">[EMAIL PROTECTED]</a>> wrote:<br><blockquote
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204);
margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I don't know if this has been discussed previously but I wanted to find
out<br>
how others on this board approached the management of CTI's. In
our Help<br>
Desk application alone, we have 811 defined CTI's. To me that
seems likes<br>
a lot but it's relative and another organization may not think of
that<br>
number as too high. I know that it has gotten this way because of
quick<br>
replies to requests like "we need a CTI for this" or "we
need a CTI for<br>
that", all of which are arising from a metrics requirements. I
know also<br>
that as this number has increased, it becomes very easy from a<br>
front-line-support standpoint to get lost when attempting to classify a<br>
ticket with the appropriate CTI, or from an administrative standpoint
with<br>
respect to seeing that the need driving a new CTI may already be
answered<br>
by an existing CTI.<br>
<br>
I spoke to Support on this and they really had no resource they could
point<br>
me to for guidance. They did say that the software should have no
problems<br>
handling a large number of CTI's. I've heard of a rule of
thumb where you<br>
shouldn't have more than 10 Categories, 10 Types for each Category, and
10<br>
Items for each Type, which seems like a good starting point. I just
would<br>
like to get ideas from others out there as to how they handle this.<br>
<br>
I appreciate the help.<br>
<br>
Joe<br>
<br>
Joseph Kasell<br>
Network Management Integrator<br>
Global Telcom Services<br>
Navy Federal Credit Union<br>
12851 Worldgate Drive, 7th Floor<br>
Herndon, Virginia 20170<br>
<br>
_______________________________________________________________________________<br>
UNSUBSCRIBE or access ARSlist Archives at <a href="http://www.arslist.org";
target="_blank">www.arslist.org</a><br>
Platinum Sponsor: <a href="http://www.rmsportal.com";
target="_blank">www.rmsportal.com</a> ARSlist: "Where the Answers
Are"<br>
</blockquote></div><br>
__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___
------=_Part_17655_31672132.1208976163570--
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
