Conference 7.286::digital

    Greg
    
    Some customers work 24/24 and/or 7/7 and/or 365/365.
    
    I gather the CSCs work these same hours, but would expect the LOR
    people to work around 7.5/24, and 5/7.
    
    Anyway the customers clearly run the risk of throwing up a problem at
    any time of the day, any day of the year.  Their problem may be
    business critical for them requiring the _most urgent_ action.
    
    IMO the CSC should be able to get the escalation process all ready to
    roll into Engineering as soon as the Engineering next working day
    starts.  There are times when the customer does _not_ need the delay of
    waiting for the LOR to launch the escalation procedure.
    
    But I do agree the the LOR needs to be informed of problems, and
    remedial actions launched so they can manage the customer relationship.

    CLD - I've heard that stands for "Customer Leaving Digital."
    
    			Alfred

    Well, what do you know.  A subject that is near and dear to my heart. 
    I've only been with the CSC (and Digital) for about a year and a half,
    but I've learned a lot about the escalation process in that time.  I
    agree that the current CLD process isn't terrible, but I definitely
    think there could be some improvements.  
    
    Number one IMHO is that there should be some way that we can CLD that
    doesn't require Local office interaction (at least in order to get the
    ball rolling).  I've had a number of critical elevations that have been
    reproduceable here that have sat somewhere in limbo between here and
    engineering because they hadn't been quickly escalated in the field.  I
    definitely think that it is a good idea to give the field a heads-up,
    but to require them to analyze the problem and do their own processing
    before it goes to engineering is (many times) wasted time.
    
    Don't get me wrong here, there are many situations where the field has
    been very instrumental in solving CSC calls, but there should be a way
    to do it directly.
    
    Also, the current interface between CSC-CHAMP and the field systems
    should be titled HOOVER (they suck)  Most times, when the field updates
    a call, even when closing it, a message is not sent back to the
    CSC-CHAMP system to notify the Specialists that the call has been
    closed.  This usually leads to a long run of phone tag and wasted time
    between the CSC and the field trying to get status of calls.
    
    Well, now that I've expressed my opinions, I have some good news and
    some bad news.  There is a new tool out there called IPMT (don't ask me
    what it stands for, I don't know) that is replacing the current CLD
    and SPR systems (don't get me started on the old SPR system).  It is
    supposed to provide a lot better interface for communication on
    escalated issues.  Engineering is already using it.  Now, the bad news
    is that the server is slooow right now (improvements are supposed to be
    coming) and there hasn't been an interface from CSC-CHAMP coded yet, so
    all escalations will have to be entered and tracked separately from
    CHAMP.  Supposedly this will provide better control and communication
    between escalation systems and CHAMP.
    
    I guess my current attitude is wait-and-see what IPMT does for us.  So
    far, since I've gotten an IPMT account, I haven't been able to access
    it due to some technical considerations, and the character-cell
    interface doesn't really work.  I'm not looking forward to the next 6-8
    months where we will track our regular calls via CHAMP and all
    escalations will be manually through IPMT (access to IPMT will be
    restricted).
    
    Jay Morgan
    Pathworks for Mac Team
    

>    Well, what do you know.  A subject that is near and dear to my heart. 

Yeah, me too.

As someone in engineering on the receiving end of CLDs, a couple of comments:

I like the idea of having the local office be the "owner" of the thing. In
order to get any additional information or to have something done, you have
to do it through the on-site folks anyway. No disrespect to the CSC but they
just add another layer to the communication path at this point in the process.

As far as CLD vs IPMT, I'll take a CLD any day. There just isn't any
information in the IPMT report - other than a bazillion lines of noise.

My only other gripe with the escalation process is those few (repeat few!)
cases where a CLD or whatever is logged either at the request of a customer
who completely dominates to local office and wants a little special attention
or is logged by a local office to please some irate customer and get 'em off
his back. There's nothing engineering can do other than come up with some
hocus pocus that amounts to passing the buck back to the local guys.

Generally speaking, the CLD process isn't busted - please don't fix it.

Mickey.

    Well, I might as well give you my "take". I'm the local office. I guess
    now we have all three. I've been a regional support guy for about 6
    years now. We've gone full circle on one aspect of this. In '88 the
    center shipped all CLD's to the field for escalation. No exceptions.
    The center wanted the ability to push and the field wanted to give it
    to them. So about July of '90 it happened. The center got the ability
    to push straight to engineering. Problems poped up now and then, but
    nothing earth shaking. Usually, it was something big would happen on
    site without the locals knowing about it and some Sales type person
    would get blind sided and he/she would blind side the UM and he/she
    would blindside the rep. Stuff runs down hill, you know.
    
    	Well, a great big power struggle formed, and turf lines where
    drawn. Support engineers where asked to help the center (Unified
    support). The cross polination has hard to track or manage and more
    friction was created. "I don't need to fund the center becouse I do all
    their work" and " Why do we even need the locals if we do all their
    work" mentalities aligned in there own camps. The customer was basicly
    help hostage while we struggled. Eventually, a truce was drawn and
    everybody fell back to their own turf. We'll do the Phone support
    and you'll do the onsite stuff. 
    
    	The ironic part is that the guys in the trenches had no idea most
    of this was even happening. All we say was mood swings. First we can,
    then we can't. I personnally trust the center to make the call. If they
    need me to get involved, they will call. If it needs CLD'ing, they
    should be able to do it. On the flip side, I liked taking calls off
    of unified. I had 200 hours of calls between January and July. Not
    much by a center persons standards, but good for a guy in the field.
    In July, we got a message that said, your account is being moved to
    another machine. We never got in again. Again, Power strugles
    by people that have never talked to a customer.
    
    Oh well,
    
    jim
    

    
   > Again, Power struggles by people that have never talked to a customer.
    
Amen brother. You speek the truth.

I think my most valuable lesson in customer relations was when I walked on
site one day, customer had just kicked the previous Field Engineer off site
for making a bad situation worse, VAX guts all over the floor, and he starts
screeming at me 3 inches from my face about how he has a payroll run for
12,000 employees due in 2 hours. 

No sir, nothing like the front lines.

Neil
    

For what it's worth, last communique I received on CLDs is dated 
27-April-1992 and was intended to address this issue.  It stated
among other things:

>	Lately, many calls are being sent as LOR's to the Field where we
>(the CSC), say that the problem needs to be sent to Engineering, has 
>already been sent to Engineering, is already CLD or needs to be a CLD,
>without qualifying how, when, or under what process it got there. 
>
>We need to STOP this practice immediately.

and:

>	When communicating with the Field we should always reference the
>process and the CLD or SPR number. If we can't, then the CSC should
>escalate the CLD or SPR ourselves. I would also like to reinforce that,
>any and all other Customers with the same problem will also be escalated
>to Engineering, by the CSC, with the appropriate process for that Customer
>(not the LOR process).

and, finally:

>	If you are working with a Customer on a problem which is not yet 
>defined and need Field involvement, do an LOR (please do not recommend 
>escalation) and let them know what is needed . Then work with the Field, 
>as a team, to further define/document the issue. If it is a product problem
>(software bug) which is ready to be sent to Engineering, then the Field
>should do the escalation.

(I would have posted the entire message but I don't have the author's
permission) 

-Andy

Re .0:

>    SPR - An SPR is kind of like a CLD, but lower priority.  ...

Like a priority 1 CLD or a priority 2 CLD?
				/AHM

    
    	I see the CLD process split into two or more categories for
    additional options and flexibility.
    	First, keep the present CLD type which is prompted by a local emergency
    (and I do think it's good to have local reps involved for customer
    relations). 
    	The second category would be of a general warning type allowing 
    proactive CLDs. Since the CSCs are a logical point of Field operations 
    control and a funnel back to Engineering, the CSCs should have the
    capability to escalate a CLD if multiple sites are experiencing the
    same difficulty. This may allow the escalation of problems BEFORE they
    become critical / Customer Leaving Digital in nature. Essentially we
    should encourage the CSCs and other support organizations to escalate 
    problems of a moderate nature in a proactive way.
    	I think a case could be built for a third category. This type of
    CLD would be a consolidation of multiple CLDs if seemingly different problem
    types can be reclassified into one.
    	Maybe the 2nd or 3rd type are called something else. But the combination
    of the three would provide the capability to a) respond to local
    emergencies b) escalate moderate problems seen on a more global basis
    before becoming critical and c) consolidate/coordinate and reclassify 
    multiple CLDs, problem statements and engineering resources applied to 
    seemingly different problems.   
    
    
    Regards,
    
    	Jim K

    	The biggest problem with LORs is that the person who initially
    receives them is usually the MCS engineer who often doesn't have a clue
    what the (hypothetical) "POLYcenter 400 TSAM access violation" problem is 
    related to. This leads to a fire drill to locate or nominate a focal
    person to handle the call. The customer then gets the pleasure of
    either replaying the details again or waiting until someone
    knowledgable is available.
    
    	The CLD process is only as good as the person(s) working an LOR
    requiring one. The biggest challenge for a support person is to have 
    all the details concisely packaged before escalating the call to
    Engineering. I've seen too many CLDs that might as well say:
    "i's broke". I don't intend to propogate these types and also don't
    want to hear Engineering push back with penny-ante busywork requests
    if a tightly documented, reproducable case is submitted.
    
    Phil
    
    Central States Product Support
    

    Hello,
    
    Here in Holland Software Support is all in one room for one
    productline. TSC/CSC/"local office". We specialists are connected 
    "live" with the customer who logs a call. 
    
>    CLD = ????  I think the original translation was "Call Logging Desk",
    
    CLD means Critical Level Disruption...
    
>    Believe it or not, the process isn't all that bad.  It ain't perfect,
>    but it isn't bad either.   Now, before you all barbecue me, I must
    
    Agree. We only escalated when we do not get any informal response
    from Engineering. Since we use IPMT, there is hardly any local overhead
    involved. When I submit a CASE, I can monitor the progress, I can
    add comments.
    
>    To generate a proper CLD, somebody needs to define the problem
>    properly.  You don't want to waste engineering talent trying to define
    
    Even more inportant is the priority and the impact for
    the customer as well as for Digital. Only a person who "knows"
    the customer is able to define these properly.
    
    By the way, SPR's and CLD's are replaced by IPMT
    (Integrated Problem Management Tool).
    
    IPMT has 5 levels of impact. Compared to CLD/SPR level they are:
    
    1. CLD, Severely Impaired and Non Productive.                               
    2. CLD, Product Behaviour that impacts customer operation.                  
            No solution is currently available.                                 
    3. SPR, Partial, noncritical functionality loss.                            
    4. SPR, Minor issue, very limited or no loss or functionality.              
    5. SPR, Suggestion, enhancement.                                            
    
>    The other issue:  Sometimes customers call their local office to
>    find out status on a problem.  As you all know, Digital corporate is
>    not the easiest entity to communicate with.  So when the customer calls
>    the local office, it would be really good if the local office knows what
>    is going on.  If the local office is managing the problem, they will by
>    definition know what is going on.
    
    Overhere in Europe we use NICE as call management system. When a customer
    logges a call, he gets a lognumber. With this lognumber, anyone 
    can see what happened with a call. What the status is, who the
    owner of the problem is etc etc.
    
    So it is not that bad at all.
    
    Regards,
    
    Jan
    

    
    Does anyone know how much each CLD costs DIGITAL? I have heard
    figures as high as 1.5 million.  Considering the amount of visibility
    each CLD escalation (VP level) gets until it is closed and since it
    means "drop everything else and attend to this problem" for Engineering
    the cost has to be pretty steep.

    No way does each CLD cost anywhere close to $1.5 million!  And no way
    does each CLD get VP attention.  No human could possibly keep track of
    that much data.  
    
    I don't expect an engineering group to drop everything and attend to
    every CLD I send.  That would be bad for the company in the long run
    because they would never get new releases out the door.  Well, OK, I'd 
    like engineering to drop everything and take care of MY problems first -) 
    (is that a smiley face?).
    
    - Greg Scott

    The figures that I have heard are around $5,000 per CLD (I used to work
    in the support part of CSSE). Some CLD's get VP attention. There are TOP N
    reports and aging reports to show problem areas that should get
    attention.
    
    I've never heard of a CLD that cost $1.5 million.
    
    michael

>    I've never heard of a CLD that cost $1.5 million.

    But I'm sure there are several we didn't fix that ended up costing
    much, much more (in lost sales) :-)
    
...petri

    There have been several multi-million dollar errors/fixes in 
    the past too.
    
    fm

Working from the center (VMS SUPPORT in COLORADO), I like the ability of 
issuing the cld from the center.  It saves money and I can make a reasonable 
judgment whether the local office can provide input.  For example, there is a 
DECinspect issue I worked where the code is simply broke.  You can easily see 
the problem in the listing and there is nothing the local office can add value 
to.  The end user understands the problem and we agree to CLD from the center.

On the other hand, we have a customer who has DECScheduler that show a symptom 
we cant reproduce, can find no issue with the code and any other avenue to 
solve the problem (notesfiles, other people, contacts in engineering) fail 
to show a solution.  We must have the local office involved to "assist" in 
an assessment of the problem.  They may not fix the issue but it is reasonable 
to involve them because they know the end user better than we could possible 
know.  Turns out there was a third party scheduling software that called 
DECScheduler and screwed up.

I expect the local referral to receive a proper response.  If this does not 
happen, then the field support groups failed to hold up their end in a "value
added" process.  I stress this characterization because any local involvment 
from my prespective is "value added" whether you can fix it or not. I believe
the frustration with the process is too many engineers, specialists, managers
spread too thin to handle the volume, poor understanding of the process, and 
customers taking advantage of the system.  I have worked the field so I know
the other end of the pipe.  I'm sure some lor's are not well thought out but
are sent to the field anyway.  Doesn't mean they are all worthless. 

As far as customers blowing up at a local engineer, I look at this as all the 
more reason for having local lor's no matter if they can fix it or not.  This
is why we invest in management training.  I have a great deal of respect for 
local managers that take the heat from a customer and still try to do what's 
best for the enduser.  Customer is being stupid if he thinks yelling is going 
to solve anything.  There's no way a manager should let that happen if he's 
done his job right.  Stand up for the engineer and then pull the engineer aside 
privately and fix what went wrong.  

The one gripe I have with the current system is I never find out the solution.
All I get is "the local offics has agreed to close this call".  I'll never
know if I missed something.

john becker

Re:<<< Note 2824.0 by ANGLIN::SCOTTG "Dammit Jim, I'm a person not a resource!" >>>

>						btw, in this string, let's
>    agree to use the acronym "CSC" for Customer Support Center.  
>    
>    The U.S. has 3 of 'em, in Colorado Springs, Atlanta, and Shrewsbury.
    
Some management might not agree with your definitions after spending lots of 
time, energy, and $$$ to promote the notion that we have just *one* CSC in the
U.S. which happens to be spread over 3 locations...  :-) 

-  David

With the new reorganization of the "off-site districts", the Customer Support
Center as an entity is no longer in existance.

Here in Shrewsbury, most of the teams are members of the new "America's Zone
Expertise Center".  Colorado and Atlanta are primarily part of the "Off-Site
Service Delivery Districts" (does anyone know the real name of this
organization?).  Naturally, there are some in CXO and ALF that are part of
the EC and vica versa.

The goal here, as explained to us, is to get closer to the customer and more
aligned with the field organization.  We'll see.

Oh...the discussion was around elevations, right?  We're now in the process of
working a manual stop-gap measure to directly access IPMT until such a time as
CHAMP/CSC (oops, there's that acronym again!) can get its automatic interface
set up.

	dave

I haven't been able to look in this note since I entered .3, but here's my 
thoughts on 'recent' replies:

re: .4

>I like the idea of having the local office be the "owner" of the thing. In
>order to get any additional information or to have something done, you have
>to do it through the on-site folks anyway. No disrespect to the CSC but they
>just add another layer to the communication path at this point in the process.

In some cases this is true, but many times the customer comes to me to find 
out status, and since the communication between the CHAMP systems have been
virtually non-existent, it was almost impossible to do this.

re: .5

>   Usually, it was something big would happen on
>    site without the locals knowing about it and some Sales type person
>    would get blind sided and he/she would blind side the UM and he/she
>    would blindside the rep. Stuff runs down hill, you know.

Yeah, for this reason, I definitely support at least a heads up on Center
Directed CLD's.

re: .17

>The one gripe I have with the current system is I never find out the solution.
>All I get is "the local offics has agreed to close this call".  I'll never
>know if I missed something.

Amen.  (referring to the "current" system)

re: .19 
>We're now in the process of working a manual stop-gap measure to directly
> access IPMT until such a time as
>CHAMP/CSC (oops, there's that acronym again!) can get its automatic interface
>set up.

Now, my current feelings on this is that IPMT was planned for implementation
in the CSC a little prematurely.  For example, in our district (DESK), only
SWS4s are being given access to IPMT because of the lack of an interface to
CHAMP and the performance problems with large numbers of people accessing
IPMT interactively.  This effectively makes the more technically experienced
people problem managers for all of the other people.  In my mind, a waste of
valuable resources.  As for myself, I'm going to offer my services to people on
my team to help with CSC (or is it AZEC or OSSDD) escalations, since I was 
lucky enough to get an IPMT account (even though I'm not a SWS4).  We have a
number of SWS4s that are not happy with being relegated to this task.
Now, considering the considerable time in getting new features of CHAMP
implemented, I don't expect communication between IPMT and CHAMP for at least
a year if not two.

Jay